From owner-xfs@oss.sgi.com Mon Oct 1 00:24:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 00:24:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l917NuWJ029549 for ; Mon, 1 Oct 2007 00:24:00 -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 RAA20859; Mon, 1 Oct 2007 17:23:51 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id DF61C58C4C0A; Mon, 1 Oct 2007 17:23:50 +1000 (EST) Date: Mon, 01 Oct 2007 17:23:50 +1000 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.23 - revert a commit User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4443/Sun Sep 30 15:16:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13190 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 Hi Linus, A problem has been found for the XFS commit b394e43e995d08821588a22561c6a71a63b4ff27 and it needs to be reverted. It has the potential for worse corruption than what it is meant to fix. Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus Lachlan's description: This fix is for a problem that has been in XFS since day one. [XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer. It tries to fix an issue where log replay is replaying an inode cluster initialisation transaction that should not be replayed because the inode cluster on disk is more up to date. Since we don't log file sizes (we rely on inode flushing to get them to disk) then we can't just replay all the transations in the log and expect the inode to be completely restored. We lose file size updates. Unfortunately this fix is causing more (serious) problems than it is fixing so please don't push this one back just yet. This will update the following files: fs/xfs/xfs_buf_item.h | 5 ---- fs/xfs/xfs_log_recover.c | 51 ++------------------------------------------- fs/xfs/xfs_trans_buf.c | 1 - 3 files changed, 3 insertions(+), 54 deletions(-) through these commits: commit 053c59a0a7234bac669992f5b8b933b7d7fc189d Author: Tim Shimmin Date: Mon Oct 1 16:39:37 2007 +1000 Revert "[XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer." This reverts commit b394e43e995d08821588a22561c6a71a63b4ff27. SGI-PV: 969656 SGI-Modid: xfs-linux-melb:xfs-kern:29804a Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin --Tim From owner-xfs@oss.sgi.com Mon Oct 1 00:49:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 00:49:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l917nd9b000545 for ; Mon, 1 Oct 2007 00:49:43 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21432; Mon, 1 Oct 2007 17:49:31 +1000 Message-ID: <4700A68A.8070609@sgi.com> Date: Mon, 01 Oct 2007 17:49:30 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Sandeen CC: Christoph Hellwig , xfs-oss Subject: Re: [PATCH V2] refactor xfs_mountfs for clarity & stack savings References: <46D37A82.2080608@sandeen.net> <20070828195221.GA7237@infradead.org> <46D48BDE.5000903@sandeen.net> In-Reply-To: <46D48BDE.5000903@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4443/Sun Sep 30 15:16:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13191 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Refactoring xfs_mountfs() to call sub-functions for logical > chunks can help save a bit of stack, and can make it easier to > read this long function. Finally got around to reviewing this one, sorry for the delay. I think we've lost something in the refactoring. > Index: linux-2.6-xfs/fs/xfs/xfs_mount.c ... > - /* > - * XFS uses the uuid from the superblock as the unique > - * identifier for fsid. We can not use the uuid from the volume > - * since a single partition filesystem is identical to a single > - * partition volume/filesystem. > - */ > - if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && > - (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { > - if (xfs_uuid_mount(mp)) { > - error = XFS_ERROR(EINVAL); > - goto error1; > - } > - uuid_mounted=1; The patch removes uuid_mounted=1, but doesn't put it back in anywhere. I think we need that bit for error handling :) Don From owner-xfs@oss.sgi.com Mon Oct 1 02:43:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 02:43:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l919hCHV014146 for ; Mon, 1 Oct 2007 02:43:13 -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 58CF122DDD; Mon, 1 Oct 2007 11:30:01 +0200 (CEST) To: Timothy Shimmin Cc: Martin Steigerwald , xfs@oss.sgi.com Subject: Re: Creation time in XFS References: <200709302124.38164.Martin@lichtvoll.de> <470042DC.2040009@sgi.com> From: Andi Kleen Date: 01 Oct 2007 11:30:01 +0200 In-Reply-To: <470042DC.2040009@sgi.com> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/4444/Mon Oct 1 00:57:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13192 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs Timothy Shimmin writes: > No XFS does not support creation time. It just has the regular > atime,mtime and ctime. > There are no plans that I've heard to support it. > Not much involved to support it AFAICT but it would either involve > changing the ondisk format of the inode or storing it in an EA. If you ever change the on disk format adding a file type similar to ext3 to directories could also greatly speed up find in many cases. > I wonder how this creation time is being exported currently? I don't think it is at all currently: % gid i_crtime fs/udf/udf_i.h:21:#define UDF_I_CRTIME(X) ( UDF_I(X)->i_crtime ) include/linux/ext4_fs.h:344: __le32 i_crtime; /* File Creation time */ include/linux/ext4_fs_i.h:160: struct timespec i_crtime; include/linux/udf_fs_i.h:20: struct timespec i_crtime; fs/ext4/ialloc.c:566: inode->i_mtime = inode->i_atime = inode->i_ctime = ei->i_crtime = fs/ext4/inode.c:2705: EXT4_EINODE_GET_XTIME(i_crtime, ei, raw_inode); fs/ext4/inode.c:2792: EXT4_EINODE_SET_XTIME(i_crtime, ei, raw_inode); -Andi From owner-xfs@oss.sgi.com Mon Oct 1 05:39:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 05:39:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l91Cdmfu016554 for ; Mon, 1 Oct 2007 05:39:50 -0700 Received: from liberator.sandeen.net (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 1AB911807A967; Mon, 1 Oct 2007 07:39:47 -0500 (CDT) Message-ID: <4700EA92.1030004@sandeen.net> Date: Mon, 01 Oct 2007 07:39:46 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Donald Douwsma CC: Christoph Hellwig , xfs-oss Subject: Re: [PATCH V2] refactor xfs_mountfs for clarity & stack savings References: <46D37A82.2080608@sandeen.net> <20070828195221.GA7237@infradead.org> <46D48BDE.5000903@sandeen.net> <4700A68A.8070609@sgi.com> In-Reply-To: <4700A68A.8070609@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 01:32:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13193 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 Donald Douwsma wrote: > Eric Sandeen wrote: >> Refactoring xfs_mountfs() to call sub-functions for logical >> chunks can help save a bit of stack, and can make it easier to >> read this long function. > > Finally got around to reviewing this one, sorry for the delay. > > I think we've lost something in the refactoring. > >> Index: linux-2.6-xfs/fs/xfs/xfs_mount.c > ... >> - /* >> - * XFS uses the uuid from the superblock as the unique >> - * identifier for fsid. We can not use the uuid from the volume >> - * since a single partition filesystem is identical to a single >> - * partition volume/filesystem. >> - */ >> - if ((mfsi_flags & XFS_MFSI_SECOND) == 0 && >> - (mp->m_flags & XFS_MOUNT_NOUUID) == 0) { >> - if (xfs_uuid_mount(mp)) { >> - error = XFS_ERROR(EINVAL); >> - goto error1; >> - } >> - uuid_mounted=1; > > The patch removes uuid_mounted=1, but doesn't put it back in anywhere. > I think we need that bit for error handling :) Hm, no idea how I lost that... maybe in bouncing from cvs to kernel.org version. Sorry, will look this evening & fix it up. -Eric From owner-xfs@oss.sgi.com Mon Oct 1 05:55:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 05:55:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l91Ct6M3018659 for ; Mon, 1 Oct 2007 05:55:07 -0700 Received: from liberator.sandeen.net (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 B414A1807A968; Mon, 1 Oct 2007 07:55:06 -0500 (CDT) Message-ID: <4700EE2A.1020304@sandeen.net> Date: Mon, 01 Oct 2007 07:55:06 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tim Shimmin CC: xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> In-Reply-To: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 01:32:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13194 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 Tim Shimmin wrote: > Hi Linus, > > A problem has been found for the XFS commit b394e43e995d08821588a22561c6a71a63b4ff27 > and it needs to be reverted. > It has the potential for worse corruption than what it is meant to fix. Whoops... that's what I get for picking it up too soon for fedora I guess! Any background on the newly-found problem, for those of us in the peanut gallery? Thanks, -Eric From owner-xfs@oss.sgi.com Mon Oct 1 06:05:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 06:05:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l91D5WUC020140 for ; Mon, 1 Oct 2007 06:05:34 -0700 Received: from liberator.sandeen.net (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 A66A418015182; Mon, 1 Oct 2007 08:05:32 -0500 (CDT) Message-ID: <4700F09C.5080903@sandeen.net> Date: Mon, 01 Oct 2007 08:05:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tim Shimmin CC: xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> In-Reply-To: <4700EE2A.1020304@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 01:32:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13195 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 Eric Sandeen wrote: > Tim Shimmin wrote: >> Hi Linus, >> >> A problem has been found for the XFS commit b394e43e995d08821588a22561c6a71a63b4ff27 >> and it needs to be reverted. >> It has the potential for worse corruption than what it is meant to fix. > > > Whoops... that's what I get for picking it up too soon for fedora I guess! > > Any background on the newly-found problem, for those of us in the peanut > gallery? Oh, I'm sorry, the problem description is already there. I thought that was the original commit description when I first saw it. -Eric From owner-xfs@oss.sgi.com Mon Oct 1 06:12:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 06:12:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l91DCFsO021244 for ; Mon, 1 Oct 2007 06:12:20 -0700 Received: from liberator.sandeen.net (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 65CC01807A96A; Mon, 1 Oct 2007 08:12:15 -0500 (CDT) Message-ID: <4700F22F.3070307@sandeen.net> Date: Mon, 01 Oct 2007 08:12:15 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Tim Shimmin CC: xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4700F09C.5080903@sandeen.net> In-Reply-To: <4700F09C.5080903@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 01:32:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13196 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 Eric Sandeen wrote: > Eric Sandeen wrote: >> Tim Shimmin wrote: >>> Hi Linus, >>> >>> A problem has been found for the XFS commit b394e43e995d08821588a22561c6a71a63b4ff27 >>> and it needs to be reverted. >>> It has the potential for worse corruption than what it is meant to fix. >> >> Whoops... that's what I get for picking it up too soon for fedora I guess! >> >> Any background on the newly-found problem, for those of us in the peanut >> gallery? > > Oh, I'm sorry, the problem description is already there. I thought that > was the original commit description when I first saw it. *sigh* or maybe not. ok, no more email 'til I've had my coffee. -Eric From owner-xfs@oss.sgi.com Mon Oct 1 08:18:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 08:18:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from smtp2.linux-foundation.org (smtp2.linux-foundation.org [207.189.120.14]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l91FIIa0009551 for ; Mon, 1 Oct 2007 08:18:18 -0700 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l91F2cmm023462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 08:02:39 -0700 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l91F2bLE021934; Mon, 1 Oct 2007 08:02:37 -0700 Date: Mon, 1 Oct 2007 08:02:37 -0700 (PDT) From: Linus Torvalds To: Tim Shimmin cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit In-Reply-To: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> Message-ID: References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii X-MIMEDefang-Filter: lf$Revision: 1.185 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 X-Virus-Scanned: ClamAV 0.91.2/4445/Mon Oct 1 01:32:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13197 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: torvalds@linux-foundation.org Precedence: bulk X-list: xfs On Mon, 1 Oct 2007, Tim Shimmin wrote: > > Lachlan's description: > This fix is for a problem that has been in XFS since day one. > [XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer. ... Why wasn't this in the commit logs? Now it just says it was reverted, with no actual reasoning *why*. And it apparently wasn't so obvious that no such reasoning is needed. Gah. I ended up amending the commit and updating it with the comment. Linus From owner-xfs@oss.sgi.com Mon Oct 1 17:14:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 17:14:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l920DtFV029313 for ; Mon, 1 Oct 2007 17:14:00 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14481; Tue, 2 Oct 2007 10:13:48 +1000 Message-ID: <47018D3C.9070409@sgi.com> Date: Tue, 02 Oct 2007 10:13:48 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Linus Torvalds CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4447/Mon Oct 1 15:02:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13198 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 Linus Torvalds wrote: > > On Mon, 1 Oct 2007, Tim Shimmin wrote: >> Lachlan's description: >> This fix is for a problem that has been in XFS since day one. >> [XFS] Avoid replaying inode buffer initialisation log items if on-disk version is newer. > ... > > Why wasn't this in the commit logs? Now it just says it was reverted, with > no actual reasoning *why*. And it apparently wasn't so obvious that no > such reasoning is needed. > > Gah. I ended up amending the commit and updating it with the comment. > > Linus Yeah, sorry about that. It occurred to me later on. I initially converted the sgi-mod (undo mod) to a git commit and then discovered git-revert and thought, hey I'll use that instead but then forgot to add all the text into it. D'oh. Thanks for the fixup. --Tim From owner-xfs@oss.sgi.com Mon Oct 1 18:41:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 18:41:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l921fghu012306 for ; Mon, 1 Oct 2007 18:41:44 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16027; Tue, 2 Oct 2007 11:41:37 +1000 Message-ID: <4701A1D0.5010709@sgi.com> Date: Tue, 02 Oct 2007 11:41:36 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> In-Reply-To: <4700EE2A.1020304@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4447/Mon Oct 1 15:02:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13199 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 Eric Sandeen wrote: > Tim Shimmin wrote: >> Hi Linus, >> >> A problem has been found for the XFS commit b394e43e995d08821588a22561c6a71a63b4ff27 >> and it needs to be reverted. >> It has the potential for worse corruption than what it is meant to fix. > > > Whoops... that's what I get for picking it up too soon for fedora I guess! > > Any background on the newly-found problem, for those of us in the peanut > gallery? > > Thanks, > > -Eric Hi Eric, Lachlan worked this problem so he can probably provide more details. My understanding is that we were having a problem with the log replay replaying newly allocated inodes (inodes from buffer items) over the top of buffers which were actually more up-to-date than what was logged. The code used a heuristic to determine if the buffer had been written to for the inode (by checking on magic#, mode and gen# - not going to comment on this). Anyway, it comes down to either copying over the inode buf data or not copying it over (doing or not doing the log replay). The change could cause the buffer to be not overwritten in replay where previously it would be. We want this to not happen as part of the fix and doing the right thing and not by mistake and failing to replay when we need it to be replayed. I presume the latter is what is happening. The symptoms of this is what Lachlan has discovered in QA on a debug kernel and he can provide the details. I believe this started from not logging the inode size changes (as is consistent with the logging model) for performance reasons, and so we can't rely on inode log items coming up on log replay to fix things up. BTW, we currently have 3 ways of logging an inode: 1. in an item buffer and marked as an inode 2. in an item buffer and not marked as an inode 3. in an inode item and 3 places where they get replayed: 1. xlog_recover_do_inode_buffer - for di_next_unlinked pointer recovery 2. xlog_recover_do_reg_buffer - for newly allocated inode recovery 3. xlog_recover_do_inode_trans - for general inode recovery The fix was in #2. Ughh. --Tim From owner-xfs@oss.sgi.com Mon Oct 1 20:10:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 20:10:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l923AETH031126 for ; Mon, 1 Oct 2007 20:10:18 -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 NAA18531; Tue, 2 Oct 2007 13:10:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 5372F58C38F1; Tue, 2 Oct 2007 13:10:09 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - cleanup vnode useage in xfs_ioctl.c Message-Id: <20071002031009.5372F58C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 13:10:09 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4448/Mon Oct 1 18:32:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13200 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs cleanup vnode useage in xfs_ioctl.c xfs_ioctl.c passes around vnode pointers quite a lot, but all places already have the Linux inode which is identical to the vnode these days. Clean the code up to always use the Linux inode. Signed-off-by: Christoph Hellwig Date: Sun Sep 30 23:26:24 PDT 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-log Inspected by: Christoph Hellwig Author: lachlan.longdrop.melbourne.sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29807a fs/xfs/linux-2.6/xfs_ioctl.c - 1.156 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.156&r2=text&tr2=1.155&f=h - cleanup vnode useage in xfs_ioctl.c From owner-xfs@oss.sgi.com Mon Oct 1 20:11:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 20:12:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l923BqhT031559 for ; Mon, 1 Oct 2007 20:11: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 NAA18565; Tue, 2 Oct 2007 13:11:48 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id A310158C38F1; Tue, 2 Oct 2007 13:11:48 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - cleanup vnode useage in xfs_iget.c Message-Id: <20071002031148.A310158C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 13:11:48 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4448/Mon Oct 1 18:32:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13201 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs cleanup vnode useage in xfs_iget.c Get rid of vnode useage in xfs_iget.c and pass Linux inode / xfs_inode where apropinquate. And kill some useless helpers while we're at it. Signed-off-by: Christoph Hellwig Date: Mon Oct 1 16:47:33 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-log Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29808a fs/xfs/xfs_iget.c - 1.236 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.236&r2=text&tr2=1.235&f=h fs/xfs/xfs_inode.h - 1.236 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.236&r2=text&tr2=1.235&f=h fs/xfs/linux-2.6/xfs_vnode.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h fs/xfs/linux-2.6/xfs_vnode.h - 1.143 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.143&r2=text&tr2=1.142&f=h fs/xfs/linux-2.6/xfs_ksyms.c - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h - cleanup vnode useage in xfs_iget.c From owner-xfs@oss.sgi.com Mon Oct 1 20:23:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 20:23:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l923NS9e005662 for ; Mon, 1 Oct 2007 20:23:32 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18827; Tue, 2 Oct 2007 13:23:24 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id D90EC30B55CE; Tue, 2 Oct 2007 13:23:23 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - kill xfs_freeze Message-Id: <20071002032323.D90EC30B55CE@linuxbuild.melbourne.sgi.com> Date: Tue, 2 Oct 2007 13:23:23 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4448/Mon Oct 1 18:32:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13202 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs kill xfs_freeze. No need to have a wrapper just two call two more functions. Signed-off-by: Christoph Hellwig Date: Tue Oct 2 13:22:40 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29816a fs/xfs/xfs_vfsops.c - 1.545 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.545&r2=text&tr2=1.544&f=h - kill xfs_freeze. fs/xfs/linux-2.6/xfs_super.c - 1.400 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.400&r2=text&tr2=1.399&f=h - kill xfs_freeze. fs/xfs/xfs_vfsops.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h - kill xfs_freeze. From owner-xfs@oss.sgi.com Mon Oct 1 20:26:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 20:26:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l923Qis7006699 for ; Mon, 1 Oct 2007 20:26:48 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18920; Tue, 2 Oct 2007 13:26:40 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 577F230CD1E8; Tue, 2 Oct 2007 13:26:40 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - kill probe_* sysctl leftovers Message-Id: <20071002032640.577F230CD1E8@linuxbuild.melbourne.sgi.com> Date: Tue, 2 Oct 2007 13:26:40 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4448/Mon Oct 1 18:32:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13203 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs kill probe_* sysctl leftovers After my recent changes the probe_* sysctls are unused because we do a proper request_module now if we actually know that we need the quota or dmapi module. Kill the leftovers that have no function anymore. Signed-off-by: Christoph Hellwig Date: Tue Oct 2 13:26:11 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29817a fs/xfs/linux-2.6/xfs_globals.c - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_globals.c.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h - kill probe_* sysctl leftovers. fs/xfs/linux-2.6/xfs_linux.h - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h - kill probe_* sysctl leftovers. fs/xfs/linux-2.6/xfs_sysctl.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h - kill probe_* sysctl leftovers. fs/xfs/linux-2.6/xfs_sysctl.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h - kill probe_* sysctl leftovers. From owner-xfs@oss.sgi.com Mon Oct 1 21:51:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 21:51:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l924pG8Z021053 for ; Mon, 1 Oct 2007 21:51:19 -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 OAA20981; Tue, 2 Oct 2007 14:51:12 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 494EE58C38F1; Tue, 2 Oct 2007 14:51:12 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 971186 - clean up some xfs_log_priv.h macros Message-Id: <20071002045112.494EE58C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 14:51:12 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13205 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs clean up some xfs_log_priv.h macros - the various assign lsn macros are replaced by a single inline, xlog_assign_lsn, which is equivalent to ASSIGN_ANY_LSN_HOST except for a more sane calling convention. ASSIGN_LSN_DISK is replaced by xlog_assign_lsn and a manual bytespap, and ASSIGN_LSN by the same, except we pass the cycle and block arguments explicitly instead of a log paramter. The latter two variants only had 2, respectively one user anyway. - the GET_CYCLE is replaced by a xlog_get_cycle inline with exactly the same calling conventions. - GET_CLIENT_ID is replaced by xlog_get_client_id which leaves away the unused arch argument. Instead of conditional defintions depending on host endianess we now do an unconditional swap and shift then, which generates equal code. - the unused XLOG_SET macro is removed. Signed-off-by: Christoph Hellwig Date: Tue Oct 2 14:47:44 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29820a fs/xfs/xfs_log.c - 1.341 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.341&r2=text&tr2=1.340&f=h fs/xfs/xfs_log_priv.h - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h fs/xfs/xfs_log_recover.c - 1.328 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.328&r2=text&tr2=1.327&f=h - clean up some xfs_log_priv.h macros From owner-xfs@oss.sgi.com Mon Oct 1 21:50:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 21:50:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l924oVCo020930 for ; Mon, 1 Oct 2007 21:50:34 -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 OAA20978; Tue, 2 Oct 2007 14:50:26 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id A77AF58C38F1; Tue, 2 Oct 2007 14:50:26 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 971186 - clean up some xfs_log_priv.h macros Message-Id: <20071002045026.A77AF58C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 14:50:26 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13204 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs clean up some xfs_log_priv.h macros - the various assign lsn macros are replaced by a single inline, xlog_assign_lsn, which is equivalent to ASSIGN_ANY_LSN_HOST except for a more sane calling convention. ASSIGN_LSN_DISK is replaced by xlog_assign_lsn and a manual bytespap, and ASSIGN_LSN by the same, except we pass the cycle and block arguments explicitly instead of a log paramter. The latter two variants only had 2, respectively one user anyway. - the GET_CYCLE is replaced by a xlog_get_cycle inline with exactly the same calling conventions. - GET_CLIENT_ID is replaced by xlog_get_client_id which leaves away the unused arch argument. Instead of conditional defintions depending on host endianess we now do an unconditional swap and shift then, which generates equal code. - the unused XLOG_SET macro is removed. Signed-off-by: Christoph Hellwig Date: Tue Oct 2 14:34:49 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29819a fs/xfs/xfs_log.c - 1.340 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.340&r2=text&tr2=1.339&f=h fs/xfs/xfs_log_priv.h - 1.123 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h fs/xfs/xfs_log_recover.c - 1.327 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.327&r2=text&tr2=1.326&f=h - clean up some xfs_log_priv.h macros From owner-xfs@oss.sgi.com Mon Oct 1 22:20:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 22:20:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l925Jxdw024520 for ; Mon, 1 Oct 2007 22:20:02 -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 PAA21697; Tue, 2 Oct 2007 15:19:55 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 03B9E58C38F1; Tue, 2 Oct 2007 15:19:54 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - xlog_rec_header/xlog_rec_ext_header endianess annotations Message-Id: <20071002051955.03B9E58C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 15:19:54 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13206 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs xlog_rec_header/xlog_rec_ext_header endianess annotations Mostly trivial conversion with one exceptions: h_num_logops was kept in native endian previously and only converted to big endian in xlog_sync, but we always keep it big endian now. With todays cpus fast byteswap instructions that's not an issue but the new variant keeps the code clean and maintainable. Signed-off-by: Christoph Hellwig Date: Tue Oct 2 15:19:07 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Signed-off-by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29821a fs/xfs/xfsidbg.c - 1.338 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.338&r2=text&tr2=1.337&f=h fs/xfs/xfs_log.h - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.h.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h fs/xfs/xfs_log.c - 1.342 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.342&r2=text&tr2=1.341&f=h fs/xfs/xfs_log_priv.h - 1.125 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h fs/xfs/xfs_log_recover.c - 1.329 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.329&r2=text&tr2=1.328&f=h - xlog_rec_header/xlog_rec_ext_header endianess annotations From owner-xfs@oss.sgi.com Mon Oct 1 22:26:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 22:26:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l925QPFR025693 for ; Mon, 1 Oct 2007 22:26:28 -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 PAA21822; Tue, 2 Oct 2007 15:26:21 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id B4D1058C38F1; Tue, 2 Oct 2007 15:26:21 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970852 - kill xfs_iocore_t Message-Id: <20071002052621.B4D1058C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 15:26:21 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13207 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs kill xfs_iocore_t xfs_iocore_t is a structure embedded in xfs_inode. Except for one field it just duplicates fields already in xfs_inode, and there is nothing this abstraction buys us on XFS/Linux. This patch removes it and shrinks source and binary size of xfs aswell as shrinking the size of xfs_inode by 60/44 bytes in debug/non-debug builds. Signed-off-by: Christoph Hellwig Date: Fri Sep 21 17:16:44 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-hch Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29754a fs/xfs/xfsidbg.c - 1.334 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.334&r2=text&tr2=1.333&f=h fs/xfs/xfs_rw.h - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.h.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h fs/xfs/xfs_vnodeops.c - 1.723 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.723&r2=text&tr2=1.722&f=h fs/xfs/xfs_iocore.c - 1.55 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h fs/xfs/xfs_dfrag.c - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h fs/xfs/xfs_iget.c - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h fs/xfs/xfs_mount.h - 1.255 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.255&r2=text&tr2=1.254&f=h fs/xfs/xfs_inode.c - 1.482 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.482&r2=text&tr2=1.481&f=h fs/xfs/xfs_inode.h - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h fs/xfs/Makefile-linux-2.6 - 1.214 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h fs/xfs/xfs_iomap.c - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h fs/xfs/linux-2.6/xfs_lrw.h - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h fs/xfs/linux-2.6/xfs_lrw.c - 1.270 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.270&r2=text&tr2=1.269&f=h fs/xfs/linux-2.6/xfs_aops.c - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h fs/xfs/linux-2.6/xfs_ksyms.c - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h fs/xfs/dmapi/xfs_dm.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h - kill xfs_iocore_t From owner-xfs@oss.sgi.com Mon Oct 1 22:27:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 22:27:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l925RYkh025863 for ; Mon, 1 Oct 2007 22:27: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 PAA21836; Tue, 2 Oct 2007 15:27:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id E0DD358C38F1; Tue, 2 Oct 2007 15:27:29 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970980 - simplify xfs_vn_getattr Message-Id: <20071002052729.E0DD358C38F1@chook.melbourne.sgi.com> Date: Tue, 2 Oct 2007 15:27:29 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13208 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs simplify xfs_vn_getattr Just fill in struct kstat directly from the xfs_inode instead of doing a detour through a bhv_vattr_t and xfs_getattr. Signed-off-by: Christoph Hellwig Date: Tue Sep 25 14:51:00 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-hch Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29770a fs/xfs/linux-2.6/xfs_iops.c - 1.265 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.265&r2=text&tr2=1.264&f=h - simplify xfs_vn_getattr From owner-xfs@oss.sgi.com Mon Oct 1 22:55:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 22:55:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l925tIxJ028639 for ; Mon, 1 Oct 2007 22:55:20 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA22610; Tue, 2 Oct 2007 15:55:11 +1000 Message-ID: <4701DD3F.1000104@sgi.com> Date: Tue, 02 Oct 2007 15:55:11 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andi Kleen CC: Martin Steigerwald , xfs@oss.sgi.com Subject: Re: Creation time in XFS References: <200709302124.38164.Martin@lichtvoll.de> <470042DC.2040009@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4451/Mon Oct 1 21:12:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13209 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 Andi Kleen wrote: > Timothy Shimmin writes: > >> No XFS does not support creation time. It just has the regular >> atime,mtime and ctime. >> There are no plans that I've heard to support it. >> Not much involved to support it AFAICT but it would either involve >> changing the ondisk format of the inode or storing it in an EA. > > If you ever change the on disk format adding a file type similar to ext3 > to directories could also greatly speed up find in many cases. > Sounds a good idea. In that case a new ondisk directory format (at v2 at the moment). I think Dave (dgc) might have been mentioning something about that recently. --Tim From owner-xfs@oss.sgi.com Mon Oct 1 23:59:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 01 Oct 2007 23:59:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l926xlHN003067 for ; Mon, 1 Oct 2007 23:59:51 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23791; Tue, 2 Oct 2007 16:59:36 +1000 Message-ID: <4701ED51.8050706@sgi.com> Date: Tue, 02 Oct 2007 17:03:45 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Timothy Shimmin CC: Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> In-Reply-To: <4701A1D0.5010709@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13210 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Eric Sandeen wrote: >> Tim Shimmin wrote: >>> Hi Linus, >>> >>> A problem has been found for the XFS commit >>> b394e43e995d08821588a22561c6a71a63b4ff27 >>> and it needs to be reverted. >>> It has the potential for worse corruption than what it is meant to fix. >> >> >> Whoops... that's what I get for picking it up too soon for fedora I >> guess! >> >> Any background on the newly-found problem, for those of us in the peanut >> gallery? >> >> Thanks, >> >> -Eric > > Hi Eric, > > Lachlan worked this problem so he can probably provide more details. > My understanding is that we were having a problem with the log replay > replaying newly allocated inodes (inodes from buffer items) over the top > of buffers which were actually more up-to-date than what was logged. > The code used a heuristic to determine if the buffer had been written > to for the inode (by checking on magic#, mode and gen# - not going to > comment on this). > Anyway, it comes down to either copying over the inode buf data or not > copying it over (doing or not doing the log replay). > The change could cause the buffer to be not overwritten in replay > where previously it would be. > We want this to not happen as part of the fix and doing the right thing > and not by mistake and failing to replay when we need it to be replayed. > I presume the latter is what is happening. > The symptoms of this is what Lachlan has discovered in QA on a debug > kernel and he can provide the details. > > I believe this started from not logging the inode size changes > (as is consistent with the logging model) for performance reasons, > and so we can't rely on inode log items coming up on log replay > to fix things up. > > BTW, we currently have 3 ways of logging an inode: > 1. in an item buffer and marked as an inode > 2. in an item buffer and not marked as an inode > 3. in an inode item > > and 3 places where they get replayed: > 1. xlog_recover_do_inode_buffer - for di_next_unlinked pointer recovery > 2. xlog_recover_do_reg_buffer - for newly allocated inode recovery > 3. xlog_recover_do_inode_trans - for general inode recovery > > The fix was in #2. > > > Ughh. Yeah that about sums it up. In an attempt to prevent log replay of inodes in cases when we shouldn't replay we also prevented log replay of inodes in cases when we should replay. We end up with directories that refer to inodes that were not replayed and we read existing data off disk. That existing data is usually previous instances of inodes. We had cases of regular files turning into directories and inode version mismatches. Lachlan From owner-xfs@oss.sgi.com Tue Oct 2 00:08:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 00:08:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9278IUp006241 for ; Tue, 2 Oct 2007 00:08:20 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 RAA24017; Tue, 2 Oct 2007 17:08:17 +1000 Date: Tue, 02 Oct 2007 17:08:59 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: xfs_reno From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------CjDhNP1TBpgHu0GSrkBaa0 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13211 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------CjDhNP1TBpgHu0GSrkBaa0 Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The attached tool allows an inode64 filesystem to be converted to inode32. For this to work, the filesystem has to be mounted inode32 before it's run. I'm not sure if there is any packaging changes required. Barry. ------------CjDhNP1TBpgHu0GSrkBaa0 Content-Disposition: attachment; filename=xfs_reno.patch Content-Type: application/octet-stream; name=xfs_reno.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNkdW1wL01ha2Vm aWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEveGZz ZHVtcC9NYWtlZmlsZQkyMDA3LTEwLTAyIDE3OjA2OjI0LjAwMDAwMDAwMCAr MTAwMAorKysgYi94ZnNkdW1wL01ha2VmaWxlCTIwMDctMDktMTQgMTc6MzE6 MzEuOTE2NDM3MTQwICsxMDAwCkBAIC0xNiw3ICsxNiw3IEBACiAJTG9ncy8q IGJ1aWx0IC5jZW5zdXMgaW5zdGFsbC4qIGluc3RhbGwtZGV2LiogKi5negog CiBTVUJESVJTID0gaW5jbHVkZSBsaWJybXQgXAotCWNvbW1vbiBlc3RpbWF0 ZSBmc3IgaW52ZW50b3J5IGludnV0aWwgZHVtcCByZXN0b3JlIFwKKwljb21t b24gZXN0aW1hdGUgZnNyIGludmVudG9yeSBpbnZ1dGlsIGR1bXAgcmVubyBy ZXN0b3JlIFwKIAltNCBtYW4gZG9jIHBvIGRlYmlhbiBidWlsZAogCiBkZWZh dWx0OiAkKENPTkZJR1VSRSkKCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQp4ZnNkdW1wL3Jlbm8vTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09CgotLS0gYS94ZnNkdW1wL3Jlbm8vTWFrZWZpbGUJMjAw Ni0wNi0xNyAwMDo1ODoyNC4wMDAwMDAwMDAgKzEwMDAKKysrIGIveGZzZHVt cC9yZW5vL01ha2VmaWxlCTIwMDctMTAtMDIgMTc6MDY6MTguNjU4MzIwNzM4 ICsxMDAwCkBAIC0wLDAgKzEsMTkgQEAKKyMKKyMgQ29weXJpZ2h0IChjKSAy MDA3IFNpbGljb24gR3JhcGhpY3MsIEluYy4gIEFsbCBSaWdodHMgUmVzZXJ2 ZWQuCisjCisKK1RPUERJUiA9IC4uCitpbmNsdWRlICQoVE9QRElSKS9pbmNs dWRlL2J1aWxkZGVmcworCitMVENPTU1BTkQgPSB4ZnNfcmVubworQ0ZJTEVT ID0geGZzX3Jlbm8uYworTExETElCUyA9ICQoTElCQVRUUikKKworZGVmYXVs dDogJChMVENPTU1BTkQpCisKK2luY2x1ZGUgJChCVUlMRFJVTEVTKQorCitp bnN0YWxsOiBkZWZhdWx0CisJJChJTlNUQUxMKSAtbSA3NTUgLWQgJChQS0df QklOX0RJUikKKwkkKExUSU5TVEFMTCkgLW0gNzU1ICQoTFRDT01NQU5EKSAk KFBLR19CSU5fRElSKQoraW5zdGFsbC1kZXY6Cgo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KeGZzZHVtcC9yZW5vL3hmc19yZW5vLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09CgotLS0gYS94ZnNkdW1wL3Jlbm8v eGZzX3Jlbm8uYwkyMDA2LTA2LTE3IDAwOjU4OjI0LjAwMDAwMDAwMCArMTAw MAorKysgYi94ZnNkdW1wL3Jlbm8veGZzX3Jlbm8uYwkyMDA3LTEwLTAyIDE3 OjA1OjM4LjQwMzU1NjI2MCArMTAwMApAQCAtMCwwICsxLDE4NDEgQEAKKy8q CisgKiBDb3B5cmlnaHQgKGMpIDIwMDcgU2lsaWNvbiBHcmFwaGljcywgSW5j LgorICogQWxsIFJpZ2h0cyBSZXNlcnZlZC4KKyAqCisgKiBUaGlzIHByb2dy YW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQg YW5kL29yCisgKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBH TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcworICogcHVibGlzaGVkIGJ5 IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBw cm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd291 bGQgYmUgdXNlZnVsLAorICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3 aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNI QU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4gIFNlZSB0aGUKKyAqIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZv ciBtb3JlIGRldGFpbHMuCisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2Vp dmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK KyAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRo ZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sCisgKiBJbmMuLCAgNTEgRnJh bmtsaW4gU3QsIEZpZnRoIEZsb29yLCBCb3N0b24sIE1BICAwMjExMC0xMzAx ICBVU0EKKyAqLworCisvKgorICogeGZzX3Jlbm8gLSByZW51bWJlciA2NC1i aXQgaW5vZGVzCisgKgorICogeGZzX3Jlbm8gWy1mXSBbLW5dIFstcF0gWy1x XSBbLXZdIFstUCBzZWNvbmRzXSBwYXRoIC4uLgorICogeGZzX3Jlbm8gWy1y XSBwYXRoIC4uLgorICoKKyAqIFJlbnVtYmVycyBhbGwgaW5vZGVzID4gMzIg Yml0cyBpbnRvIDMyIGJpdCBzcGFjZS4gUmVxdWlyZXMgdGhlIGZpbGVzeXRl bQorICogdG8gYmUgbW91bnRlZCB3aXRoIGlub2RlMzIuCisgKgorICoJLWYJ CWZvcmNlIGNvbnZlcnNpb24gb24gYWxsIGlub2RlcyByYXRoZXIgdGhhbiBq dXN0CisgKgkJCXRob3NlIHdpdGggYSA2NGJpdCBpbm9kZSBudW1iZXIuCisg KgktbgkJbm90aGluZywgZG8gbm90IHJlbnVtYmVyIGlub2RlcworICoJLXAJ CXNob3cgcHJvZ3Jlc3Mgc3RhdHVzLgorICoJLXEJCXF1aWV0LCBkbyBub3Qg cmVwb3J0IHByb2dyZXNzLCBvbmx5IGVycm9ycy4KKyAqCS12CQl2ZXJib3Nl LCBtb3JlIC12J3MgbW9yZSB2ZXJib3NlLgorICoJLVAgc2Vjb25kcwlzZXQg dGhlIGludGVydmFsIGZvciB0aGUgcHJvZ3Jlc3Mgc3RhdHVzIGluIHNlY29u ZHMuCisgKgktcgkJcmVjb3ZlciBmcm9tIGFuIGludGVycnVwdGVkIHJ1bi4K KyAqLworCisjaW5jbHVkZSA8eGZzL3hmcy5oPgorCisjaW5jbHVkZSA8ZGly ZW50Lmg+CisjaW5jbHVkZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxmY250bC5o PgorI2luY2x1ZGUgPGZ0dy5oPgorI2luY2x1ZGUgPGxpYmdlbi5oPgorI2lu Y2x1ZGUgPG1hbGxvYy5oPgorI2luY2x1ZGUgPHNpZ25hbC5oPgorI2luY2x1 ZGUgPHN0ZGludC5oPgorI2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1 ZGUgPGF0dHIvYXR0cmlidXRlcy5oPgorI2luY2x1ZGUgPHhmcy94ZnNfZGZy YWcuaD4KKyNpbmNsdWRlIDx4ZnMveGZzX2ludW0uaD4KKworI2RlZmluZSBB VFRSQlVGU0laRQkxMDI0CisKKyNkZWZpbmUgU0NBTl9QSEFTRQkweDAwCisj ZGVmaW5lIERJUl9QSEFTRQkweDEwCS8qIG5vdGhpbmcgZG9uZSBvciBhbGwg ZG9uZSAqLworI2RlZmluZSBESVJfUEhBU0VfMQkweDExCS8qIHRhcmdldCBk aXIgY3JlYXRlZCAqLworI2RlZmluZSBESVJfUEhBU0VfMgkweDEyCS8qIHRl bXAgZGlyIGNyZWF0ZWQgKi8KKyNkZWZpbmUgRElSX1BIQVNFXzMJMHgxMwkv KiBhdHRyaWJ1dGVzIGJhY2tlZCB1cCB0byB0ZW1wICovCisjZGVmaW5lIERJ Ul9QSEFTRV80CTB4MTQJLyogZGlyZW50cyBtb3ZlZCB0byB0YXJnZXQgZGly ICovCisjZGVmaW5lIERJUl9QSEFTRV81CTB4MTUJLyogYXR0cmlidXRlcyBh cHBsaWVkIHRvIHRhcmdldCBkaXIgKi8KKyNkZWZpbmUgRElSX1BIQVNFXzYJ MHgxNgkvKiBzcmMgZGlyIHJlbW92ZWQgKi8KKyNkZWZpbmUgRElSX1BIQVNF XzcJMHgxNwkvKiB0ZW1wIGRpciByZW1vdmVkICovCisjZGVmaW5lIERJUl9Q SEFTRV9NQVgJMHgxNworI2RlZmluZSBGSUxFX1BIQVNFCTB4MjAJLyogbm90 aGluZyBkb25lIG9yIGFsbCBkb25lICovCisjZGVmaW5lIEZJTEVfUEhBU0Vf MQkweDIxCS8qIHRlbXAgZmlsZSBjcmVhdGVkICovCisjZGVmaW5lIEZJTEVf UEhBU0VfMgkweDIyCS8qIHN3YXBwZWQgZXh0ZW50cyAqLworI2RlZmluZSBG SUxFX1BIQVNFXzMJMHgyMwkvKiB1bmxpbmtlZCBzb3VyY2UgKi8KKyNkZWZp bmUgRklMRV9QSEFTRV80CTB4MjQJLyogcmVuYW1lZCB0ZW1wIHRvIHNvdXJj ZSBuYW1lICovCisjZGVmaW5lIEZJTEVfUEhBU0VfTUFYCTB4MjQKKworc3Rh dGljIHZvaWQgdXBkYXRlX3JlY292ZXJmaWxlKHZvaWQpOworI2RlZmluZSBT RVRfUEhBU0UoeCkJKGN1cl9waGFzZSA9IHgsIHVwZGF0ZV9yZWNvdmVyZmls ZSgpKQorCisjZGVmaW5lIExPR19FUlIJCTAKKyNkZWZpbmUgTE9HX05PUk1B TAkxCisjZGVmaW5lIExPR19JTkZPCTIKKyNkZWZpbmUgTE9HX0RFQlVHCTMK KyNkZWZpbmUgTE9HX05JVFRZCTQKKworI2RlZmluZSBOSF9CVUNLRVRTCTY1 NTM2CisjZGVmaW5lIE5IX0hBU0goaW5vKQkobm9kZWhhc2ggKyAoKGlubykg JSBOSF9CVUNLRVRTKSkKKwordHlwZWRlZiBzdHJ1Y3QgeworCXhmc19pbm9f dAlpbm87CisJaW50CQlmdHdfZmxhZ3M7CisJbmxpbmtfdAkJbnVtcGF0aHM7 CisJY2hhcgkJKipwYXRoczsKK30gYmlnbm9kZV90OworCit0eXBlZGVmIHN0 cnVjdCB7CisJYmlnbm9kZV90CSpub2RlczsKKwl1aW50NjRfdAlsaXN0bGVu OworCXVpbnQ2NF90CWxhc3Rub2RlOworfSBub2RlbGlzdF90OworCitzdGF0 aWMgY29uc3QgY2hhcgkqY21kX3ByZWZpeCA9ICJ4ZnNfcmVub18iOworCitz dGF0aWMgY2hhcgkJKnByb2duYW1lOworc3RhdGljIGludAkJbG9nX2xldmVs ID0gTE9HX05PUk1BTDsKK3N0YXRpYyBpbnQJCWZvcmNlX2FsbDsKK3N0YXRp YyBub2RlbGlzdF90CSpub2RlaGFzaDsKK3N0YXRpYyBpbnQJCXJlYWx1aWQ7 CitzdGF0aWMgdWludDY0X3QJCW51bWRpcm5vZGVzOworc3RhdGljIHVpbnQ2 NF90CQludW1maWxlbm9kZXM7CitzdGF0aWMgdWludDY0X3QJCW51bWRpcnNk b25lOworc3RhdGljIHVpbnQ2NF90CQludW1maWxlc2RvbmU7CitzdGF0aWMg aW50CQlwb2xsX2ludGVydmFsOworc3RhdGljIHRpbWVfdAkJc3RhcnR0aW1l Oworc3RhdGljIGJpZ25vZGVfdAkqY3VyX25vZGU7CitzdGF0aWMgY2hhcgkJ KmN1cl90YXJnZXQ7CitzdGF0aWMgY2hhcgkJKmN1cl90ZW1wOworc3RhdGlj IGludAkJY3VyX3BoYXNlOworc3RhdGljIGludAkJaGlnaGVzdF9udW1wYXRo czsKK3N0YXRpYyBjaGFyCQkqcmVjb3Zlcl9maWxlOworc3RhdGljIGludAkJ cmVjb3Zlcl9mZDsKK3N0YXRpYyB2b2xhdGlsZSBpbnQJcG9sbF9vdXRwdXQ7 CitzdGF0aWMgaW50CQlnbG9iYWxfcnZhbDsKKworLyoKKyAqIG1lc3NhZ2Ug aGFuZGxpbmcKKyAqLworc3RhdGljIHZvaWQKK2xvZ19tZXNzYWdlKAorCWlu dAkJbGV2ZWwsCisJY2hhcgkJKmZtdCwgLi4uKQoreworCWNoYXIJCWJ1Zlsx MDI0XTsKKwl2YV9saXN0CQlhcDsKKworCWlmIChsb2dfbGV2ZWwgPCBsZXZl bCkKKwkJcmV0dXJuOworCisJdmFfc3RhcnQoYXAsIGZtdCk7CisJdnNucHJp bnRmKGJ1ZiwgMTAyNCwgZm10LCBhcCk7CisJdmFfZW5kKGFwKTsKKworCXBy aW50ZigiJWMlczogJXNcbiIsIHBvbGxfb3V0cHV0ID8gJ1xuJyA6ICdccics IHByb2duYW1lLCBidWYpOworCXBvbGxfb3V0cHV0ID0gMDsKK30KKworc3Rh dGljIHZvaWQKK2Vycl9tZXNzYWdlKAorCWNoYXIJCSpmbXQsIC4uLikKK3sK KwljaGFyCQlidWZbMTAyNF07CisJdmFfbGlzdAkJYXA7CisKKwl2YV9zdGFy dChhcCwgZm10KTsKKwl2c25wcmludGYoYnVmLCAxMDI0LCBmbXQsIGFwKTsK Kwl2YV9lbmQoYXApOworCisJZnByaW50ZihzdGRlcnIsICIlYyVzOiAlc1xu IiwgcG9sbF9vdXRwdXQgPyAnXG4nIDogJ1xyJywgcHJvZ25hbWUsIGJ1Zik7 CisJcG9sbF9vdXRwdXQgPSAwOworfQorCitzdGF0aWMgdm9pZAorZXJyX25v bWVtKHZvaWQpCit7CisJZXJyX21lc3NhZ2UoXygiT3V0IG9mIG1lbW9yeSIp KTsKK30KKworc3RhdGljIHZvaWQKK2Vycl9vcGVuKAorCWNvbnN0IGNoYXIJ KnMpCit7CisJZXJyX21lc3NhZ2UoXygiQ2Fubm90IG9wZW4gJXM6ICVzIiks IHMsIHN0cmVycm9yKGVycm5vKSk7Cit9CisKK3N0YXRpYyB2b2lkCitlcnJf bm90X3hmcygKKwljb25zdCBjaGFyIAkqcykKK3sKKwllcnJfbWVzc2FnZShf KCIlcyBpcyBub3Qgb24gYW4gWEZTIGZpbGVzeXN0ZW0iKSwgcyk7Cit9CisK K3N0YXRpYyB2b2lkCitlcnJfc3RhdCgKKwljb25zdCBjaGFyCSpzKQorewor CWVycl9tZXNzYWdlKF8oIkNhbm5vdCBzdGF0ICVzOiAlc1xuIiksIHMsIHN0 cmVycm9yKGVycm5vKSk7Cit9CisKKy8qCisgKiB1c2FnZSBtZXNzYWdlCisg Ki8KK3N0YXRpYyB2b2lkCit1c2FnZSh2b2lkKQoreworCWZwcmludGYoc3Rk ZXJyLCBfKCIlcyBbLWZucHF2XSBbLVAgPGludGVydmFsPl0gWy1yXSA8cGF0 aD5cbiIpLAorCQkJcHJvZ25hbWUpOworCWV4aXQoMSk7Cit9CisKKworLyoK KyAqIFhGUyBpbnRlcmZhY2UgZnVuY3Rpb25zCisgKi8KKworc3RhdGljIGlu dAoreGZzX2J1bGtzdGF0X3NpbmdsZShpbnQgZmQsIHhmc19pbm9fdCAqbGFz dGlwLCB4ZnNfYnN0YXRfdCAqdWJ1ZmZlcikKK3sKKwl4ZnNfZnNvcF9idWxr cmVxX3QgIGJ1bGtyZXE7CisKKwlidWxrcmVxLmxhc3RpcCA9IChfX3U2NCAq KWxhc3RpcDsKKwlidWxrcmVxLmljb3VudCA9IDE7CisJYnVsa3JlcS51YnVm ZmVyID0gdWJ1ZmZlcjsKKwlidWxrcmVxLm9jb3VudCA9IE5VTEw7CisJcmV0 dXJuIGlvY3RsKGZkLCBYRlNfSU9DX0ZTQlVMS1NUQVRfU0lOR0xFLCAmYnVs a3JlcSk7Cit9CisKK3N0YXRpYyBpbnQKK3hmc19zd2FwZXh0KGludCBmZCwg eGZzX3N3YXBleHRfdCAqc3gpCit7CisJcmV0dXJuIGlvY3RsKGZkLCBYRlNf SU9DX1NXQVBFWFQsIHN4KTsKK30KKworc3RhdGljIGludAoreGZzX2dldHhh dHRyKGludCBmZCwgc3RydWN0IGZzeGF0dHIgKmF0dHIpCit7CisJcmV0dXJu IGlvY3RsKGZkLCBYRlNfSU9DX0ZTR0VUWEFUVFIsIGF0dHIpOworfQorCitz dGF0aWMgaW50Cit4ZnNfc2V0eGF0dHIoaW50IGZkLCBzdHJ1Y3QgZnN4YXR0 ciAqYXR0cikKK3sKKwlyZXR1cm4gaW9jdGwoZmQsIFhGU19JT0NfRlNTRVRY QVRUUiwgYXR0cik7Cit9CisKKy8qCisgKiBBIGhhc2ggdGFibGUgb2YgaW5v ZGUgbnVtYmVycyBhbmQgYXNzb2NpYXRlZCBwYXRocy4KKyAqLworc3RhdGlj IG5vZGVsaXN0X3QgKgoraW5pdF9ub2RlaGFzaCh2b2lkKQoreworCWludAkJ aTsKKworCW5vZGVoYXNoID0gY2FsbG9jKE5IX0JVQ0tFVFMsIHNpemVvZihu b2RlbGlzdF90KSk7CisJaWYgKG5vZGVoYXNoID09IE5VTEwpIHsKKwkJZXJy X25vbWVtKCk7CisJCXJldHVybiBOVUxMOworCX0KKworCWZvciAoaSA9IDA7 IGkgPCBOSF9CVUNLRVRTOyBpKyspIHsKKwkJbm9kZWhhc2hbaV0ubm9kZXMg PSBOVUxMOworCQlub2RlaGFzaFtpXS5sYXN0bm9kZSA9IDA7CisJCW5vZGVo YXNoW2ldLmxpc3RsZW4gPSAwOworCX0KKworCXJldHVybiBub2RlaGFzaDsK K30KKworc3RhdGljIHZvaWQKK2ZyZWVfbm9kZWhhc2godm9pZCkKK3sKKwlp bnQJCWksIGosIGs7CisKKwlmb3IgKGkgPSAwOyBpIDwgTkhfQlVDS0VUUzsg aSsrKSB7CisJCWJpZ25vZGVfdCAqbm9kZXMgPSBub2RlaGFzaFtpXS5ub2Rl czsKKworCQlmb3IgKGogPSAwOyBqIDwgbm9kZWhhc2hbaV0ubGFzdG5vZGU7 IGorKykgeworCQkJZm9yIChrID0gMDsgayA8IG5vZGVzW2pdLm51bXBhdGhz OyBrKyspIHsKKwkJCQlmcmVlKG5vZGVzW2pdLnBhdGhzW2tdKTsKKwkJCX0K KwkJCWZyZWUobm9kZXNbal0ucGF0aHMpOworCQl9CisKKwkJZnJlZShub2Rl cyk7CisJfQorCWZyZWUobm9kZWhhc2gpOworfQorCitzdGF0aWMgbmxpbmtf dAorYWRkX3BhdGgoCisJYmlnbm9kZV90CSpub2RlLAorCWNvbnN0IGNoYXIJ KnBhdGgpCit7CisJbm9kZS0+cGF0aHMgPSByZWFsbG9jKG5vZGUtPnBhdGhz LAorCQkJICAgICAgc2l6ZW9mKGNoYXIgKikgKiAobm9kZS0+bnVtcGF0aHMg KyAxKSk7CisJaWYgKG5vZGUtPnBhdGhzID09IE5VTEwpIHsKKwkJZXJyX25v bWVtKCk7CisJCWV4aXQoMSk7CisJfQorCisJbm9kZS0+cGF0aHNbbm9kZS0+ bnVtcGF0aHNdID0gc3RyZHVwKHBhdGgpOworCWlmIChub2RlLT5wYXRoc1tu b2RlLT5udW1wYXRoc10gPT0gTlVMTCkgeworCQllcnJfbm9tZW0oKTsKKwkJ ZXhpdCgxKTsKKwl9CisKKwlub2RlLT5udW1wYXRocysrOworCWlmIChub2Rl LT5udW1wYXRocyA+IGhpZ2hlc3RfbnVtcGF0aHMpCisJCWhpZ2hlc3RfbnVt cGF0aHMgPSBub2RlLT5udW1wYXRoczsKKworCXJldHVybiBub2RlLT5udW1w YXRoczsKK30KKworc3RhdGljIGJpZ25vZGVfdCAqCithZGRfbm9kZSgKKwlu b2RlbGlzdF90CSpsaXN0LAorCXhmc19pbm9fdAlpbm8sCisJaW50CQlmdHdf ZmxhZ3MsCisJY29uc3QgY2hhcgkqcGF0aCkKK3sKKwliaWdub2RlX3QJKm5v ZGU7CisKKwlpZiAobGlzdC0+bGFzdG5vZGUgPj0gbGlzdC0+bGlzdGxlbikg eworCQlsaXN0LT5saXN0bGVuICs9IDUwMDsKKwkJbGlzdC0+bm9kZXMgPSBy ZWFsbG9jKGxpc3QtPm5vZGVzLAorCQkJCQlzaXplb2YoYmlnbm9kZV90KSAq IGxpc3QtPmxpc3RsZW4pOworCQlpZiAobGlzdC0+bm9kZXMgPT0gTlVMTCkg eworCQkJZXJyX25vbWVtKCk7CisJCQlyZXR1cm4gTlVMTDsKKwkJfQorCX0K KworCW5vZGUgPSBsaXN0LT5ub2RlcyArIGxpc3QtPmxhc3Rub2RlOworCisJ bm9kZS0+aW5vID0gaW5vOworCW5vZGUtPmZ0d19mbGFncyA9IGZ0d19mbGFn czsKKwlub2RlLT5wYXRocyA9IE5VTEw7CisJbm9kZS0+bnVtcGF0aHMgPSAw OworCWFkZF9wYXRoKG5vZGUsIHBhdGgpOworCisJbGlzdC0+bGFzdG5vZGUr KzsKKworCXJldHVybiBub2RlOworfQorCitzdGF0aWMgYmlnbm9kZV90ICoK K2ZpbmRfbm9kZSgKKwl4ZnNfaW5vX3QJaW5vKQoreworCWludAkJaTsKKwlu b2RlbGlzdF90CSpub2RlbGlzdDsKKwliaWdub2RlX3QJKm5vZGVzOworCisJ bm9kZWxpc3QgPSBOSF9IQVNIKGlubyk7CisJbm9kZXMgPSBub2RlbGlzdC0+ bm9kZXM7CisKKwlmb3IoaSA9IDA7IGkgPCBub2RlbGlzdC0+bGFzdG5vZGU7 IGkrKykgeworCQlpZiAobm9kZXNbaV0uaW5vID09IGlubykgeworCQkJcmV0 dXJuICZub2Rlc1tpXTsKKwkJfQorCX0KKworCXJldHVybiBOVUxMOworfQor CitzdGF0aWMgYmlnbm9kZV90ICoKK2FkZF9ub2RlX3BhdGgoCisJeGZzX2lu b190CWlubywKKwlpbnQJCWZ0d19mbGFncywKKwljb25zdCBjaGFyCSpwYXRo KQoreworCW5vZGVsaXN0X3QJKm5vZGVsaXN0OworCWJpZ25vZGVfdAkqbm9k ZTsKKworCWxvZ19tZXNzYWdlKExPR19OSVRUWSwgImFkZF9ub2RlX3BhdGg6 IGlubyAlbGx1LCBwYXRoICVzIiwgaW5vLCBwYXRoKTsKKworCW5vZGUgPSBm aW5kX25vZGUoaW5vKTsKKwlpZiAobm9kZSA9PSBOVUxMKSB7CisJCW5vZGVs aXN0ID0gTkhfSEFTSChpbm8pOworCQlyZXR1cm4gYWRkX25vZGUobm9kZWxp c3QsIGlubywgZnR3X2ZsYWdzLCBwYXRoKTsKKwl9CisKKwlhZGRfcGF0aChu b2RlLCBwYXRoKTsKKwlyZXR1cm4gbm9kZTsKK30KKworc3RhdGljIHZvaWQK K2R1bXBfbm9kZSgKKwljaGFyCQkqbXNnLAorCWJpZ25vZGVfdAkqbm9kZSkK K3sKKwlpbnQJCWs7CisKKwlpZiAobG9nX2xldmVsIDwgTE9HX0RFQlVHKQor CQlyZXR1cm47CisKKwlsb2dfbWVzc2FnZShMT0dfREVCVUcsICIlczogJWxs dSAlbGx1ICVzIiwgbXNnLCBub2RlLT5pbm8sCisJCQlub2RlLT5udW1wYXRo cywgbm9kZS0+cGF0aHNbMF0pOworCisJZm9yIChrID0gMTsgayA8IG5vZGUt Pm51bXBhdGhzOyBrKyspCisJCWxvZ19tZXNzYWdlKExPR19ERUJVRywgIlx0 JXMiLCBub2RlLT5wYXRoc1trXSk7Cit9CisKK3N0YXRpYyB2b2lkCitkdW1w X25vZGVoYXNoKHZvaWQpCit7CisJaW50CQlpLCBqOworCisJaWYgKGxvZ19s ZXZlbCA8IExPR19OSVRUWSkKKwkJcmV0dXJuOworCisJZm9yIChpID0gMDsg aSA8IE5IX0JVQ0tFVFM7IGkrKykgeworCQliaWdub2RlX3QJKm5vZGVzID0g bm9kZWhhc2hbaV0ubm9kZXM7CisJCWZvciAoaiA9IDA7IGogPCBub2RlaGFz aFtpXS5sYXN0bm9kZTsgaisrLCBub2RlcysrKQorCQkJZHVtcF9ub2RlKCJu b2RlaGFzaCIsIG5vZGVzKTsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2Zvcl9h bGxfbm9kZXMoCisJaW50CQkoKmZuKShiaWdub2RlX3QgKm5vZGUpLAorCWlu dAkJZnR3X2ZsYWdzLAorCWludAkJcXVpdF9vbl9lcnJvcikKK3sKKwlpbnQJ CWk7CisJaW50CQlqOworCWludAkJcnZhbCA9IDA7CisKKwlmb3IgKGkgPSAw OyBpIDwgTkhfQlVDS0VUUzsgaSsrKSB7CisJCWJpZ25vZGVfdAkqbm9kZXMg PSBub2RlaGFzaFtpXS5ub2RlczsKKworCQlmb3IgKGogPSAwOyBqIDwgbm9k ZWhhc2hbaV0ubGFzdG5vZGU7IGorKywgbm9kZXMrKykgeworCQkJaWYgKG5v ZGVzLT5mdHdfZmxhZ3MgPT0gZnR3X2ZsYWdzKSB7CisJCQkJcnZhbCA9IGZu KG5vZGVzKTsKKwkJCQlpZiAocnZhbCAmJiBxdWl0X29uX2Vycm9yKQorCQkJ CQlnb3RvIHF1aXQ7CisJCQl9CisJCX0KKwl9CisKK3F1aXQ6CisJcmV0dXJu IHJ2YWw7Cit9CisKKy8qCisgKiBBZGRzIGFwcHJvcHJpYXRlIGZpbGVzIHRv IHRoZSBpbm9kZSBoYXNoIHRhYmxlCisgKi8KK3N0YXRpYyBpbnQKK25mdHdf YWRkbm9kZXMoCisJY29uc3QgY2hhcgkqcGF0aCwKKwljb25zdCBzdHJ1Y3Qg c3RhdDY0ICpzdCwKKwlpbnQJCWZsYWdzLAorCXN0cnVjdCBGVFcJKnNudGZ3 KQoreworCWlmIChzdC0+c3RfaW5vIDw9IFhGU19NQVhJTlVNQkVSXzMyICYm ICFmb3JjZV9hbGwpCisJCXJldHVybiAwOworCisJaWYgKGZsYWdzID09IEZU V19GKQorCQludW1maWxlbm9kZXMrKzsKKwllbHNlIGlmIChmbGFncyA9PSBG VFdfRCkKKwkJbnVtZGlybm9kZXMrKzsKKwllbHNlCisJCXJldHVybiAwOwor CisJYWRkX25vZGVfcGF0aChzdC0+c3RfaW5vLCBmbGFncywgcGF0aCk7CisK KwlyZXR1cm4gMDsKK30KKworLyoKKyAqIEF0dHJpYnV0ZSBjbG9uaW5nIGNv ZGUgLSBtb3N0IG9mIHRoaXMgaXMgaGVyZSBiZWNhdXNlIGF0dHJfY29weSBk b2VzIG5vdAorICogbGV0IHVzIHBpY2sgYW5kIGNob29zZSB3aGljaCBhdHRy aWJ1dGVzIHdlIHdhbnQgdG8gY29weS4KKyAqLworCithdHRyX211bHRpb3Bf dAlhdHRyX29wc1tBVFRSX01BWF9NVUxUSU9QU107CisKKy8qCisgKiBHcmFi IGF0dHJpYnV0ZXMgc3BlY2lmaWVkIGluIGF0dHJfb3BzIGZyb20gc291cmNl IGZpbGUgYW5kIHdyaXRlIHRoZW0KKyAqIG91dCBvbiB0aGUgZGVzdGluYXRp b24gZmlsZS4KKyAqLworCitzdGF0aWMgaW50CithdHRyX3JlcGxpY2F0ZShp bnQgc3JjX2ZkLCBpbnQgZHN0X2ZkLCBpbnQgY291bnQpCit7CisJaW50CWos IGs7CisKKwlpZiAoYXR0cl9tdWx0aWYoc3JjX2ZkLCBhdHRyX29wcywgY291 bnQsIDApIDwgMCkKKwkJcmV0dXJuIC0xOworCisJZm9yIChrID0gMDsgayA8 IGNvdW50OyBrKyspIHsKKwkJaWYgKGF0dHJfb3BzW2tdLmFtX2Vycm9yKSB7 CisJCQllcnJfbWVzc2FnZShfKCJFcnJvciAlZCBnZXR0aW5nIGF0dHJpYnV0 ZSIpLAorCQkJCQlhdHRyX29wc1trXS5hbV9lcnJvcik7CisJCQlicmVhazsK KwkJfQorCQlhdHRyX29wc1trXS5hbV9vcGNvZGUgPSBBVFRSX09QX1NFVDsK Kwl9CisJaWYgKGF0dHJfbXVsdGlmKGRzdF9mZCwgYXR0cl9vcHMsIGssIDAp IDwgMCkKKwkJZXJyX21lc3NhZ2UoIm9uIGF0dHJfbXVsdGlmIHNldCIpOwor CWZvciAoaiA9IDA7IGogPCBrOyBqKyspIHsKKwkJaWYgKGF0dHJfb3BzW2pd LmFtX2Vycm9yKSB7CisJCQllcnJfbWVzc2FnZShfKCJFcnJvciAlZCBzZXR0 aW5nIGF0dHJpYnV0ZSIpLAorCQkJCQlhdHRyX29wc1tqXS5hbV9lcnJvcik7 CisJCQlyZXR1cm4gLTE7CisJCX0KKwl9CisKKwlyZXR1cm4gMDsKK30KKwor LyoKKyAqIENvcHkgYWxsIHRoZSBhdHRyaWJ1dGVzIHNwZWNpZmllZCBmcm9t IHNyYyB0byBkc3QuCisgKi8KKworc3RhdGljIGludAorYXR0cl9jbG9uZV9j b3B5KAorCWludAkJc3JjX2ZkLAorCWludAkJZHN0X2ZkLAorCWNoYXIJCSps aXN0X2J1ZiwKKwljaGFyCQkqYXR0cl9idWYsCisJaW50CQlidWZfbGVuLAor CWludAkJZmxhZ3MpCit7CisgICAgICAgIGF0dHJsaXN0X3QgCSphbGlzdDsK KyAgICAgICAgYXR0cmxpc3RfZW50X3QJKmF0dHI7CisgICAgICAgIGF0dHJs aXN0X2N1cnNvcl90IGN1cnNvcjsKKyAgICAgICAgaW50CQlzcGFjZSwgaSwg ajsKKwljaGFyCQkqcHRyOworCisgICAgICAgIGJ6ZXJvKChjaGFyICopJmN1 cnNvciwgc2l6ZW9mKGN1cnNvcikpOworICAgICAgICBkbyB7CisgICAgICAg ICAgICAgICAgaWYgKGF0dHJfbGlzdGYoc3JjX2ZkLCBsaXN0X2J1ZiwgQVRU UkJVRlNJWkUsIGZsYWdzLAorICAgICAgICAgICAgICAgIAkJJmN1cnNvcikg PCAwKSB7CisJCQllcnJfbWVzc2FnZSgib24gYXR0cl9saXN0ZiIpOworICAg ICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIDE7CisJCX0KKworICAgICAg ICAgICAgICAgIGFsaXN0ID0gKGF0dHJsaXN0X3QgKilsaXN0X2J1ZjsKKwor CQlzcGFjZSA9IGJ1Zl9sZW47CisJCXB0ciA9IGF0dHJfYnVmOworICAgICAg ICAgICAgICAgIGZvciAoaiA9IDAsIGkgPSAwOyBpIDwgYWxpc3QtPmFsX2Nv dW50OyBpKyspIHsKKyAgICAgICAgICAgICAgICAgICAgICAgIGF0dHIgPSBB VFRSX0VOVFJZKGxpc3RfYnVmLCBpKTsKKwkJCWlmIChzcGFjZSA8IGF0dHIt PmFfdmFsdWVsZW4pIHsKKwkJCQlhdHRyX3JlcGxpY2F0ZShzcmNfZmQsIGRz dF9mZCwgaik7CisJCQkJaiA9IDA7CisJCQkJc3BhY2UgPSBidWZfbGVuOwor CQkJCXB0ciA9IGF0dHJfYnVmOworCQkJfQorCQkJYXR0cl9vcHNbal0uYW1f b3Bjb2RlID0gQVRUUl9PUF9HRVQ7CisJCQlhdHRyX29wc1tqXS5hbV9hdHRy bmFtZSA9IGF0dHItPmFfbmFtZTsKKwkJCWF0dHJfb3BzW2pdLmFtX2F0dHJ2 YWx1ZSA9IHB0cjsKKwkJCWF0dHJfb3BzW2pdLmFtX2xlbmd0aCA9IChpbnQp IGF0dHItPmFfdmFsdWVsZW47CisJCQlhdHRyX29wc1tqXS5hbV9mbGFncyA9 IGZsYWdzOworCQkJYXR0cl9vcHNbal0uYW1fZXJyb3IgPSAwOworCQkJaisr OworCQkJcHRyICs9IGF0dHItPmFfdmFsdWVsZW47CisJCQlzcGFjZSAtPSBh dHRyLT5hX3ZhbHVlbGVuOworICAgICAgICAgICAgICAgIH0KKworCQlsb2df bWVzc2FnZShMT0dfTklUVFksICJjb3B5aW5nIGF0dHJpYnV0ZSAlZCIsIGkp OworCisJCWlmIChqKQorCQkJYXR0cl9yZXBsaWNhdGUoc3JjX2ZkLCBkc3Rf ZmQsIGopOworCisgICAgICAgIH0gd2hpbGUgKGFsaXN0LT5hbF9tb3JlKTsK KworICAgICAgICByZXR1cm4gMDsKK30KKworc3RhdGljIGludAorY2xvbmVf YXR0cmlicyhpbnQgaW5fZmQsIGludCBvdXRfZmQpCit7CisJY2hhcglsaXN0 X2J1ZltBVFRSQlVGU0laRV07CisJY2hhcgkqYXR0cl9idWY7CisKKwlhdHRy X2J1ZiA9IG1hbGxvYyhBVFRSX01BWF9WQUxVRUxFTiAqIDIpOworCWF0dHJf Y2xvbmVfY29weShpbl9mZCwgb3V0X2ZkLCBsaXN0X2J1ZiwKKwkJCWF0dHJf YnVmLCBBVFRSX01BWF9WQUxVRUxFTiAqIDIsIDApOworCWF0dHJfY2xvbmVf Y29weShpbl9mZCwgb3V0X2ZkLCBsaXN0X2J1ZiwKKwkJCWF0dHJfYnVmLCBB VFRSX01BWF9WQUxVRUxFTiAqIDIsIEFUVFJfUk9PVCk7CisJYXR0cl9jbG9u ZV9jb3B5KGluX2ZkLCBvdXRfZmQsIGxpc3RfYnVmLAorCQkJYXR0cl9idWYs IEFUVFJfTUFYX1ZBTFVFTEVOICogMiwgQVRUUl9TRUNVUkUpOworCWZyZWUo YXR0cl9idWYpOworCXJldHVybiAwOworfQorCitzdGF0aWMgaW50CitkdXBf YXR0cmlidXRlcygKKwljaGFyCQkqc291cmNlLAorCWludAkJc2ZkLAorCWNo YXIJCSp0YXJnZXQsCisJaW50CQl0ZmQpCit7CisJc3RydWN0IHN0YXQ2NAlz dDsKKwlzdHJ1Y3QgdGltZXZhbAl0dlsyXTsKKwlzdHJ1Y3QgZnN4YXR0cglm c3g7CisKKwlpZiAobHN0YXQ2NChzb3VyY2UsICZzdCkgPCAwKSB7CisJCWVy cl9zdGF0KHNvdXJjZSk7CisJCXJldHVybiAxOworCX0KKworCWlmICh4ZnNf Z2V0eGF0dHIoc2ZkLCAmZnN4KSA8IDApIHsKKwkJZXJyX3N0YXQoc291cmNl KTsKKwkJcmV0dXJuIDE7CisJfQorCisJdHZbMF0udHZfc2VjID0gc3Quc3Rf YXRpbS50dl9zZWM7CisJdHZbMF0udHZfdXNlYyA9IHN0LnN0X2F0aW0udHZf bnNlYyAvIDEwMDA7CisJdHZbMV0udHZfc2VjID0gc3Quc3RfbXRpbS50dl9z ZWM7CisJdHZbMV0udHZfdXNlYyA9IHN0LnN0X210aW0udHZfbnNlYyAvIDEw MDA7CisKKwlpZiAodXRpbWVzKHRhcmdldCwgdHYpIDwgMCkKKwkJZXJyX21l c3NhZ2UoXygiJXM6IENhbm5vdCB1cGRhdGUgdGFyZ2V0IHRpbWVzIiksIHRh cmdldCk7CisKKwlpZiAoY2hvd24odGFyZ2V0LCBzdC5zdF91aWQsIHN0LnN0 X2dpZCkgPCAwKSB7CisJCWVycl9tZXNzYWdlKF8oIiVzOiBDYW5ub3QgY2hh bmdlIHRhcmdldCBvd25lcnNoaXAgdG8gIgorCQkJInVpZCglZCkgZ2lkKCVk KSIpLCB0YXJnZXQsIHN0LnN0X3VpZCwgc3Quc3RfZ2lkKTsKKworCQlpZiAo Y2htb2QodGFyZ2V0LCBzdC5zdF9tb2RlICYgfihTX0lTVUlEIHwgU19JU0dJ RCkpIDwgMCkKKwkJCWVycl9tZXNzYWdlKF8oIiVzOiBDYW5ub3QgY2hhbmdl IHRhcmdldCBtb2RlICIKKwkJCQkJInRvICglbykiKSwgdGFyZ2V0LCBzdC5z dF9tb2RlKTsKKwl9IGVsc2UgaWYgKGNobW9kKHRhcmdldCwgc3Quc3RfbW9k ZSkgPCAwKQorCQllcnJfbWVzc2FnZShfKCIlczogQ2Fubm90IGNoYW5nZSB0 YXJnZXQgbW9kZSB0byAoJW8pIiksCisJCQkJdGFyZ2V0LCBzdC5zdF9tb2Rl KTsKKworCWlmICh4ZnNfc2V0eGF0dHIodGZkLCAmZnN4KSA8IDApCisJCWVy cl9tZXNzYWdlKF8oIiVzOiBDYW5uZXQgc2V0IHRhcmdldCBleHRlbmRlZCBh dHRyaWJ1dGVzIiksCisJCQkJdGFyZ2V0KTsKKworCXJldHVybiBjbG9uZV9h dHRyaWJzKHNmZCwgdGZkKTsKK30KKworc3RhdGljIGludAorbW92ZV9kaXJl bnRzKAorCWNoYXIJCSpzcmNwYXRoLAorCWNoYXIJCSp0YXJnZXRwYXRoLAor CWludAkJKm1vdmVfY291bnQpCit7CisJaW50CQlydmFsID0gMDsKKwlESVIJ CSpzcmNkOworCXN0cnVjdCBkaXJlbnQ2NAkqZHA7CisJY2hhcgkJc3JjbmFt ZVtQQVRIX01BWF07CisJY2hhcgkJdGFyZ2V0bmFtZVtQQVRIX01BWF07CisK KwkqbW92ZV9jb3VudCA9IDA7CisKKwlzcmNkID0gb3BlbmRpcihzcmNwYXRo KTsKKwlpZiAoc3JjZCA9PSBOVUxMKSB7CisJCWVycl9vcGVuKHNyY3BhdGgp OworCQlyZXR1cm4gMTsKKwl9CisKKwl3aGlsZSAoKGRwID0gcmVhZGRpcjY0 KHNyY2QpKSAhPSBOVUxMKSB7CisJCWlmIChkcC0+ZF9pbm8gPT0gMCB8fCAh c3RyY21wKGRwLT5kX25hbWUsICIuIikgfHwKKwkJCQkhc3RyY21wKGRwLT5k X25hbWUsICIuLiIpKQorCQkJY29udGludWU7CisKKwkJaWYgKHN0cmxlbihz cmNwYXRoKSArIDEgKyBzdHJsZW4oZHAtPmRfbmFtZSkgPj0KKwkJCQlzaXpl b2Yoc3JjbmFtZSkgLSAxKSB7CisKKwkJCWVycl9tZXNzYWdlKF8oIiVzLyVz OiBOYW1lIHRvbyBsb25nIiksIHNyY3BhdGgsCisJCQkJCWRwLT5kX25hbWUp OworCQkJcnZhbCA9IDE7CisJCQlnb3RvIHF1aXQ7CisJCX0KKworCQlzcHJp bnRmKHNyY25hbWUsICIlcy8lcyIsIHNyY3BhdGgsIGRwLT5kX25hbWUpOwor CQlzcHJpbnRmKHRhcmdldG5hbWUsICIlcy8lcyIsIHRhcmdldHBhdGgsIGRw LT5kX25hbWUpOworCisJCXJ2YWwgPSByZW5hbWUoc3JjbmFtZSwgdGFyZ2V0 bmFtZSk7CisJCWlmIChydmFsICE9IDApIHsKKwkJCWVycl9tZXNzYWdlKF8o ImZhaWxlZCB0byByZW5hbWU6IFwnJXNcJyB0byBcJyVzXCciKSwKKwkJCQkJ c3JjbmFtZSwgdGFyZ2V0bmFtZSk7CisJCQlnb3RvIHF1aXQ7CisJCX0KKwor CQlsb2dfbWVzc2FnZShMT0dfREVCVUcsICJyZW5hbWUgJXMgLT4gJXMiLCBz cmNuYW1lLCB0YXJnZXRuYW1lKTsKKworCQkoKm1vdmVfY291bnQpKys7CisJ fQorCitxdWl0OgorCWNsb3NlZGlyKHNyY2QpOworCXJldHVybiBydmFsOwor fQorCitzdGF0aWMgaW50Citwcm9jZXNzX2RpcigKKwliaWdub2RlX3QJKm5v ZGUpCit7CisJaW50CQlzZmQgPSAtMTsKKwlpbnQJCXRmZCA9IC0xOworCWlu dAkJdGFyZ2V0ZmQgPSAtMTsKKwlpbnQJCXJ2YWwgPSAwOworCWludAkJbW92 ZV9jb3VudCA9IDA7CisJY2hhcgkJKnNyY25hbWUgPSBOVUxMOworCWNoYXIJ CSpwbmFtZSA9IE5VTEw7CisJc3RydWN0IHN0YXQ2NAlzMTsKKwlzdHJ1Y3Qg ZnN4YXR0ciAgZnN4OworCWNoYXIJCXRhcmdldFtQQVRIX01BWF0gPSAiIjsK KworCVNFVF9QSEFTRShESVJfUEhBU0UpOworCisJZHVtcF9ub2RlKCJkaXJl Y3RvcnkiLCBub2RlKTsKKworCWN1cl9ub2RlID0gbm9kZTsKKwlzcmNuYW1l ID0gbm9kZS0+cGF0aHNbMF07CisKKwlpZiAoc3RhdDY0KHNyY25hbWUsICZz MSkgPCAwKSB7CisJCWlmIChlcnJubyAhPSBFTk9FTlQpIHsKKwkJCWVycl9z dGF0KHNyY25hbWUpOworCQkJZ2xvYmFsX3J2YWwgfD0gMjsKKwkJfQorCQln b3RvIHF1aXQ7CisJfQorCWlmIChzMS5zdF9pbm8gPD0gWEZTX01BWElOVU1C RVJfMzIgJiYgIWZvcmNlX2FsbCkgeworCQkvKgorCQkgKiBUaGlzIGRpcmVj dG9yeSBoYXMgYWxyZWFkeSBjaGFuZ2VkIGlubydzLCBwcm9iYWJseSBkdWUK KwkJICogdG8gYmVpbmcgbW92ZWQgZHVyaW5nIHByb2Nlc3Npbmcgb2YgYSBw YXJlbnQgZGlyZWN0b3J5LgorCQkgKi8KKwkJbG9nX21lc3NhZ2UoTE9HX0RF QlVHLCAicHJvY2Vzc19kaXI6IHNraXBwaW5nICVzIiwgc3JjbmFtZSk7CisJ CWdvdG8gcXVpdDsKKwl9CisKKwlydmFsID0gMTsKKworCXNmZCA9IG9wZW4o c3JjbmFtZSwgT19SRE9OTFkpOworCWlmIChzZmQgPCAwKSB7CisJCWVycl9v cGVuKHNyY25hbWUpOworCQlnb3RvIHF1aXQ7CisJfQorCisJaWYgKCFwbGF0 Zm9ybV90ZXN0X3hmc19mZChzZmQpKSB7CisJCWVycl9ub3RfeGZzKHNyY25h bWUpOworCQlnb3RvIHF1aXQ7CisJfQorCisJaWYgKHhmc19nZXR4YXR0cihz ZmQsICZmc3gpIDwgMCkgeworCQllcnJfbWVzc2FnZShfKCJmYWlsZWQgdG8g Z2V0IGlub2RlIGF0dHJzOiAlcyIpLCBzcmNuYW1lKTsKKwkJZ290byBxdWl0 OworCX0KKwlpZiAoZnN4LmZzeF94ZmxhZ3MgJiAoWEZTX1hGTEFHX0lNTVVU QUJMRSB8IFhGU19YRkxBR19BUFBFTkQpKSB7CisJCWVycl9tZXNzYWdlKF8o IiVzOiBpbW11dGFibGUvYXBwZW5kLCBpZ25vcmluZyIpLCBzcmNuYW1lKTsK KwkJZ2xvYmFsX3J2YWwgfD0gMjsKKwkJcnZhbCA9IDA7CisJCWdvdG8gcXVp dDsKKwl9CisKKwkvKiBta2RpciBwYXJlbnQvdGFyZ2V0ICovCisJcG5hbWUg PSBzdHJkdXAoc3JjbmFtZSk7CisJaWYgKHBuYW1lID09IE5VTEwpIHsKKwkJ ZXJyX25vbWVtKCk7CisJCWdvdG8gcXVpdDsKKwl9CisJZGlybmFtZShwbmFt ZSk7CisJc3ByaW50Zih0YXJnZXQsICIlcy8lc1hYWFhYWCIsIHBuYW1lLCBj bWRfcHJlZml4KTsKKwlpZiAobWtkdGVtcCh0YXJnZXQpID09IE5VTEwpIHsK KwkJZXJyX21lc3NhZ2UoXygiVW5hYmxlIHRvIGNyZWF0ZSBkaXJlY3Rvcnkg Y29weTogJXMiKSwgc3JjbmFtZSk7CisJCWdvdG8gcXVpdDsKKwl9CisJU0VU X1BIQVNFKERJUl9QSEFTRV8xKTsKKworCWN1cl90YXJnZXQgPSBzdHJkdXAo dGFyZ2V0KTsKKwlpZiAoIWN1cl90YXJnZXQpIHsKKwkJZXJyX25vbWVtKCk7 CisJCWdvdG8gcXVpdDsKKwl9CisKKwlzcHJpbnRmKHRhcmdldCwgIiVzLyVz WFhYWFhYIiwgcG5hbWUsIGNtZF9wcmVmaXgpOworCWlmIChta2R0ZW1wKHRh cmdldCkgPT0gTlVMTCkgeworCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8g Y3JlYXRlIHRtcCBkaXJlY3RvcnkgY29weSIpKTsKKwkJZ290byBxdWl0Owor CX0KKwlTRVRfUEhBU0UoRElSX1BIQVNFXzIpOworCisJY3VyX3RlbXAgPSBz dHJkdXAodGFyZ2V0KTsKKwlpZiAoIWN1cl90ZW1wKSB7CisJCWVycl9ub21l bSgpOworCQlnb3RvIHF1aXQ7CisJfQorCisJdGZkID0gb3BlbihjdXJfdGVt cCwgT19SRE9OTFkpOworCWlmICh0ZmQgPCAwKSB7CisJCWVycl9vcGVuKGN1 cl90ZW1wKTsKKwkJZ290byBxdWl0OworCX0KKworCXRhcmdldGZkID0gb3Bl bihjdXJfdGFyZ2V0LCBPX1JET05MWSk7CisJaWYgKHRmZCA8IDApIHsKKwkJ ZXJyX29wZW4oY3VyX3RhcmdldCk7CisJCWdvdG8gcXVpdDsKKwl9CisKKwor CS8qIGNvcHkgdGltZXN0YW1wcywgYXR0cmlicyBhbmQgRUFzLCB0byBjdXJf dGVtcCAqLworCXJ2YWwgPSBkdXBfYXR0cmlidXRlcyhzcmNuYW1lLCBzZmQs IGN1cl90ZW1wLCB0ZmQpOworCWlmIChydmFsICE9IDApIHsKKwkJZXJyX21l c3NhZ2UoXygidW5hYmxlIHRvIGR1cGxpY2F0ZSBkaXJlY3RvcnkgYXR0cmli dXRlczogJXMiKSwKKwkJCSAgICBzcmNuYW1lKTsKKwkJZ290byBxdWl0X3Vu bGluazsKKwl9CisKKwlTRVRfUEhBU0UoRElSX1BIQVNFXzMpOworCisJLyog bW92ZSBzcmMgZGlyZW50cyB0byBjdXJfdGFyZ2V0ICh0aGlzIGNoYW5nZXMg dGltZXN0YW1wcyBvbiBzcmMpICovCisJcnZhbCA9IG1vdmVfZGlyZW50cyhz cmNuYW1lLCBjdXJfdGFyZ2V0LCAmbW92ZV9jb3VudCk7CisJaWYgKHJ2YWwg IT0gMCkgeworCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8gbW92ZSBkaXJl Y3RvcnkgY29udGVudHM6ICVzIHRvICVzIiksCisJCQkJc3JjbmFtZSwgY3Vy X3RhcmdldCk7CisJCS8qIHVoIG9oLCBtb3ZlIGV2ZXJ5dGhpbmcgYmFjay4u LiAqLworCQlpZiAobW92ZV9jb3VudCA+IDApCisJCQlnb3RvIHF1aXRfdW5k bzsKKwl9CisKKwlTRVRfUEhBU0UoRElSX1BIQVNFXzQpOworCisJLyogY29w eSB0aW1lc3RhbXBzLCBhdHRyaWJzIGFuZCBFQXMgZnJvbSBjdXJfdGVtcCB0 byBjdXJfdGFyZ2V0ICovCisJcnZhbCA9IGR1cF9hdHRyaWJ1dGVzKGN1cl90 ZW1wLCB0ZmQsIGN1cl90YXJnZXQsIHRhcmdldGZkKTsKKwlpZiAocnZhbCAh PSAwKSB7CisJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBkdXBsaWNhdGUg ZGlyZWN0b3J5IGF0dHJpYnV0ZXM6ICVzIiksCisJCQkJY3VyX3RlbXApOwor CQlnb3RvIHF1aXRfdW5saW5rOworCX0KKworCVNFVF9QSEFTRShESVJfUEhB U0VfNSk7CisKKwkvKiBybWRpciBzcmMgKi8KKwlydmFsID0gcm1kaXIoc3Jj bmFtZSk7CisJaWYgKHJ2YWwgIT0gMCkgeworCQllcnJfbWVzc2FnZShfKCJ1 bmFibGUgdG8gcmVtb3ZlIGRpcmVjdG9yeTogJXMiKSwgc3JjbmFtZSk7CisJ CWdvdG8gcXVpdF91bmRvOworCX0KKworCVNFVF9QSEFTRShESVJfUEhBU0Vf Nik7CisKKwlydmFsID0gcm1kaXIoY3VyX3RlbXApOworCWlmIChydmFsICE9 IDApCisJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW1vdmUgdG1wIGRp cmVjdG9yeTogJXMiKSwgY3VyX3RlbXApOworCisJU0VUX1BIQVNFKERJUl9Q SEFTRV83KTsKKworCS8qIHJlbmFtZSBjdXJfdGFyZ2V0IHNyYyAqLworCXJ2 YWwgPSByZW5hbWUoY3VyX3RhcmdldCwgc3JjbmFtZSk7CisJaWYgKHJ2YWwg IT0gMCkgeworCQkvKgorCQkgKiB3ZSBjYW4ndCBhYm9ydCBzaW5jZSB0aGUg c3JjIGRpciBpcyBub3cgZ29uZS4KKwkJICogbGV0IHRoZSBhZG1pbiBjbGVh biB0aGlzIG9uZSB1cAorCQkgKi8KKwkJZXJyX21lc3NhZ2UoXygidW5hYmxl IHRvIHJlbmFtZSBkaXJlY3Rvcnk6ICVzIHRvICVzIiksCisJCQkJY3VyX3Rh cmdldCwgc3JjbmFtZSk7CisJfQorCWdvdG8gcXVpdDsKKworIHF1aXRfdW5k bzoKKwlpZiAobW92ZV9kaXJlbnRzKGN1cl90YXJnZXQsIHNyY25hbWUsICZt b3ZlX2NvdW50KSAhPSAwKSB7CisJCS8qIG9oLCBkZWFyIGxvcmQuLi4gbGV0 IHRoZSBhZG1pbiBjbGVhbiB0aGlzIG9uZSB1cCAqLworCQllcnJfbWVzc2Fn ZShfKCJ1bmFibGUgdG8gbW92ZSBkaXJlY3RvcnkgY29udGVudHMgYmFjazog JXMgdG8gJXMiKSwKKwkJCQljdXJfdGFyZ2V0LCBzcmNuYW1lKTsKKwkJZ290 byBxdWl0OworCX0KKwlTRVRfUEhBU0UoRElSX1BIQVNFXzMpOworCisgcXVp dF91bmxpbms6CisJcm1kaXIoY3VyX3RhcmdldCk7CisJcm1kaXIoY3VyX3Rl bXApOworCisgcXVpdDoKKworCVNFVF9QSEFTRShESVJfUEhBU0UpOworCisJ aWYgKHNmZCA+PSAwKQorCQljbG9zZShzZmQpOworCWlmICh0ZmQgPj0gMCkK KwkJY2xvc2UodGZkKTsKKwlpZiAodGFyZ2V0ZmQgPj0gMCkKKwkJY2xvc2Uo dGFyZ2V0ZmQpOworCisJZnJlZShwbmFtZSk7CisJZnJlZShjdXJfdGFyZ2V0 KTsKKwlmcmVlKGN1cl90ZW1wKTsKKworCWN1cl90YXJnZXQgPSBOVUxMOwor CWN1cl90ZW1wID0gTlVMTDsKKwljdXJfbm9kZSA9IE5VTEw7CisJbnVtZGly c2RvbmUrKzsKKwlyZXR1cm4gcnZhbDsKK30KKworaW50Citwcm9jZXNzX2Zp bGUoYmlnbm9kZV90ICpub2RlKQoreworCWludAkJc2ZkID0gLTE7CisJaW50 CQl0ZmQgPSAtMTsKKwlpbnQJCWkgPSAwOworCWludAkJcnZhbCA9IDA7CisJ c3RydWN0IHN0YXQ2NAlzMTsKKwljaGFyCQkqc3JjbmFtZSA9IE5VTEw7CisJ Y2hhcgkJKnBuYW1lID0gTlVMTDsKKwl4ZnNfc3dhcGV4dF90CXN4OworCXhm c19ic3RhdF90CWJzdGF0YnVmOworCXN0cnVjdCBmc3hhdHRyICBmc3g7CisJ Y2hhcgkJdGFyZ2V0W1BBVEhfTUFYXSA9ICIiOworCisJU0VUX1BIQVNFKEZJ TEVfUEhBU0UpOworCisJZHVtcF9ub2RlKCJmaWxlIiwgbm9kZSk7CisKKwlj dXJfbm9kZSA9IG5vZGU7CisJc3JjbmFtZSA9IG5vZGUtPnBhdGhzWzBdOwor CisJYnplcm8oJnMxLCBzaXplb2YoczEpKTsKKwliemVybygmYnN0YXRidWYs IHNpemVvZihic3RhdGJ1ZikpOworCWJ6ZXJvKCZzeCwgc2l6ZW9mKHN4KSk7 CisKKwlpZiAoc3RhdDY0KHNyY25hbWUsICZzMSkgPCAwKSB7CisJCWlmIChl cnJubyAhPSBFTk9FTlQpIHsKKwkJCWVycl9zdGF0KHNyY25hbWUpOworCQkJ Z2xvYmFsX3J2YWwgfD0gMjsKKwkJfQorCQlnb3RvIHF1aXQ7CisJfQorCWlm IChzMS5zdF9pbm8gPD0gWEZTX01BWElOVU1CRVJfMzIgJiYgIWZvcmNlX2Fs bCkKKwkJLyogdGhpcyBmaWxlIGhhcyBjaGFuZ2VkLCBhbmQgbm8gbG9uZ2Vy IG5lZWRzIHByb2Nlc3NpbmcgKi8KKwkJZ290byBxdWl0OworCisJLyogb3Bl biBhbmQgc3luYyBzb3VyY2UgKi8KKwlzZmQgPSBvcGVuKHNyY25hbWUsIE9f UkRXUiB8IE9fRElSRUNUKTsKKwlpZiAoc2ZkIDwgMCkgeworCQllcnJfb3Bl bihzcmNuYW1lKTsKKwkJcnZhbCA9IDE7CisJCWdvdG8gcXVpdDsKKwl9CisJ aWYgKCFwbGF0Zm9ybV90ZXN0X3hmc19mZChzZmQpKSB7CisJCWVycl9ub3Rf eGZzKHNyY25hbWUpOworCQlydmFsID0gMTsKKwkJZ290byBxdWl0OworCX0K KwlpZiAoZnN5bmMoc2ZkKSA8IDApIHsKKwkJZXJyX21lc3NhZ2UoXygic3lu YyBmYWlsZWQ6ICVzOiAlcyIpLAorCQkJCXNyY25hbWUsIHN0cmVycm9yKGVy cm5vKSk7CisJCXJ2YWwgPSAxOworCQlnb3RvIHF1aXQ7CisJfQorCisKKwkv KgorCSAqIENoZWNrIGlmIGEgbWFuZGF0b3J5IGxvY2sgaXMgc2V0IG9uIHRo ZSBmaWxlIHRvIHRyeSBhbmQKKwkgKiBhdm9pZCBibG9ja2luZyBpbmRlZmlu aXRlbHkgb24gdGhlIHJlYWRzIGxhdGVyLiBOb3RlIHRoYXQKKwkgKiBzb21l b25lIGNvdWxkIHN0aWxsIHNldCBhIG1hbmRhdG9yeSBsb2NrIGFmdGVyIHRo aXMgY2hlY2sKKwkgKiBidXQgYmVmb3JlIGFsbCByZWFkcyBoYXZlIGNvbXBs ZXRlZCB0byBibG9jayB4ZnNfcmVubyByZWFkcy4KKwkgKiBUaGlzIGNoYW5n ZSBqdXN0IGNsb3NlcyB0aGUgd2luZG93IGEgYml0LgorCSAqLworCWlmICgo czEuc3RfbW9kZSAmIFNfSVNHSUQpICYmICEoczEuc3RfbW9kZSAmIFNfSVhH UlApKSB7CisJCXN0cnVjdCBmbG9jayBmbDsKKworCQlmbC5sX3R5cGUgPSBG X1JETENLOworCQlmbC5sX3doZW5jZSA9IFNFRUtfU0VUOworCQlmbC5sX3N0 YXJ0ID0gKG9mZl90KTA7CisJCWZsLmxfbGVuID0gMDsKKwkJaWYgKGZjbnRs KHNmZCwgRl9HRVRMSywgJmZsKSA8IDAgKSB7CisJCQlpZiAobG9nX2xldmVs ID49IExPR19ERUJVRykKKwkJCQllcnJfbWVzc2FnZSgibG9ja2luZyBjaGVj ayBmYWlsZWQ6ICVzIiwKKwkJCQkJCXNyY25hbWUpOworCQkJZ2xvYmFsX3J2 YWwgfD0gMjsKKwkJCWdvdG8gcXVpdDsKKwkJfQorCQlpZiAoZmwubF90eXBl ICE9IEZfVU5MQ0spIHsKKwkJCWlmIChsb2dfbGV2ZWwgPj0gTE9HX0RFQlVH KQorCQkJCWVycl9tZXNzYWdlKCJtYW5kYXRvcnkgbG9jazogJXM6IGlnbm9y aW5nIiwKKwkJCQkJCXNyY25hbWUpOworCQkJZ2xvYmFsX3J2YWwgfD0gMjsK KwkJCWdvdG8gcXVpdDsKKwkJfQorCX0KKworCWlmICh4ZnNfZ2V0eGF0dHIo c2ZkLCAmZnN4KSA8IDApIHsKKwkJZXJyX21lc3NhZ2UoXygiZmFpbGVkIHRv IGdldCBpbm9kZSBhdHRyczogJXMiKSwgc3JjbmFtZSk7CisJCXJ2YWwgPSAx OworCQlnb3RvIHF1aXQ7CisJfQorCWlmIChmc3guZnN4X3hmbGFncyAmIChY RlNfWEZMQUdfSU1NVVRBQkxFIHwgWEZTX1hGTEFHX0FQUEVORCkpIHsKKwkJ ZXJyX21lc3NhZ2UoXygiJXM6IGltbXV0YWJsZS9hcHBlbmQsIGlnbm9yaW5n IiksIHNyY25hbWUpOworCQlnbG9iYWxfcnZhbCB8PSAyOworCQlnb3RvIHF1 aXQ7CisJfQorCisJcnZhbCA9IDE7CisKKwlpZiAocmVhbHVpZCAhPSAwICYm IHJlYWx1aWQgIT0gczEuc3RfdWlkKSB7CisJCWVycm5vID0gRUFDQ0VTOwor CQllcnJfb3BlbihzcmNuYW1lKTsKKwkJZ290byBxdWl0OworCX0KKworCS8q IGNyZWF0IHRhcmdldCAqLworCXBuYW1lID0gc3RyZHVwKHNyY25hbWUpOwor CWlmIChwbmFtZSA9PSBOVUxMKSB7CisJCWVycl9ub21lbSgpOworCQlnb3Rv IHF1aXQ7CisJfQorCWRpcm5hbWUocG5hbWUpOworCXNwcmludGYodGFyZ2V0 LCAiJXMvJXNYWFhYWFgiLCBwbmFtZSwgY21kX3ByZWZpeCk7CisJdGZkID0g bWtzdGVtcCh0YXJnZXQpOworCWlmICh0ZmQgPCAwKSB7CisJCWVycl9tZXNz YWdlKCJ1bmFibGUgdG8gY3JlYXRlIGZpbGUgY29weSIpOworCQlnb3RvIHF1 aXQ7CisJfQorCWN1cl90YXJnZXQgPSBzdHJkdXAodGFyZ2V0KTsKKwlpZiAo Y3VyX3RhcmdldCA9PSBOVUxMKSB7CisJCWVycl9ub21lbSgpOworCQlnb3Rv IHF1aXQ7CisJfQorCisJU0VUX1BIQVNFKEZJTEVfUEhBU0VfMSk7CisKKwkv KiBTZXR1cCBkaXJlY3QgSS9PICovCisJaWYgKGZjbnRsKHRmZCwgRl9TRVRG TCwgT19ESVJFQ1QpIDwgMCApIHsKKwkJZXJyX21lc3NhZ2UoXygiY291bGQg bm90IHNldCBPX0RJUkVDVCBmb3IgJXMgb24gdG1wOiAlcyIpLAorCQkJCXNy Y25hbWUsIHRhcmdldCk7CisJCXVubGluayh0YXJnZXQpOworCQlnb3RvIHF1 aXQ7CisJfQorCisJLyogY29weSBhdHRyaWJzICYgRUFzIHRvIHRhcmdldCAq LworCWlmIChkdXBfYXR0cmlidXRlcyhzcmNuYW1lLCBzZmQsIHRhcmdldCwg dGZkKSAhPSAwKSB7CisJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBkdXBs aWNhdGUgZmlsZSBhdHRyaWJ1dGVzOiAlcyIpLAorCQkJCXNyY25hbWUpOwor CQl1bmxpbmsodGFyZ2V0KTsKKwkJZ290byBxdWl0OworCX0KKworCWlmICh4 ZnNfYnVsa3N0YXRfc2luZ2xlKHNmZCwgJnMxLnN0X2lubywgJmJzdGF0YnVm KSA8IDApIHsKKwkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIGJ1bGtzdGF0 IHNvdXJjZSBmaWxlOiAlcyIpLAorCQkJCXNyY25hbWUpOworCQl1bmxpbmso dGFyZ2V0KTsKKwkJZ290byBxdWl0OworCX0KKworCWlmIChic3RhdGJ1Zi5i c19pbm8gIT0gczEuc3RfaW5vKSB7CisJCWVycl9tZXNzYWdlKF8oImJ1bGtz dGF0IG9mIHNvdXJjZSBmaWxlIHJldHVybmVkIHdyb25nIGlub2RlOiAlcyIp LAorCQkJCXNyY25hbWUpOworCQl1bmxpbmsodGFyZ2V0KTsKKwkJZ290byBx dWl0OworCX0KKworCWZ0cnVuY2F0ZTY0KHRmZCwgYnN0YXRidWYuYnNfc2l6 ZSk7CisKKwkvKiBzd2FwZXh0ZW50cyBzcmMgdGFyZ2V0ICovCisJc3guc3hf c3RhdCAgICAgPSBic3RhdGJ1ZjsgLyogc3RydWN0IGNvcHkgKi8KKwlzeC5z eF92ZXJzaW9uICA9IFhGU19TWF9WRVJTSU9OOworCXN4LnN4X2ZkdGFyZ2V0 ID0gc2ZkOworCXN4LnN4X2ZkdG1wICAgID0gdGZkOworCXN4LnN4X29mZnNl dCAgID0gMDsKKwlzeC5zeF9sZW5ndGggICA9IGJzdGF0YnVmLmJzX3NpemU7 CisKKwkvKiBTd2FwIHRoZSBleHRlbnRzICovCisJcnZhbCA9IHhmc19zd2Fw ZXh0KHNmZCwgJnN4KTsKKwlpZiAocnZhbCA8IDApIHsKKwkJaWYgKGxvZ19s ZXZlbCA+PSBMT0dfREVCVUcpIHsKKwkJCXN3aXRjaCAoZXJybm8pIHsKKwkJ CWNhc2UgRU5PVFNVUDoKKwkJCQllcnJfbWVzc2FnZSgiJXM6IGZpbGUgdHlw ZSBub3Qgc3VwcG9ydGVkIiwKKwkJCQkJc3JjbmFtZSk7CisJCQkJYnJlYWs7 CisJCQljYXNlIEVGQVVMVDoKKwkJCQkvKiBUaGUgZmlsZSBoYXMgY2hhbmdl ZCBzaW5jZSB3ZSBzdGFydGVkIHRoZSBjb3B5ICovCisJCQkJZXJyX21lc3Nh Z2UoIiVzOiBmaWxlIG1vZGlmaWVkLCAiCisJCQkJCSAiaW5vZGUgcmVudW1i ZXIgYWJvcnRlZDogJWxkIiwKKwkJCQkJIHNyY25hbWUsIGJzdGF0YnVmLmJz X3NpemUpOworCQkJCWJyZWFrOworCQkJY2FzZSBFQlVTWToKKwkJCQkvKiBU aW1lc3RhbXAgaGFzIGNoYW5nZWQgb3IgbW1hcCdlZCBmaWxlICovCisJCQkJ ZXJyX21lc3NhZ2UoIiVzOiBmaWxlIGJ1c3kiLCBzcmNuYW1lKTsKKwkJCQli cmVhazsKKwkJCWRlZmF1bHQ6CisJCQkJZXJyX21lc3NhZ2UoXygiU3dhcCBl eHRlbnRzIGZhaWxlZDogJXM6ICVzIiksCisJCQkJCXNyY25hbWUsIHN0cmVy cm9yKGVycm5vKSk7CisJCQkJYnJlYWs7CisJCQl9CisJCX0gZWxzZQorCQkJ ZXJyX21lc3NhZ2UoXygiU3dhcCBleHRlbnRzIGZhaWxlZDogJXM6ICVzIiks CisJCQkJCXNyY25hbWUsIHN0cmVycm9yKGVycm5vKSk7CisJCWdvdG8gcXVp dDsKKwl9CisKKwlpZiAoYnN0YXRidWYuYnNfZG1ldm1hc2sgfCBic3RhdGJ1 Zi5ic19kbXN0YXRlKSB7CisJCXN0cnVjdCBmc2RtaWRhdGEgZnNzZXRkbTsK KworCQkvKiBTZXQgdGhlIERNQVBJIEZpZWxkcy4gKi8KKwkJZnNzZXRkbS5m c2RfZG1ldm1hc2sgPSBic3RhdGJ1Zi5ic19kbWV2bWFzazsKKwkJZnNzZXRk bS5mc2RfcGFkZGluZyA9IDA7CisJCWZzc2V0ZG0uZnNkX2Rtc3RhdGUgPSBi c3RhdGJ1Zi5ic19kbXN0YXRlOworCisJCWlmIChpb2N0bCh0ZmQsIFhGU19J T0NfRlNTRVRETSwgKHZvaWQgKikmZnNzZXRkbSApIDwgMCkKKwkJCWVycl9t ZXNzYWdlKF8oImF0dGVtcHQgdG8gc2V0IERNSSBhdHRyaWJ1dGVzICIKKwkJ CQkJIm9mICVzIGZhaWxlZCIpLCB0YXJnZXQpOworCX0KKworCVNFVF9QSEFT RShGSUxFX1BIQVNFXzIpOworCisJLyogdW5saW5rIHNyYyAqLworCXJ2YWwg PSB1bmxpbmsoc3JjbmFtZSk7CisJaWYgKHJ2YWwgIT0gMCkgeworCQllcnJf bWVzc2FnZShfKCJ1bmFibGUgdG8gcmVtb3ZlIGZpbGU6ICVzIiksIHNyY25h bWUpOworCQlnb3RvIHF1aXQ7CisJfQorCisJU0VUX1BIQVNFKEZJTEVfUEhB U0VfMyk7CisKKwkvKiByZW5hbWUgdGFyZ2V0IHNyYyAqLworCXJ2YWwgPSBy ZW5hbWUodGFyZ2V0LCBzcmNuYW1lKTsKKwlpZiAocnZhbCAhPSAwKSB7CisJ CS8qCisJCSAqIHdlIGNhbid0IGFib3J0IHNpbmNlIHRoZSBzcmMgZmlsZSBp cyBub3cgZ29uZS4KKwkJICogbGV0IHRoZSBhZG1pbiBjbGVhbiB0aGlzIG9u ZSB1cAorCQkgKi8KKwkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIHJlbmFt ZSBmaWxlOiAlcyB0byAlcyIpLAorCQkJCXRhcmdldCwgc3JjbmFtZSk7CisJ CWdvdG8gcXVpdDsKKwl9CisKKwlTRVRfUEhBU0UoRklMRV9QSEFTRV80KTsK KworCS8qIGZvciBlYWNoIGhhcmRsaW5rLCB1bmxpbmsgYW5kIGNyZWF0IHBv aW50aW5nIHRvIHRhcmdldCAqLworCWZvciAoaSA9IDE7IGkgPCBub2RlLT5u dW1wYXRoczsgaSsrKSB7CisJCS8qIHVubGluayBzcmMgKi8KKwkJcnZhbCA9 IHVubGluayhub2RlLT5wYXRoc1tpXSk7CisJCWlmIChydmFsICE9IDApIHsK KwkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW1vdmUgZmlsZTogJXMi KSwKKwkJCQkgICAgICAgbm9kZS0+cGF0aHNbaV0pOworCQkJZ290byBxdWl0 OworCQl9CisKKwkJcnZhbCA9IGxpbmsoc3JjbmFtZSwgbm9kZS0+cGF0aHNb aV0pOworCQlpZiAocnZhbCAhPSAwKSB7CisJCQllcnJfbWVzc2FnZSgidW5h YmxlIHRvIGxpbmsgdG8gZmlsZTogJXMiLCBzcmNuYW1lKTsKKwkJCWdvdG8g cXVpdDsKKwkJfQorCQludW1maWxlc2RvbmUrKzsKKwl9CisKKyBxdWl0Ogor CWN1cl9ub2RlID0gTlVMTDsKKworCVNFVF9QSEFTRShGSUxFX1BIQVNFKTsK KworCWlmIChzZmQgPj0gMCkKKwkJY2xvc2Uoc2ZkKTsKKwlpZiAodGZkID49 IDApCisJCWNsb3NlKHRmZCk7CisKKwlmcmVlKHBuYW1lKTsKKwlmcmVlKGN1 cl90YXJnZXQpOworCisJY3VyX3RhcmdldCA9IE5VTEw7CisKKwludW1maWxl c2RvbmUrKzsKKwlyZXR1cm4gcnZhbDsKK30KKworc3RhdGljIGludAorb3Bl bl9yZWNvdmVyZmlsZSh2b2lkKQoreworCXJlY292ZXJfZmQgPSBvcGVuKHJl Y292ZXJfZmlsZSwgT19SRFdSIHwgT19TWU5DIHwgT19DUkVBVCB8IE9fRVhD TCwKKwkJCTA2MDApOworCWlmIChyZWNvdmVyX2ZkIDwgMCkgeworCQlpZiAo ZXJybm8gPT0gRUVYSVNUKQorCQkJZXJyX21lc3NhZ2UoXygiUmVjb3Zlcnkg ZmlsZSBhbHJlYWR5IGV4aXN0cywgZWl0aGVyICIKKwkJCQkicnVuICclcyAt ciAlcycgb3IgcmVtb3ZlIHRoZSBmaWxlLiIpLAorCQkJCXByb2duYW1lLCBy ZWNvdmVyX2ZpbGUpOworCQllbHNlCisJCQllcnJfb3BlbihyZWNvdmVyX2Zp bGUpOworCQlyZXR1cm4gMTsKKwl9CisKKwlpZiAoIXBsYXRmb3JtX3Rlc3Rf eGZzX2ZkKHJlY292ZXJfZmQpKSB7CisJCWVycl9ub3RfeGZzKHJlY292ZXJf ZmlsZSk7CisJCWNsb3NlKHJlY292ZXJfZmQpOworCQlyZXR1cm4gMTsKKwl9 CisKKwlyZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQKK3VwZGF0ZV9yZWNv dmVyZmlsZSh2b2lkKQoreworCXN0YXRpYyBjb25zdCBjaGFyIG51bGxfZmls ZVtdID0gIjBcbjBcbjBcblxudGFyZ2V0OiBcbnRlbXA6IFxuZW5kXG4iOwor CXN0YXRpYyBzaXplX3QJYnVmX3NpemUgPSAwOworCXN0YXRpYyBjaGFyCSpi dWYgPSBOVUxMOworCWludCAJCWksIGxlbjsKKworCWlmIChyZWNvdmVyX2Zk IDw9IDApCisJCXJldHVybjsKKworCWlmIChjdXJfbm9kZSA9PSBOVUxMIHx8 IGN1cl9waGFzZSA9PSAwKSB7CisJCS8qIGluYmV0d2VlbiBwcm9jZXNzaW5n IG9yIHN0aWxsIHNjYW5uaW5nICovCisJCWxzZWVrKHJlY292ZXJfZmQsIDAs IFNFRUtfU0VUKTsKKwkJd3JpdGUocmVjb3Zlcl9mZCwgbnVsbF9maWxlLCBz aXplb2YobnVsbF9maWxlKSk7CisJCXJldHVybjsKKwl9CisKKwlBU1NFUlQo aGlnaGVzdF9udW1wYXRocyA+IDApOworCWlmIChidWYgPT0gTlVMTCkgewor CQlidWZfc2l6ZSA9IChoaWdoZXN0X251bXBhdGhzICsgMykgKiBQQVRIX01B WDsKKwkJYnVmID0gbWFsbG9jKGJ1Zl9zaXplKTsKKwkJaWYgKGJ1ZiA9PSBO VUxMKSB7CisJCQllcnJfbm9tZW0oKTsKKwkJCWV4aXQoMSk7CisJCX0KKwl9 CisKKwlsZW4gPSBzcHJpbnRmKGJ1ZiwgIiVkXG4lbGx1XG4lZFxuIiwgY3Vy X3BoYXNlLAorCQkJKGxvbmcgbG9uZyljdXJfbm9kZS0+aW5vLCBjdXJfbm9k ZS0+ZnR3X2ZsYWdzKTsKKworCWZvciAoaSA9IDA7IGkgPCBjdXJfbm9kZS0+ bnVtcGF0aHM7IGkrKykKKwkJbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAi JXNcbiIsIGN1cl9ub2RlLT5wYXRoc1tpXSk7CisKKwlsZW4gKz0gc3ByaW50 ZihidWYgKyBsZW4sICJ0YXJnZXQ6ICVzXG50ZW1wOiAlc1xuZW5kXG4iLAor CQkJY3VyX3RhcmdldCwgY3VyX3RlbXApOworCisJQVNTRVJUKGxlbiA8IGJ1 Zl9zaXplKTsKKworCWxzZWVrKHJlY292ZXJfZmQsIDAsIFNFRUtfU0VUKTsK KwlmdHJ1bmNhdGUocmVjb3Zlcl9mZCwgMCk7CisJd3JpdGUocmVjb3Zlcl9m ZCwgYnVmLCBsZW4pOworfQorCitzdGF0aWMgdm9pZAorY2xlYW51cCh2b2lk KQoreworCWxvZ19tZXNzYWdlKExPR19OT1JNQUwsIF8oIkludGVycnVwdGVk IC0tIGNsZWFuaW5nIHVwLi4uIikpOworCisJZnJlZV9ub2RlaGFzaCgpOwor CisJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgXygiRG9uZS4iKSk7Cit9CisK K3N0YXRpYyB2b2lkCitzaWdoYW5kbGVyKGludCBzaWcpCit7CisJc3RhdGlj IGNoYXIJY3ljbGVbNF0gPSAiLVxcfC8iOworCXN0YXRpYyB1aW50NjRfdAlj dXJfY3ljbGUgPSAwOworCWRvdWJsZQkJcGVyY2VudDsKKworCWFsYXJtKDAp OworCisJaWYgKHNpZyAhPSBTSUdBTFJNKSB7CisJCWNsZWFudXAoKTsKKwkJ ZXhpdCgxKTsKKwl9CisKKwlpZiAoY3VyX3BoYXNlID09IFNDQU5fUEhBU0Up IHsKKwkJaWYgKGxvZ19sZXZlbCA+PSBMT0dfSU5GTykKKwkJCWZwcmludGYo c3RkZXJyLCBfKCJcciVsbHUgZmlsZXMgYW5kICVsbHUgZGlycyAiCisJCQkJ InRvIHJlbnVtYmVyIGZvdW5kLi4uICVjIiksCisJCQkJKGxvbmcgbG9uZylu dW1maWxlbm9kZXMsCisJCQkJKGxvbmcgbG9uZyludW1kaXJub2RlcywKKwkJ CQljeWNsZVtjdXJfY3ljbGUgJSA0XSk7CisJCWVsc2UKKwkJCWZwcmludGYo c3RkZXJyLCAiXHIlYyIsCisJCQkJY3ljbGVbY3VyX2N5Y2xlICUgNF0pOwor CQljdXJfY3ljbGUrKzsKKwl9IGVsc2UgaWYgKGN1cl9waGFzZSA+PSBESVJf UEhBU0UgJiYgY3VyX3BoYXNlIDw9IERJUl9QSEFTRV9NQVgpIHsKKwkJcGVy Y2VudCA9IChkb3VibGUpbnVtZGlyc2RvbmUgLyAoZG91YmxlKW51bWRpcm5v ZGVzOworCQlwZXJjZW50ICo9IDEwMC4wOworCQlpZiAocGVyY2VudCA+IDEw MC4wKQorCQkJcGVyY2VudCA9IDEwMC4wOworCQlpZiAobG9nX2xldmVsID49 IExPR19JTkZPKQorCQkJZnByaW50ZihzdGRlcnIsIF8oIlxyJS4xZiUlLCAl bGx1IG9mICVsbHUgIgorCQkJCSJkaXJzLCAldSBzZWNvbmRzIGVsYXBzZWQi KSwgcGVyY2VudCwKKwkJCQkobG9uZyBsb25nKW51bWRpcnNkb25lLAorCQkJ CShsb25nIGxvbmcpbnVtZGlybm9kZXMsCisJCQkJKGludCkodGltZSgwKSAt IHN0YXJ0dGltZSkpOworCQllbHNlCisJCQlmcHJpbnRmKHN0ZGVyciwgIlxy JS4xZiUlIiwgcGVyY2VudCk7CisJfSBlbHNlIGlmIChjdXJfcGhhc2UgPj0g RklMRV9QSEFTRSAmJiBjdXJfcGhhc2UgPD0gRklMRV9QSEFTRV9NQVgpIHsK KwkJcGVyY2VudCA9IChkb3VibGUpbnVtZmlsZXNkb25lIC8gKGRvdWJsZSlu dW1maWxlbm9kZXM7CisJCXBlcmNlbnQgKj0gMTAwLjA7CisJCWlmIChwZXJj ZW50ID4gMTAwLjApCisJCQlwZXJjZW50ID0gMTAwLjA7CisJCWlmIChsb2df bGV2ZWwgPj0gTE9HX0lORk8pCisJCQlmcHJpbnRmKHN0ZGVyciwgXygiXHIl LjFmJSUsICVsbHUgb2YgJWxsdSAiCisJCQkJImZpbGVzLCAldSBzZWNvbmRz IGVsYXBzZWQiKSwKKwkJCQlwZXJjZW50LCAobG9uZyBsb25nKW51bWZpbGVz ZG9uZSwKKwkJCQkobG9uZyBsb25nKW51bWZpbGVub2RlcywKKwkJCQkoaW50 KSh0aW1lKDApIC0gc3RhcnR0aW1lKSk7CisJCWVsc2UKKwkJCWZwcmludGYo c3RkZXJyLCAiXHIlLjFmJSUiLCBwZXJjZW50KTsKKwl9CisJcG9sbF9vdXRw dXQgPSAxOworCXNpZ25hbChTSUdBTFJNLCBzaWdoYW5kbGVyKTsKKworCWlm IChwb2xsX2ludGVydmFsKQorCQlhbGFybShwb2xsX2ludGVydmFsKTsKK30K Kworc3RhdGljIGludAorcmVhZF9yZWNvdmVyX2ZpbGUoCisJY2hhcgkJKnJl Y292ZXJfZmlsZSwKKwliaWdub2RlX3QJKipub2RlLAorCWNoYXIJCSoqdGFy Z2V0LAorCWNoYXIJCSoqdGVtcCwKKwlpbnQJCSpwaGFzZSkKK3sKKwlGSUxF CQkqZmlsZTsKKwlpbnQJCXJ2YWwgPSAxOworCWlub190CQlpbm87CisJaW50 CQlmdHdfZmxhZ3M7CisJY2hhcgkJYnVmW1BBVEhfTUFYICsgMTBdOyAvKiBw YXRoICsgInRhcmdldDogIiAqLworCXN0cnVjdCBzdGF0NjQJczsKKwlpbnQJ CWZpcnN0X3BhdGg7CisKKwkvKgorCisJQSByZWNvdmVyeSBmaWxlIHNob3Vs ZCBsb29rIGxpa2U6CisKKwk8cGhhc2U+CisJPGlubyBudW1iZXI+CisJPGZ0 dyBmbGFncz4KKwk8Zmlyc3QgcGF0aCB0byBpbm9kZT4KKwk8aGFyZGxpbmtz IHRvIGlub2RlPgorCXRhcmdldDogPHBhdGggdG8gdGFyZ2V0IGRpciBvciBm aWxlPgorCXRlbXA6IDxwYXRoIHRvIHRlbXAgZGlyIGlmIGRpciBwaGFzZT4K KwllbmQKKwkqLworCisJZmlsZSA9IGZvcGVuKHJlY292ZXJfZmlsZSwgInIi KTsKKwlpZiAoZmlsZSA9PSBOVUxMKSB7CisJCWVycl9vcGVuKHJlY292ZXJf ZmlsZSk7CisJCXJldHVybiAxOworCX0KKworCS8qIHJlYWQgcGhhc2UgKi8K KwkqcGhhc2UgPSAwOworCWlmIChmZ2V0cyhidWYsIFBBVEhfTUFYICsgMTAs IGZpbGUpID09IE5VTEwpIHsKKwkJZXJyX21lc3NhZ2UoIlJlY292ZXJ5IGZh aWxlZDogdW5hYmxlIHRvIHJlYWQgcGhhc2UiKTsKKwkJZ290byBxdWl0Owor CX0KKwlidWZbc3RybGVuKGJ1ZikgLSAxXSA9ICdcMCc7CisJKnBoYXNlID0g YXRvaShidWYpOworCWlmICgqcGhhc2UgPT0gU0NBTl9QSEFTRSkgeworCQlm Y2xvc2UoZmlsZSk7CisJCXJldHVybiAwOworCX0KKwlpZiAoKCpwaGFzZSA8 IERJUl9QSEFTRSB8fCAqcGhhc2UgPiBESVJfUEhBU0VfTUFYKSAmJgorCQkJ KCpwaGFzZSA8IEZJTEVfUEhBU0UgfHwgKnBoYXNlID4gRklMRV9QSEFTRV9N QVgpKSB7CisJCWVycl9tZXNzYWdlKCJSZWNvdmVyeSBmYWlsZWQ6IGZhaWxl ZCB0byByZWFkIHZhbGlkIHJlY292ZXJ5IHBoYXNlIik7CisJCWdvdG8gcXVp dDsKKwl9CisKKwkvKiByZWFkIGlub2RlIG51bWJlciAqLworCWlmIChmZ2V0 cyhidWYsIFBBVEhfTUFYICsgMTAsIGZpbGUpID09IE5VTEwpIHsKKwkJZXJy X21lc3NhZ2UoIlJlY292ZXJ5IGZhaWxlZDogdW5hYmxlIHRvIHJlYWQgaW5v ZGUgbnVtYmVyIik7CisJCWdvdG8gcXVpdDsKKwl9CisJYnVmW3N0cmxlbihi dWYpIC0gMV0gPSAnXDAnOworCWlubyA9IHN0cnRvdWxsKGJ1ZiwgTlVMTCwg MTApOworCWlmIChpbm8gPT0gMCkgeworCQllcnJfbWVzc2FnZSgiUmVjb3Zl cnkgZmFpbGVkOiB1bmFibGUgdG8gcmVhZCBpbm9kZSBudW1iZXIiKTsKKwkJ Z290byBxdWl0OworCX0KKworCS8qIHJlYWQgZnR3X2ZsYWdzICovCisJaWYg KGZnZXRzKGJ1ZiwgUEFUSF9NQVggKyAxMCwgZmlsZSkgPT0gTlVMTCkgewor CQllcnJfbWVzc2FnZSgiUmVjb3ZlcnkgZmFpbGVkOiB1bmFibGUgdG8gcmVh ZCBmbGFncyIpOworCQlnb3RvIHF1aXQ7CisJfQorCWJ1ZltzdHJsZW4oYnVm KSAtIDFdID0gJ1wwJzsKKwlpZiAoYnVmWzFdICE9ICdcMCcgfHwgKGJ1Zlsw XSAhPSAnMCcgJiYgYnVmWzBdICE9ICcxJykpIHsKKwkJZXJyX21lc3NhZ2Uo IlJlY292ZXJ5IGZhaWxlZDogdW5hYmxlIHRvIHJlYWQgZmxhZ3M6ICclcyci LCBidWYpOworCQlnb3RvIHF1aXQ7CisJfQorCWZ0d19mbGFncyA9IGF0b2ko YnVmKTsKKworCS8qIHJlYWQgcGF0aHMgYW5kIHRhcmdldCBwYXRoICovCisJ Km5vZGUgPSBOVUxMOworCSp0YXJnZXQgPSBOVUxMOworCWZpcnN0X3BhdGgg PSAxOworCXdoaWxlIChmZ2V0cyhidWYsIFBBVEhfTUFYICsgMTAsIGZpbGUp ICE9IE5VTEwpIHsKKwkJYnVmW3N0cmxlbihidWYpIC0gMV0gPSAnXDAnOwor CisJCWxvZ19tZXNzYWdlKExPR19ERUJVRywgInBhdGg6ICclcyciLCBidWYp OworCisJCWlmIChidWZbMF0gPT0gJy8nKSB7CisJCQlpZiAoc3RhdDY0KGJ1 ZiwgJnMpIDwgMCkgeworCQkJCWVycl9tZXNzYWdlKF8oIlJlY292ZXJ5IGZh aWxlZDogY2Fubm90ICIKKwkJCQkJCSJzdGF0ICclcyciKSwgYnVmKTsKKwkJ CQlnb3RvIHF1aXQ7CisJCQl9CisJCQlpZiAocy5zdF9pbm8gIT0gaW5vKSB7 CisJCQkJZXJyX21lc3NhZ2UoXygiUmVjb3ZlcnkgZmFpbGVkOiBpbm9kZSAi CisJCQkJCQkibnVtYmVyIGZvciAnJXMnIGRvZXMgbm90ICIKKwkJCQkJCSJt YXRjaCByZWNvcmRlZCBudW1iZXIiKSwgYnVmKTsKKwkJCQlnb3RvIHF1aXQ7 CisJCQl9CisKKwkJCWlmIChmaXJzdF9wYXRoKSB7CisJCQkJZmlyc3RfcGF0 aCA9IDA7CisJCQkJKm5vZGUgPSBhZGRfbm9kZV9wYXRoKGlubywgZnR3X2Zs YWdzLCBidWYpOworCQkJfQorCQkJZWxzZSB7CisJCQkJYWRkX3BhdGgoKm5v ZGUsIGJ1Zik7CisJCQl9CisJCX0KKwkJZWxzZSBpZiAoc3RybmNtcChidWYs ICJ0YXJnZXQ6ICIsIDgpID09IDApIHsKKwkJCSp0YXJnZXQgPSBzdHJkdXAo YnVmICsgOCk7CisJCQlpZiAoKnRhcmdldCA9PSBOVUxMKSB7CisJCQkJZXJy X25vbWVtKCk7CisJCQkJZ290byBxdWl0OworCQkJfQorCQkJaWYgKHN0YXQ2 NCgqdGFyZ2V0LCAmcykgPCAwKSB7CisJCQkJZXJyX21lc3NhZ2UoXygiUmVj b3ZlcnkgZmFpbGVkOiBjYW5ub3QgIgorCQkJCQkJInN0YXQgJyVzJyIpLCAq dGFyZ2V0KTsKKwkJCQlnb3RvIHF1aXQ7CisJCQl9CisJCX0KKwkJZWxzZSBp ZiAoc3RybmNtcChidWYsICJ0ZW1wOiAiLCA2KSA9PSAwKSB7CisJCQkqdGVt cCA9IHN0cmR1cChidWYgKyA2KTsKKwkJCWlmICgqdGVtcCA9PSBOVUxMKSB7 CisJCQkJZXJyX25vbWVtKCk7CisJCQkJZ290byBxdWl0OworCQkJfQorCQl9 CisJCWVsc2UgaWYgKHN0cmNtcChidWYsICJlbmQiKSA9PSAwKSB7CisJCQly dmFsID0gMDsKKwkJCWdvdG8gcXVpdDsKKwkgCX0KKwkgCWVsc2UgeworCQkJ ZXJyX21lc3NhZ2UoXygiUmVjb3ZlcnkgZmFpbGVkOiB1bnJlY29nbmlzZWQg IgorCQkJCQkic3RyaW5nOiAnJXMnIiksIGJ1Zik7CisJCQlnb3RvIHF1aXQ7 CisJCX0KKwl9CisKKwllcnJfbWVzc2FnZShfKCJSZWNvdmVyeSBmYWlsZWQ6 IGVuZCBvZiByZWNvdmVyeSBmaWxlIG5vdCBmb3VuZCIpKTsKKworIHF1aXQ6 CisJaWYgKCpub2RlID09IE5VTEwpIHsKKwkJZXJyX21lc3NhZ2UoXygiUmVj b3ZlcnkgZmFpbGVkOiBubyB2YWxpZCBpbm9kZSBvciBwYXRocyAiCisJCQkJ InNwZWNpZmllZCIpKTsKKwkJcnZhbCA9IDE7CisJfQorCisJaWYgKCp0YXJn ZXQgPT0gTlVMTCkgeworCQllcnJfbWVzc2FnZShfKCJSZWNvdmVyeSBmYWls ZWQ6IG5vIGlub2RlIHRhcmdldCBzcGVjaWZpZWQiKSk7CisJCXJ2YWwgPSAx OworCX0KKworCWZjbG9zZShmaWxlKTsKKworCXJldHVybiBydmFsOworfQor CitpbnQKK3JlY292ZXIoCisJYmlnbm9kZV90CSpub2RlLAorCWNoYXIJCSp0 YXJnZXQsCisJY2hhcgkJKnRuYW1lLAorCWludAkJcGhhc2UpCit7CisJaW50 CQl0ZmQgPSAtMTsKKwlpbnQJCXRhcmdldGZkID0gLTE7CisJY2hhcgkJKnNy Y25hbWUgPSBOVUxMOworCWludAkJcnZhbCA9IDA7CisJaW50CQlpOworCWlu dAkJbW92ZV9jb3VudCA9IDA7CisKKwlkdW1wX25vZGUoInJlY292ZXIiLCBu b2RlKTsKKwlsb2dfbWVzc2FnZShMT0dfREVCVUcsICJ0YXJnZXQ6ICVzLCBw aGFzZTogJXgiLCB0YXJnZXQsIHBoYXNlKTsKKworCWlmIChub2RlKQorCQlz cmNuYW1lID0gbm9kZS0+cGF0aHNbMF07CisKKwlzd2l0Y2ggKHBoYXNlKSB7 CisKKwljYXNlIERJUl9QSEFTRV8yOgorcm10ZW1wczoKKwkJbG9nX21lc3Nh Z2UoTE9HX05PUk1BTCwgXygiUmVtb3ZpbmcgdGVtcG9yYXJ5IGRpcmVjdG9y eTogJyVzJyIpLAorCQkJCXRuYW1lKTsKKwkJaWYgKHJtZGlyKHRuYW1lKSA8 IDAgJiYgZXJybm8gIT0gRU5PRU5UKSB7CisJCQllcnJfbWVzc2FnZShfKCJ1 bmFibGUgdG8gcmVtb3ZlIGRpcmVjdG9yeTogJXMiKSwgdG5hbWUpOworCQkJ cnZhbCA9IDE7CisJCX0KKwkJLyogRkFMTCBUSFJVICovCisJY2FzZSBESVJf UEhBU0VfMToKKwkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgXygiUmVtb3Zp bmcgdGFyZ2V0IGRpcmVjdG9yeTogJyVzJyIpLAorCQkJCXRhcmdldCk7CisJ CWlmIChybWRpcih0YXJnZXQpIDwgMCAmJiBlcnJubyAhPSBFTk9FTlQpIHsK KwkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW1vdmUgZGlyZWN0b3J5 OiAlcyIpLAorCQkJCQl0YXJnZXQpOworCQkJcnZhbCA9IDE7CisJCX0KKwkJ YnJlYWs7CisKKwljYXNlIERJUl9QSEFTRV8zOgorCQlsb2dfbWVzc2FnZShM T0dfTk9STUFMLCBfKCJDb21wbGV0aW5nIG1vdmluZyBkaXJlY3RvcnkgIgor CQkJCSJjb250ZW50czogJyVzJyB0byAnJXMnIiksIHNyY25hbWUsIHRhcmdl dCk7CisJCWlmIChtb3ZlX2RpcmVudHMoc3JjbmFtZSwgdGFyZ2V0LCAmbW92 ZV9jb3VudCkgIT0gMCkgeworCQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRv IG1vdmUgZGlyZWN0b3J5IGNvbnRlbnRzOiAiCisJCQkJCSIlcyB0byAlcyIp LCBzcmNuYW1lLCB0YXJnZXQpOworCQkJLyogdWggb2gsIG1vdmUgZXZlcnl0 aGluZyBiYWNrLi4uICovCisJCQlpZiAobW92ZV9jb3VudCA+IDApIHsKKwkJ CQlpZiAobW92ZV9kaXJlbnRzKHRhcmdldCwgc3JjbmFtZSwKKwkJCQkJCSZt b3ZlX2NvdW50KSAhPSAwKSB7CisJCQkJCS8qIG9oLCBkZWFyIGxvcmQuLi4g bGV0IHRoZSBhZG1pbgorCQkJCQkgKiBjbGVhbiB0aGlzIG9uZSB1cCAqLwor CQkJCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8gbW92ZSBkaXJlY3Rvcnkg IgorCQkJCQkJImNvbnRlbnRzIGJhY2s6ICVzIHRvICVzIiksCisJCQkJCQl0 YXJnZXQsIHNyY25hbWUpOworCQkJCQlleGl0KDEpOworCQkJCX0KKwkJCX0K KwkJCWdvdG8gcm10ZW1wczsKKwkJfQorCQkvKiBGQUxMIFRIUlUgKi8KKwlj YXNlIERJUl9QSEFTRV80OgorCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCBf KCJTZXR0aW5nIGF0dHJpYnV0ZXMgZm9yIHRhcmdldCAiCisJCQkJImRpcmVj dG9yeTogXCclc1wnIiksIHRhcmdldCk7CisJCXRmZCA9IG9wZW4odG5hbWUs IE9fUkRPTkxZKTsKKwkJaWYgKHRmZCA8IDApIHsKKwkJCWVycl9vcGVuKHRu YW1lKTsKKwkJCXJ2YWwgPSAxOworCQkJYnJlYWs7CisJCX0KKwkJdGFyZ2V0 ZmQgPSBvcGVuKHRhcmdldCwgT19SRE9OTFkpOworCQlpZiAodGFyZ2V0ZmQg PCAwKSB7CisJCQllcnJfb3Blbih0YXJnZXQpOworCQkJcnZhbCA9IDE7CisJ CQlicmVhazsKKwkJfQorCQlydmFsID0gZHVwX2F0dHJpYnV0ZXModG5hbWUs IHRmZCwgdGFyZ2V0LCB0YXJnZXRmZCk7CisJCWlmIChydmFsICE9IDApIHsK KwkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBkdXBsaWNhdGUgZGlyZWN0 b3J5ICIKKwkJCQkJImF0dHJpYnV0ZXM6ICVzIiksIHRuYW1lKTsKKwkJCWJy ZWFrOworCQl9CisJCWNsb3NlKHRmZCk7CisJCWNsb3NlKHRhcmdldGZkKTsK KwkJLyogRkFMTCBUSFJVICovCisJY2FzZSBESVJfUEhBU0VfNjoKKwkJbG9n X21lc3NhZ2UoTE9HX05PUk1BTCwgXygiUmVtb3ZpbmcgdGVtcG9yYXJ5IGRp cmVjdG9yeTogXCclc1wnIiksCisJCQkJdG5hbWUpOworCQlpZiAocm1kaXIo dG5hbWUpIDwgMCAmJiBlcnJubyAhPSBFTk9FTlQpIHsKKwkJCWVycl9tZXNz YWdlKF8oInVuYWJsZSB0byByZW1vdmUgZGlyZWN0b3J5OiAlcyIpLAorCQkJ CQl0bmFtZSk7CisJCQlydmFsID0gMTsKKwkJCWJyZWFrOworCQl9CisJCS8q IEZBTEwgVEhSVSAqLworCWNhc2UgRElSX1BIQVNFXzU6CisJCWxvZ19tZXNz YWdlKExPR19OT1JNQUwsIF8oIlJlbW92aW5nIG9sZCBkaXJlY3Rvcnk6IFwn JXNcJyIpLAorCQkJCXNyY25hbWUpOworCQlpZiAocm1kaXIoc3JjbmFtZSkg PCAwICYmIGVycm5vICE9IEVOT0VOVCkgeworCQkJZXJyX21lc3NhZ2UoXygi dW5hYmxlIHRvIHJlbW92ZSBkaXJlY3Rvcnk6ICVzIiksCisJCQkJCXNyY25h bWUpOworCQkJcnZhbCA9IDE7CisJCQlicmVhazsKKwkJfQorCQkvKiBGQUxM IFRIUlUgKi8KKwljYXNlIERJUl9QSEFTRV83OgorCQlsb2dfbWVzc2FnZShM T0dfTk9STUFMLCBfKCJSZW5hbWluZyBuZXcgZGlyZWN0b3J5IHRvIG9sZCAi CisJCQkiZGlyZWN0b3J5OiBcJyVzXCcgLT4gXCclc1wnIiksIHRhcmdldCwg c3JjbmFtZSk7CisJCXJ2YWwgPSByZW5hbWUodGFyZ2V0LCBzcmNuYW1lKTsK KwkJaWYgKHJ2YWwgIT0gMCkgeworCQkJLyogd2UgY2FuJ3QgYWJvcnQgc2lu Y2UgdGhlIHNyYyBkaXIgaXMgbm93IGdvbmUuCisJCQkgKiBsZXQgdGhlIGFk bWluIGNsZWFuIHRoaXMgb25lIHVwCisJCQkgKi8KKwkJCWVycl9tZXNzYWdl KF8oInVuYWJsZSB0byByZW5hbWUgZGlyZWN0b3J5OiAlcyB0byAlcyIpLAor CQkJCQl0YXJnZXQsIHNyY25hbWUpOworCQkJYnJlYWs7CisJCX0KKwkJYnJl YWs7CisKKworCWNhc2UgRklMRV9QSEFTRV8xOgorCQlsb2dfbWVzc2FnZShM T0dfTk9STUFMLCBfKCJVbmxpbmtpbmcgdGVtcG9yYXJ5IGZpbGU6IFwnJXNc JyIpLCB0YXJnZXQpOworCQl1bmxpbmsodGFyZ2V0KTsKKwkJYnJlYWs7CisK KwljYXNlIEZJTEVfUEhBU0VfMjoKKwkJbG9nX21lc3NhZ2UoTE9HX05PUk1B TCwgXygiVW5saW5raW5nIG9sZCBmaWxlOiBcJyVzXCciKSwgc3JjbmFtZSk7 CisJCXJ2YWwgPSB1bmxpbmsoc3JjbmFtZSk7CisJCWlmIChydmFsICE9IDAp IHsKKwkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW1vdmUgZmlsZTog JXMiKSwgc3JjbmFtZSk7CisJCQlicmVhazsKKwkJfQorCQkvKiBGQUxMIFRI UlUgKi8KKwljYXNlIEZJTEVfUEhBU0VfMzoKKwkJbG9nX21lc3NhZ2UoTE9H X05PUk1BTCwgXygiUmVuYW1pbmcgbmV3IGZpbGUgdG8gb2xkIGZpbGU6ICIK KwkJCQkiXCclc1wnIC0+IFwnJXNcJyIpLCB0YXJnZXQsIHNyY25hbWUpOwor CQlydmFsID0gcmVuYW1lKHRhcmdldCwgc3JjbmFtZSk7CisJCWlmIChydmFs ICE9IDApIHsKKwkJCS8qIHdlIGNhbid0IGFib3J0IHNpbmNlIHRoZSBzcmMg ZmlsZSBpcyBub3cgZ29uZS4KKwkJCSAqIGxldCB0aGUgYWRtaW4gY2xlYW4g dGhpcyBvbmUgdXAKKwkJCSAqLworCQkJZXJyX21lc3NhZ2UoXygidW5hYmxl IHRvIHJlbmFtZSBmaWxlOiAlcyB0byAlcyIpLAorCQkJCQl0YXJnZXQsIHNy Y25hbWUpOworCQkJYnJlYWs7CisJCX0KKwkJLyogRkFMTCBUSFJVICovCisJ Y2FzZSBGSUxFX1BIQVNFXzQ6CisJCS8qIGZvciBlYWNoIGhhcmRsaW5rLCB1 bmxpbmsgYW5kIGNyZWF0IHBvaW50aW5nIHRvIHRhcmdldCAqLworCQlmb3Ig KGkgPSAxOyBpIDwgbm9kZS0+bnVtcGF0aHM7IGkrKykgeworCQkJaWYgKGkg PT0gMSkKKwkJCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCBfKCJSZXNldHRp bmcgaGFyZGxpbmtzIHRvICIKKwkJCQkJCSJuZXcgZmlsZSIpKTsKKworCQkJ cnZhbCA9IHVubGluayhub2RlLT5wYXRoc1tpXSk7CisJCQlpZiAocnZhbCAh PSAwKSB7CisJCQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIHJlbW92ZSBm aWxlOiAlcyIpLAorCQkJCQkJbm9kZS0+cGF0aHNbaV0pOworCQkJCWJyZWFr OworCQkJfQorCQkJcnZhbCA9IGxpbmsoc3JjbmFtZSwgbm9kZS0+cGF0aHNb aV0pOworCQkJaWYgKHJ2YWwgIT0gMCkgeworCQkJCWVycl9tZXNzYWdlKF8o InVuYWJsZSB0byBsaW5rIHRvIGZpbGU6ICVzIiksCisJCQkJCQlzcmNuYW1l KTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCQlicmVhazsKKwl9CisKKwlp ZiAocnZhbCA9PSAwKSB7CisJCWxvZ19tZXNzYWdlKExPR19OT1JNQUwsIF8o IlJlbW92aW5nIHJlY292ZXIgZmlsZTogXCclc1wnIiksCisJCQkJcmVjb3Zl cl9maWxlKTsKKwkJdW5saW5rKHJlY292ZXJfZmlsZSk7CisJCWxvZ19tZXNz YWdlKExPR19OT1JNQUwsIF8oIlJlY292ZXJ5IGRvbmUuIikpOworCX0KKwll bHNlIHsKKwkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgXygiTGVhdmluZyBy ZWNvdmVyIGZpbGU6IFwnJXNcJyIpLAorCQkJCXJlY292ZXJfZmlsZSk7CisJ CWxvZ19tZXNzYWdlKExPR19OT1JNQUwsIF8oIlJlY292ZXJ5IGZhaWxlZC4i KSk7CisJfQorCisJcmV0dXJuIHJ2YWw7Cit9CisKK2ludAorbWFpbigKKwlp bnQJCWFyZ2MsCisJY2hhcgkJKmFyZ3ZbXSkKK3sKKwlpbnQJCWMgPSAwOwor CWludAkJcnZhbCA9IDA7CisJaW50CQlxX29wdCA9IDA7CisJaW50CQl2X29w dCA9IDA7CisJaW50CQlwX29wdCA9IDA7CisJaW50CQluX29wdCA9IDA7CisJ Y2hhcgkJcGF0aG5hbWVbUEFUSF9NQVhdOworCXN0cnVjdCBzdGF0NjQJc3Q7 CisKKwlwcm9nbmFtZSA9IGJhc2VuYW1lKGFyZ3ZbMF0pOworCisJc2V0bG9j YWxlKExDX0FMTCwgIiIpOworCWJpbmR0ZXh0ZG9tYWluKFBBQ0tBR0UsIExP Q0FMRURJUik7CisJdGV4dGRvbWFpbihQQUNLQUdFKTsKKworCXdoaWxlICgo YyA9IGdldG9wdChhcmdjLCBhcmd2LCAiZm5wcXZQOnI6IikpICE9IC0xKSB7 CisJCXN3aXRjaCAoYykgeworCQljYXNlICdmJzoKKwkJCWZvcmNlX2FsbCA9 IDE7CisJCQlicmVhazsKKwkJY2FzZSAnbic6CisJCQluX29wdCsrOworCQkJ YnJlYWs7CisJCWNhc2UgJ3AnOgorCQkJcF9vcHQrKzsKKwkJCWJyZWFrOwor CQljYXNlICdxJzoKKwkJCWlmICh2X29wdCkKKwkJCQllcnJfbWVzc2FnZShf KCIncScgb3B0aW9uIGluY29tcGF0aWJsZSAiCisJCQkJCQkid2l0aCAndicg b3B0aW9uIikpOworCQkJcV9vcHQrKzsKKwkJCWxvZ19sZXZlbD0wOworCQkJ YnJlYWs7CisJCWNhc2UgJ3YnOgorCQkJaWYgKHFfb3B0KQorCQkJCWVycl9t ZXNzYWdlKF8oIid2JyBvcHRpb24gaW5jb21wYXRpYmxlICIKKwkJCQkJCSJ3 aXRoICdxJyBvcHRpb24iKSk7CisJCQl2X29wdCsrOworCQkJbG9nX2xldmVs Kys7CisJCQlicmVhazsKKwkJY2FzZSAnUCc6CisJCQlwb2xsX2ludGVydmFs ID0gYXRvaShvcHRhcmcpOworCQkJYnJlYWs7CisJCWNhc2UgJ3InOgorCQkJ cmVjb3Zlcl9maWxlID0gb3B0YXJnOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6 CisJCQllcnJfbWVzc2FnZShfKCIlczogaWxsZWdhbCBvcHRpb24gLS0gJWNc biIpLCBjKTsKKwkJCXVzYWdlKCk7CisJCQkvKiBOT1RSRUFDSEVEICovCisJ CQlicmVhazsKKwkJfQorCX0KKworCWlmIChvcHRpbmQgIT0gYXJnYyAtIDEg JiYgcmVjb3Zlcl9maWxlID09IE5VTEwpIHsKKwkJdXNhZ2UoKTsKKwkJZXhp dCgxKTsKKwl9CisKKwlyZWFsdWlkID0gZ2V0dWlkKCk7CisJc3RhcnR0aW1l ID0gdGltZSgwKTsKKworCWluaXRfbm9kZWhhc2goKTsKKworCXNpZ25hbChT SUdBTFJNLCBzaWdoYW5kbGVyKTsKKwlzaWduYWwoU0lHQUJSVCwgc2lnaGFu ZGxlcik7CisJc2lnbmFsKFNJR0hVUCwgc2lnaGFuZGxlcik7CisJc2lnbmFs KFNJR0lOVCwgc2lnaGFuZGxlcik7CisJc2lnbmFsKFNJR1FVSVQsIHNpZ2hh bmRsZXIpOworCXNpZ25hbChTSUdURVJNLCBzaWdoYW5kbGVyKTsKKworCWlm IChwX29wdCAmJiBwb2xsX2ludGVydmFsID09IDApIHsKKwkJcG9sbF9pbnRl cnZhbCA9IDE7CisJfQorCWlmIChwb2xsX2ludGVydmFsKQorCQlhbGFybShw b2xsX2ludGVydmFsKTsKKworCWlmIChyZWNvdmVyX2ZpbGUpIHsKKwkJYmln bm9kZV90CSpub2RlID0gTlVMTDsKKwkJY2hhcgkJKnRhcmdldCA9IE5VTEw7 CisJCWNoYXIJCSp0bmFtZSA9IE5VTEw7CisJCWludAkJcGhhc2UgPSAwOwor CisJCWlmIChuX29wdCkKKwkJCWdvdG8gcXVpdDsKKworCQkvKiByZWFkIG5v ZGUgaW5mbyBmcm9tIHJlY292ZXJ5IGZpbGUgKi8KKwkJaWYgKHJlYWRfcmVj b3Zlcl9maWxlKHJlY292ZXJfZmlsZSwgJm5vZGUsICZ0YXJnZXQsCisJCQkJ JnRuYW1lLCAmcGhhc2UpICE9IDApCisJCQlleGl0KDEpOworCisJCXJ2YWwg PSByZWNvdmVyKG5vZGUsIHRhcmdldCwgdG5hbWUsIHBoYXNlKTsKKworCQlm cmVlKHRhcmdldCk7CisJCWZyZWUodG5hbWUpOworCisJCXJldHVybiBydmFs OworCX0KKworCXJlY292ZXJfZmlsZSA9IG1hbGxvYyhQQVRIX01BWCk7CisJ aWYgKHJlY292ZXJfZmlsZSA9PSBOVUxMKSB7CisJCWVycl9ub21lbSgpOwor CQlleGl0KDEpOworCX0KKwlyZWNvdmVyX2ZpbGVbMF0gPSAnXDAnOworCisJ c3RyY3B5KHBhdGhuYW1lLCBhcmd2W29wdGluZF0pOworCWlmIChwYXRobmFt ZVswXSAhPSAnLycpIHsKKwkJZXJyX21lc3NhZ2UoXygicGF0aG5hbWUgbXVz dCBiZWdpbiB3aXRoIGEgc2xhc2ggKCcvJykiKSk7CisJCWV4aXQoMSk7CisJ fQorCisJaWYgKHN0YXQ2NChwYXRobmFtZSwgJnN0KSA8IDApIHsKKwkJZXJy X3N0YXQocGF0aG5hbWUpOworCQlleGl0KDEpOworCX0KKwlpZiAoU19JU1JF RyhzdC5zdF9tb2RlKSkgeworCQkvKiBzaW5nbGUgZmlsZSBzcGVjaWZpZWQg Ki8KKwkJaWYgKHN0LnN0X25saW5rID4gMSkgeworCQkJZXJyX21lc3NhZ2Uo XygiY2Fubm90IHByb2Nlc3Mgc2luZ2xlIGZpbGUgd2l0aCBhICIKKwkJCQkJ ImxpbmsgY291bnQgZ3JlYXRlciB0aGFuIDEiKSk7CisJCQlleGl0KDEpOwor CQl9CisKKwkJc3RyY3B5KHJlY292ZXJfZmlsZSwgcGF0aG5hbWUpOworCQlk aXJuYW1lKHJlY292ZXJfZmlsZSk7CisKKwkJc3RyY3B5KHJlY292ZXJfZmls ZSArIHN0cmxlbihyZWNvdmVyX2ZpbGUpLCAiL3hmc19yZW5vLnJlY292ZXIi KTsKKwkJaWYgKCFuX29wdCkgeworCQkJaWYgKG9wZW5fcmVjb3ZlcmZpbGUo KSAhPSAwKQorCQkJCWV4aXQoMSk7CisJCX0KKwkJYWRkX25vZGVfcGF0aChz dC5zdF9pbm8sIEZUV19GLCBwYXRobmFtZSk7CisJfQorCWVsc2UgaWYgKFNf SVNESVIoc3Quc3RfbW9kZSkpIHsKKwkJLyogZGlyZWN0b3J5IHRyZWUgc3Bl Y2lmaWVkICovCisJCXN0cmNweShyZWNvdmVyX2ZpbGUsIHBhdGhuYW1lKTsK KworCQlzdHJjcHkocmVjb3Zlcl9maWxlICsgc3RybGVuKHJlY292ZXJfZmls ZSksICIveGZzX3Jlbm8ucmVjb3ZlciIpOworCQlpZiAoIW5fb3B0KSB7CisJ CQlpZiAob3Blbl9yZWNvdmVyZmlsZSgpICE9IDApCisJCQkJZXhpdCgxKTsK KwkJfQorCisJCS8qIGRpcmVjdG9yeSBzY2FuICovCisJCWxvZ19tZXNzYWdl KExPR19JTkZPLCBfKCJcclNjYW5uaW5nIGRpcmVjdG9yeSB0cmVlLi4uIikp OworCQlTRVRfUEhBU0UoU0NBTl9QSEFTRSk7CisJCW5mdHc2NChwYXRobmFt ZSwgbmZ0d19hZGRub2RlcywgMTAwLCBGVFdfUEhZUyB8IEZUV19NT1VOVCk7 CisJfQorCWVsc2UgeworCQllcnJfbWVzc2FnZShfKCJwYXRobmFtZSBtdXN0 IGJlIGVpdGhlciBhIHJlZ3VsYXIgZmlsZSAiCisJCQkJIm9yIGRpcmVjdG9y eSIpKTsKKwkJZXhpdCgxKTsKKwl9CisKKwlkdW1wX25vZGVoYXNoKCk7CisK KwlpZiAobl9vcHQpIHsKKwkJLyogbiBmbGFnIHNldCwgZG9uJ3QgZG8gYW55 dGhpbmcgKi8KKwkJaWYgKG51bWRpcm5vZGVzKQorCQkJbG9nX21lc3NhZ2Uo TE9HX05PUk1BTCwgIlxyV291bGQgcHJvY2VzcyAlZCAlcyIsCisJCQkJCW51 bWRpcm5vZGVzLCBudW1kaXJub2RlcyA9PSAxID8KKwkJCQkJCSJkaXJlY3Rv cnkiIDogImRpcmVjdG9yaWVzIik7CisJCWVsc2UKKwkJCWxvZ19tZXNzYWdl KExPR19OT1JNQUwsICJcck5vIGRpcmVjdG9yaWVzIHRvIHByb2Nlc3MiKTsK KworCQlpZiAobnVtZmlsZW5vZGVzKQorCQkJLyogcHJvY2VzcyBmaWxlcyAq LworCQkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgIlxyV291bGQgcHJvY2Vz cyAlZCAlcyIsCisJCQkJCW51bWZpbGVub2RlcywgbnVtZmlsZW5vZGVzID09 IDEgPworCQkJCQkJImZpbGUiIDogImZpbGVzIik7CisJCWVsc2UKKwkJCWxv Z19tZXNzYWdlKExPR19OT1JNQUwsICJcck5vIGZpbGVzIHRvIHByb2Nlc3Mi KTsKKwl9IGVsc2UgeworCQkvKiBwcm9jZXNzIGRpcmVjdG9yaWVzICovCisJ CWlmIChudW1kaXJub2RlcykgeworCQkJbG9nX21lc3NhZ2UoTE9HX0lORk8s IF8oIlxyUHJvY2Vzc2luZyAlZCAlcy4uLiIpLAorCQkJCQludW1kaXJub2Rl cywgbnVtZGlybm9kZXMgPT0gMSA/CisJCQkJCSAgICBfKCJkaXJlY3Rvcnki KSA6IF8oImRpcmVjdG9yaWVzIikpOworCQkJY3VyX3BoYXNlID0gRElSX1BI QVNFOworCQkJcnZhbCA9IGZvcl9hbGxfbm9kZXMocHJvY2Vzc19kaXIsIEZU V19ELCAxKTsKKwkJCWlmIChydmFsICE9IDApCisJCQkJZ290byBxdWl0Owor CQl9CisJCWVsc2UKKwkJCWxvZ19tZXNzYWdlKExPR19JTkZPLCBfKCJcck5v IGRpcmVjdG9yaWVzIHRvIHByb2Nlc3MuLi4iKSk7CisKKwkJaWYgKG51bWZp bGVub2RlcykgeworCQkJLyogcHJvY2VzcyBmaWxlcyAqLworCQkJbG9nX21l c3NhZ2UoTE9HX0lORk8sIF8oIlxyUHJvY2Vzc2luZyAlZCAlcy4uLiIpLAor CQkJCQludW1maWxlbm9kZXMsIG51bWZpbGVub2RlcyA9PSAxID8KKwkJCQkJ CV8oImZpbGUiKSA6IF8oImZpbGVzIikpOworCQkJY3VyX3BoYXNlID0gRklM RV9QSEFTRTsKKwkJCWZvcl9hbGxfbm9kZXMocHJvY2Vzc19maWxlLCBGVFdf RiwgMCk7CisJCX0KKwkJZWxzZQorCQkJbG9nX21lc3NhZ2UoTE9HX0lORk8s IF8oIlxyTm8gZmlsZXMgdG8gcHJvY2Vzcy4uLiIpKTsKKwl9CitxdWl0Ogor CWZyZWVfbm9kZWhhc2goKTsKKworCWNsb3NlKHJlY292ZXJfZmQpOworCisJ aWYgKHJ2YWwgPT0gMCkKKwkJdW5saW5rKHJlY292ZXJfZmlsZSk7CisKKwls b2dfbWVzc2FnZShMT0dfREVCVUcsICJcciV1IHNlY29uZHMgZWxhcHNlZCIs IHRpbWUoMCkgLSBzdGFydHRpbWUpOworCWxvZ19tZXNzYWdlKExPR19JTkZP LCBfKCJcckRvbmUuIikpOworCisJcmV0dXJuIHJ2YWwgfCBnbG9iYWxfcnZh bDsKK30K ------------CjDhNP1TBpgHu0GSrkBaa0-- From owner-xfs@oss.sgi.com Tue Oct 2 00:17:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 00:17:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l927HYgi007751 for ; Tue, 2 Oct 2007 00:17:36 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 3FC1392CCDD; Tue, 2 Oct 2007 17:17:33 +1000 (EST) Subject: Re: REVIEW: xfs_reno From: Nathan Scott Reply-To: nscott@aconex.com To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev In-Reply-To: References: Content-Type: text/plain Organization: Aconex Date: Tue, 02 Oct 2007 17:20:01 +1000 Message-Id: <1191309601.15908.217.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13212 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2007-10-02 at 17:08 +1000, Barry Naujok wrote: > The attached tool allows an inode64 filesystem to be converted to inode32. > For this to work, the filesystem has to be mounted inode32 before it's run. > > I'm not sure if there is any packaging changes required. I expect not, the Makefile handles that. Is there a man page? cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Oct 2 01:11:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 01:11:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_66,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l928B1qT016937 for ; Tue, 2 Oct 2007 01:11:04 -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 C3C8522EBE for ; Tue, 2 Oct 2007 10:11:01 +0200 (CEST) From: Andi Kleen Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) To: xfs@oss.sgi.com Subject: [PATCH] Replace XFS bit functions with Linux functions Date: Tue, 2 Oct 2007 10:10:58 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710021010.58284.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13213 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 XFS had some own functions to find high and low bits. This patch replaces them with a call to the respective Linux functions. The semantics of the Linux functions differ a little, but i checked all call sites that they can deal with that. I think all callers are ok; but i added a few more asserts for the 0 case (where Linux and old XFS differ) just to make it easy to detect mistakes. The resulting xfs.ko is about 500 bytes smaller on x86-64 This is similar to the patch Eric sent some days ago, but does it more efficiently imho. It replaces his patch. I wasn't able to do a full XFS QA run over this unfortunately; but did careful review. Signed-off-by: Andi Kleen Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.c =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_bit.c +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.c @@ -22,112 +22,9 @@ #include "xfs_buf_item.h" /* - * XFS bit manipulation routines, used in non-realtime code. + * XFS bit manipulation routines */ -#ifndef HAVE_ARCH_HIGHBIT -/* - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. - */ -static const char xfs_highbit[256] = { - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ -}; -#endif - -/* - * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. - */ -inline int -xfs_highbit32( - __uint32_t v) -{ -#ifdef HAVE_ARCH_HIGHBIT - return highbit32(v); -#else - int i; - - if (v & 0xffff0000) - if (v & 0xff000000) - i = 24; - else - i = 16; - else if (v & 0x0000ffff) - if (v & 0x0000ff00) - i = 8; - else - i = 0; - else - return -1; - return i + xfs_highbit[(v >> i) & 0xff]; -#endif -} - -/* - * xfs_lowbit64: get low bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_lowbit64( - __uint64_t v) -{ - __uint32_t w = (__uint32_t)v; - int n = 0; - - if (w) { /* lower bits */ - n = ffs(w); - } else { /* upper bits */ - w = (__uint32_t)(v >> 32); - if (w && (n = ffs(w))) - n += 32; - } - return n - 1; -} - -/* - * xfs_highbit64: get high bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_highbit64( - __uint64_t v) -{ - __uint32_t h = (__uint32_t)(v >> 32); - - if (h) - return xfs_highbit32(h) + 32; - return xfs_highbit32((__uint32_t)v); -} - - /* * Return whether bitmap is empty. * Size is number of words in the bitmap, which is padded to word boundary Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.h =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_bit.h +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.h @@ -46,15 +46,6 @@ static inline __uint64_t xfs_mask64lo(in return ((__uint64_t)1 << (n)) - 1; } -/* Get high bit set out of 32-bit argument, -1 if none set */ -extern int xfs_highbit32(__uint32_t v); - -/* Get low bit set out of 64-bit argument, -1 if none set */ -extern int xfs_lowbit64(__uint64_t v); - -/* Get high bit set out of 64-bit argument, -1 if none set */ -extern int xfs_highbit64(__uint64_t); - /* Return whether bitmap is empty (1 == empty) */ extern int xfs_bitmap_empty(uint *map, uint size); Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_iget.c +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c @@ -55,8 +55,7 @@ xfs_ihash_init(xfs_mount_t *mp) if (!mp->m_ihsize) { icount = mp->m_maxicount ? mp->m_maxicount : (mp->m_sb.sb_dblocks << mp->m_sb.sb_inopblog); - mp->m_ihsize = 1 << max_t(uint, 8, - (xfs_highbit64(icount) + 1) / 2); + mp->m_ihsize = 1 << max_t(uint, 8, fls64(icount) / 2); mp->m_ihsize = min_t(uint, mp->m_ihsize, (64 * NBPP) / sizeof(xfs_ihash_t)); } Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_mount.c +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_mount.c @@ -439,7 +439,7 @@ xfs_xlatesb( mem_ptr = (xfs_caddr_t)sb; while (fields) { - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields,64); first = xfs_sb_info[f].offset; size = xfs_sb_info[f + 1].offset - first; @@ -589,7 +589,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; mp->m_sectbb_log = sbp->sb_sectlog - BBSHIFT; - mp->m_agno_log = xfs_highbit32(sbp->sb_agcount - 1) + 1; + mp->m_agno_log = fls(sbp->sb_agcount - 1); mp->m_agino_log = sbp->sb_inopblog + sbp->sb_agblklog; mp->m_litino = sbp->sb_inodesize - ((uint)sizeof(xfs_dinode_core_t) + (uint)sizeof(xfs_agino_t)); @@ -1428,11 +1428,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi /* find modified range */ - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields, 64); ASSERT((1LL << f) & XFS_SB_MOD_BITS); first = xfs_sb_info[f].offset; - f = (xfs_sb_field_t)xfs_highbit64((__uint64_t)fields); + f = (xfs_sb_field_t)fls64((__uint64_t)fields) - 1; ASSERT((1LL << f) & XFS_SB_MOD_BITS); last = xfs_sb_info[f + 1].offset - 1; Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.h =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_rtalloc.h +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.h @@ -60,13 +60,19 @@ struct xfs_trans; #define XFS_RTMIN(a,b) ((a) < (b) ? (a) : (b)) #define XFS_RTMAX(a,b) ((a) > (b) ? (a) : (b)) -#define XFS_RTLOBIT(w) xfs_lowbit32(w) -#define XFS_RTHIBIT(w) xfs_highbit32(w) +/* All callers check for 0 arguments already; so no -1 handling */ +static inline int xfs_rtlobit(unsigned long v) +{ + return find_first_bit(&v, 32); +} + +#define XFS_RTLOBIT(w) xfs_rtlobit(w) +#define XFS_RTHIBIT(w) (fls(w) - 1) #if XFS_BIG_BLKNOS -#define XFS_RTBLOCKLOG(b) xfs_highbit64(b) +#define XFS_RTBLOCKLOG(b) (fls64(b) - 1) #else -#define XFS_RTBLOCKLOG(b) xfs_highbit32(b) +#define XFS_RTBLOCKLOG(b) (fls(b) - 1) #endif Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.c =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_rtalloc.c +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.c @@ -73,18 +73,6 @@ STATIC int xfs_rtmodify_summary(xfs_moun */ /* - * xfs_lowbit32: get low bit set out of 32-bit argument, -1 if none set. - */ -STATIC int -xfs_lowbit32( - __uint32_t v) -{ - if (v) - return ffs(v) - 1; - return -1; -} - -/* * Allocate space to the bitmap or summary file, and zero it, for growfs. */ STATIC int /* error */ @@ -444,7 +432,8 @@ xfs_rtallocate_extent_near( } bbno = XFS_BITTOBLOCK(mp, bno); i = 0; - log2len = xfs_highbit32(minlen); + ASSERT(minlen != 0); + log2len = fls(minlen) - 1; /* * Loop over all bitmap blocks (bbno + i is current block). */ @@ -607,11 +596,13 @@ xfs_rtallocate_extent_size( int error; /* error value */ int i; /* bitmap block number */ int l; /* level number (loop control) */ + int end; xfs_rtblock_t n; /* next block to be tried */ xfs_rtblock_t r; /* result block number */ xfs_suminfo_t sum; /* summary information for extents */ ASSERT(minlen % prod == 0 && maxlen % prod == 0); + ASSERT(maxlen != 0); /* * Loop over all the levels starting with maxlen. * At each level, look at all the bitmap blocks, to see if there @@ -619,7 +610,7 @@ xfs_rtallocate_extent_size( * Note, only on the initial level can the allocation fail if * the summary says there's an extent. */ - for (l = xfs_highbit32(maxlen); l < mp->m_rsumlevels; l++) { + for (l = fls(maxlen) - 1; l < mp->m_rsumlevels; l++) { /* * Loop over all the bitmap blocks. */ @@ -669,12 +660,15 @@ xfs_rtallocate_extent_size( *rtblock = NULLRTBLOCK; return 0; } + ASSERT(maxlen != 0); + ASSERT(minlen != 0); /* * Loop over sizes, from maxlen down to minlen. * This time, when we do the allocations, allow smaller ones * to succeed. */ - for (l = xfs_highbit32(maxlen); l >= xfs_highbit32(minlen); l--) { + end = fls(minlen) - 1; + for (l = fls(maxlen) - 1; l >= end; l--) { /* * Loop over all the bitmap blocks, try an allocation * starting in that block. @@ -1863,7 +1857,6 @@ xfs_growfs_rt( xfs_drfsbno_t nrblocks; /* new number of realtime blocks */ xfs_extlen_t nrbmblocks; /* new number of rt bitmap blocks */ xfs_drtbno_t nrextents; /* new number of realtime extents */ - uint8_t nrextslog; /* new log2 of sb_rextents */ xfs_extlen_t nrsumblocks; /* new number of summary blocks */ uint nrsumlevels; /* new rt summary levels */ uint nrsumsize; /* new size of rt summary, bytes */ @@ -1900,8 +1893,7 @@ xfs_growfs_rt( nrextents = nrblocks; do_div(nrextents, in->extsize); nrbmblocks = howmany_64(nrextents, NBBY * sbp->sb_blocksize); - nrextslog = xfs_highbit32(nrextents); - nrsumlevels = nrextslog + 1; + nrsumlevels = fls(nrextents); nrsumsize = (uint)sizeof(xfs_suminfo_t) * nrsumlevels * nrbmblocks; nrsumblocks = XFS_B_TO_FSB(mp, nrsumsize); nrsumsize = XFS_FSB_TO_B(mp, nrsumblocks); @@ -1954,7 +1946,8 @@ xfs_growfs_rt( nsbp->sb_blocksize * nsbp->sb_rextsize); nsbp->sb_rextents = nsbp->sb_rblocks; do_div(nsbp->sb_rextents, nsbp->sb_rextsize); - nsbp->sb_rextslog = xfs_highbit32(nsbp->sb_rextents); + ASSERT(nsbp->sb_rextents != 0); + nsbp->sb_rextslog = fls(nsbp->sb_rextents) - 1; nrsumlevels = nmp->m_rsumlevels = nsbp->sb_rextslog + 1; nrsumsize = (uint)sizeof(xfs_suminfo_t) * nrsumlevels * @@ -2317,9 +2310,10 @@ xfs_rtpick_extent( *seqp = 0; } seq = *seqp; - if ((log2 = xfs_highbit64(seq)) == -1) + if ((log2 = fls64(seq)) == 0) b = 0; else { + log2--; resid = seq - (1ULL << log2); b = (mp->m_sb.sb_rextents * ((resid << 1) + 1ULL)) >> (log2 + 1); Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_ialloc.h =================================================================== --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_ialloc.h +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_ialloc.h @@ -57,10 +57,10 @@ xfs_make_iptr(struct xfs_mount *mp, stru #define XFS_IALLOC_FIND_FREE(fp) xfs_ialloc_find_free(fp) static inline int xfs_ialloc_find_free(xfs_inofree_t *fp) { - return xfs_lowbit64(*fp); + unsigned long v = *fp; /* Guarantee alignment */ + return find_first_bit(&v, 64); } - #ifdef __KERNEL__ /* * Allocate an inode on disk. From owner-xfs@oss.sgi.com Tue Oct 2 01:43:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 01:43:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l928h7iC021081 for ; Tue, 2 Oct 2007 01:43:08 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id C98DA1C099243; Tue, 2 Oct 2007 04:43:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C6C934020DA5; Tue, 2 Oct 2007 04:43:07 -0400 (EDT) Date: Tue, 2 Oct 2007 04:43:07 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Lachlan McIlroy cc: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit In-Reply-To: <4701ED51.8050706@sgi.com> Message-ID: References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13214 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 On Tue, 2 Oct 2007, Lachlan McIlroy wrote: > Timothy Shimmin wrote: >> Eric Sandeen wrote: >>> Tim Shimmin wrote: >>>> Hi Linus, >>>> >>>> A problem has been found for the XFS commit >>>> b394e43e995d08821588a22561c6a71a63b4ff27 >>>> and it needs to be reverted. >>>> It has the potential for worse corruption than what it is meant to fix. >>> >>> >>> Whoops... that's what I get for picking it up too soon for fedora I guess! >>> >>> Any background on the newly-found problem, for those of us in the peanut >>> gallery? >>> >>> Thanks, >>> >>> -Eric >> >> Hi Eric, >> >> Lachlan worked this problem so he can probably provide more details. >> My understanding is that we were having a problem with the log replay >> replaying newly allocated inodes (inodes from buffer items) over the top >> of buffers which were actually more up-to-date than what was logged. >> The code used a heuristic to determine if the buffer had been written >> to for the inode (by checking on magic#, mode and gen# - not going to >> comment on this). >> Anyway, it comes down to either copying over the inode buf data or not >> copying it over (doing or not doing the log replay). >> The change could cause the buffer to be not overwritten in replay >> where previously it would be. >> We want this to not happen as part of the fix and doing the right thing >> and not by mistake and failing to replay when we need it to be replayed. >> I presume the latter is what is happening. >> The symptoms of this is what Lachlan has discovered in QA on a debug >> kernel and he can provide the details. >> >> I believe this started from not logging the inode size changes >> (as is consistent with the logging model) for performance reasons, >> and so we can't rely on inode log items coming up on log replay >> to fix things up. >> >> BTW, we currently have 3 ways of logging an inode: >> 1. in an item buffer and marked as an inode >> 2. in an item buffer and not marked as an inode >> 3. in an inode item >> >> and 3 places where they get replayed: >> 1. xlog_recover_do_inode_buffer - for di_next_unlinked pointer recovery >> 2. xlog_recover_do_reg_buffer - for newly allocated inode recovery >> 3. xlog_recover_do_inode_trans - for general inode recovery >> >> The fix was in #2. >> >> >> Ughh. > > Yeah that about sums it up. In an attempt to prevent log replay of inodes > in cases when we shouldn't replay we also prevented log replay of inodes in > cases when we should replay. We end up with directories that refer to inodes > that were not replayed and we read existing data off disk. That existing > data is usually previous instances of inodes. We had cases of regular files > turning into directories and inode version mismatches. > > Lachlan > In 2.6.23-rc8? From owner-xfs@oss.sgi.com Tue Oct 2 02:20:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:20:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l929K1om026148 for ; Tue, 2 Oct 2007 02:20:06 -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 TAA26930; Tue, 2 Oct 2007 19:19:53 +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 l929JqdD46651635; Tue, 2 Oct 2007 19:19:53 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l929JpA247397775; Tue, 2 Oct 2007 19:19:51 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 2 Oct 2007 19:19:51 +1000 From: David Chinner To: Christoph Hellwig Cc: Barry Naujok , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno Message-ID: <20071002091951.GE995458@sgi.com> References: <20071002090216.GA22721@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002090216.GA22721@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13215 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 On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote: > On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote: > > > > The attached tool allows an inode64 filesystem to be converted to inode32. > > For this to work, the filesystem has to be mounted inode32 before it's run. > > > > I'm not sure if there is any packaging changes required. > > Together with the stop allocating from specific AGs patch this should be > 90% towards an xfs_shrinkfs, right? Well, this just moves the inodes - it's one piece of the puzzle. We still need to collide xfs_fsr with xfs_reno to move the data. After that, we need to work out how to move the orphan metadata blocks out of the AGs that are to be truncated off. That's not simple.... After that, we need the transaction to shrink the fs. At that point, we'll got a "working" shrink that will allow shrinking to only 50% of the original size because the log will get in the way. To fix that, we'll need to implement transactions to move the log... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 02:25:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:25:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l929PHYa027363 for ; Tue, 2 Oct 2007 02:25:24 -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 TAA27036; Tue, 2 Oct 2007 19:25:15 +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 l929PDdD47296546; Tue, 2 Oct 2007 19:25:14 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l929PAIh47379255; Tue, 2 Oct 2007 19:25:10 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 2 Oct 2007 19:25:10 +1000 From: David Chinner To: Andi Kleen Cc: Timothy Shimmin , Martin Steigerwald , xfs@oss.sgi.com Subject: Re: Creation time in XFS Message-ID: <20071002092509.GF995458@sgi.com> References: <200709302124.38164.Martin@lichtvoll.de> <470042DC.2040009@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13216 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 On Mon, Oct 01, 2007 at 11:30:01AM +0200, Andi Kleen wrote: > Timothy Shimmin writes: > > > No XFS does not support creation time. It just has the regular > > atime,mtime and ctime. > > There are no plans that I've heard to support it. > > Not much involved to support it AFAICT but it would either involve > > changing the ondisk format of the inode or storing it in an EA. > > If you ever change the on disk format adding a file type similar to ext3 > to directories could also greatly speed up find in many cases. Sure, but that's the directory structure, not inode structure. They have different versioning methods, and so can be modified independently. FWIW, I haven't forgotten abou thtis request, Andi ;) I'll be modifying the directory structure for CRCs relatively soon, and I plan to do that modification at the same time so I only need a single version bump for both.... > > I wonder how this creation time is being exported currently? > > I don't think it is at all currently: So what is the point? Forensic analysis? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 02:27:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:27:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l929R81R027851 for ; Tue, 2 Oct 2007 02:27:09 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Icddw-0005wg-Tl; Tue, 02 Oct 2007 10:02:16 +0100 Date: Tue, 2 Oct 2007 10:02:16 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno Message-ID: <20071002090216.GA22721@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13217 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 On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote: > > The attached tool allows an inode64 filesystem to be converted to inode32. > For this to work, the filesystem has to be mounted inode32 before it's run. > > I'm not sure if there is any packaging changes required. Together with the stop allocating from specific AGs patch this should be 90% towards an xfs_shrinkfs, right? From owner-xfs@oss.sgi.com Tue Oct 2 02:36:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:36:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l929aXwG029146 for ; Tue, 2 Oct 2007 02:36:36 -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 TAA27335; Tue, 2 Oct 2007 19:36:31 +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 l929aUdD47392317; Tue, 2 Oct 2007 19:36:31 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l929aTNs47358461; Tue, 2 Oct 2007 19:36:29 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 2 Oct 2007 19:36:29 +1000 From: David Chinner To: Lachlan McIlroy Cc: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit Message-ID: <20071002093629.GG995458@sgi.com> References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4701ED51.8050706@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13218 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 On Tue, Oct 02, 2007 at 05:03:45PM +1000, Lachlan McIlroy wrote: > Yeah that about sums it up. In an attempt to prevent log replay of inodes > in cases when we shouldn't replay we also prevented log replay of inodes in > cases when we should replay. We end up with directories that refer to > inodes > that were not replayed and we read existing data off disk. That existing > data is usually previous instances of inodes. We had cases of regular files > turning into directories and inode version mismatches. The issue that started tripping this was stale inodes from a previous filesystem being detected as valid clusters of inodes. Hence inodes magically changed from what they were supposed to be and that caused all sorts of problems. FWIW, in a past life XFS was supposed to store the uuid of the filesystem in it's inodes to prevent exactly this sort of confusion, but that was considered expendable and disappeared in version 2 inodes when XFS grew 32bit link counts and project ID's. The padding is still there waiting to be used. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 02:38:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:38:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l929cQmg029694 for ; Tue, 2 Oct 2007 02:38:31 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IceCs-0006UE-Fa; Tue, 02 Oct 2007 10:38:22 +0100 Date: Tue, 2 Oct 2007 10:38:22 +0100 From: Christoph Hellwig To: David Chinner Cc: Andi Kleen , Timothy Shimmin , Martin Steigerwald , xfs@oss.sgi.com Subject: Re: Creation time in XFS Message-ID: <20071002093822.GA24907@infradead.org> References: <200709302124.38164.Martin@lichtvoll.de> <470042DC.2040009@sgi.com> <20071002092509.GF995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002092509.GF995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13219 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 On Tue, Oct 02, 2007 at 07:25:10PM +1000, David Chinner wrote: > > I don't think it is at all currently: > > So what is the point? Forensic analysis? Windows wants it, so I guess they added when they had to bump the inode version anyway in preparation of a user interface for samba. We probably should do the same for XFS when bumping the inode version for the crcs. From owner-xfs@oss.sgi.com Tue Oct 2 02:55:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 02:55:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32 autolearn=no version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l929tPCS031536 for ; Tue, 2 Oct 2007 02:55:26 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IceTN-0006do-AQ; Tue, 02 Oct 2007 10:55:25 +0100 Date: Tue, 2 Oct 2007 10:55:25 +0100 From: Christoph Hellwig To: Andi Kleen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] Replace XFS bit functions with Linux functions Message-ID: <20071002095525.GA25405@infradead.org> References: <200710021010.58284.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710021010.58284.ak@suse.de> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13220 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 On Tue, Oct 02, 2007 at 10:10:58AM +0200, Andi Kleen wrote: > > XFS had some own functions to find high and low bits. > > This patch replaces them with a call to the respective Linux functions. > The semantics of the Linux functions differ a little, but i checked > all call sites that they can deal with that. I think all callers > are ok; but i added a few more asserts for the 0 case (where Linux > and old XFS differ) just to make it easy to detect mistakes. > > The resulting xfs.ko is about 500 bytes smaller on x86-64 > > This is similar to the patch Eric sent some days ago, but does > it more efficiently imho. It replaces his patch. > > I wasn't able to do a full XFS QA run over this unfortunately; but did careful > review. The patch looks like it's against mainline, so there might be some problems applying it to the xfs tree. At least some of the touched functions have changed names and maybe content aswell. > while (fields) { > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields,64); I don't think we should add the case here but rather pass the fields varialble as an unsigned long to start with. > @@ -1428,11 +1428,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi > > /* find modified range */ > > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields, 64); > ASSERT((1LL << f) & XFS_SB_MOD_BITS); > first = xfs_sb_info[f].offset; > > - f = (xfs_sb_field_t)xfs_highbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)fls64((__uint64_t)fields) - 1; Same here. > +/* All callers check for 0 arguments already; so no -1 handling */ > +static inline int xfs_rtlobit(unsigned long v) > +{ > + return find_first_bit(&v, 32); > +} > + > +#define XFS_RTLOBIT(w) xfs_rtlobit(w) I think just a #define XFS_RTLOBIT(w) find_first_bit(&(w), 32) should be fine. Or make it just an inline, but not both a macro an an inline. From owner-xfs@oss.sgi.com Tue Oct 2 03:02:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 03:02:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.4 required=5.0 tests=BAYES_99,J_CHICKENPOX_33, J_CHICKENPOX_72,J_CHICKENPOX_73,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from idaegu.co.kr ([211.224.129.115]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92A27BK032684 for ; Tue, 2 Oct 2007 03:02:09 -0700 Received: from idaegu.co.kr (localhost.localdomain [127.0.0.1]) by idaegu.co.kr (8.12.8/8.12.8) with ESMTP id l9281nTt019981 for ; Tue, 2 Oct 2007 17:01:49 +0900 Received: (from nobody@localhost) by idaegu.co.kr (8.12.8/8.12.8/Submit) id l9281mnS019977; Tue, 2 Oct 2007 17:01:48 +0900 Date: Tue, 2 Oct 2007 17:01:48 +0900 Message-Id: <200710020801.l9281mnS019977@idaegu.co.kr> To: xfs@oss.sgi.com Subject: Online Job Oppurtunity Job Code #534-ASGPD From: Kimcham Fatu Reply-To: kimcham-fatu@hotmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13221 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Gallery@art.com Precedence: bulk X-list: xfs Dear Employee, We have a job offer available for you in response to your initial request in the Job search directory.We are a company based in ASIA; we have been receiving orders from NORTHERN AMERICA, AUSTRALIA, UNITED KINGDOM AND EUROPE which we have not been able to process competently since we do not have a payment receiving personnel in these Areas.We have decided to recruit payment officers online hence we will need a representative to process our payments in these areas, this is due to delays in processing payments from these areas in ASIA. WHAT WE DO OFFER; Flexible program:Two hours / day at your choice, daytime and evening time Work at home: Checking e-mail and going to the bank Part time Professional contact team with very good support and communication skills. Other highlights:No selling involved, no kit to buy, we won't charge you anything. Monthly salary: You would be paid 500GBP every two weeks to a total of 1000GBP per month. Commission:15% of every cheque that is cashed instantly "cash in hand" or "cash on counter" is what you get from the total cashed amount. EXAMPLE;If you receive a check of 1,000.0OGBP your net income is 150.00GBP, our company supports any fees. You will process at least 2-3 orders per day and you will earn more than 300.00 GBP cash in hand each day. REMEMBER: THE MORE ORDERS YOU PROCESS- AT A FASTER RATE THE HIGHER YOU STAND TO EARN DAILY. What we ask:Two free hours daily not including weekends, Internet access for sending and receiving e-mails, available means of cashing cheque at the nearest cashing point. IMPORTANT: 1) You must be over 18 years of age. 2) U.S, UK, CANADIAN OR AUSTRALIAN CITIZENSHIP. If you meet these conditions and wish to apply send this reference position number #534-ASGPD and please contact our recruiting manager through this e-mail address ( kimcham-fatu@hotmail.com ) to receive a Representative Contract agreement. Please ensure you add your Full Details..... Surname, First Name, Middle Name, Contact Address,Or Mailing Address ,Post Code Mobile Phone Number / Fax numbers for quick delivery of payments. Present Occupation, Age, We will never ask you for anything more then that, no bank names, No bank account number, routing number, credit card, passwords, ssn # etc.If anyone asks for those on our behalf please do not give out this info.This is to ensure your security and non involvement in cases of Identity Theft. Thank You for taking your time to read our offer. My Regards, Kimcham Fatu ( Recruiting Manager ) Kimcham Fatu for Gallery Art ltd. B.21/F., Jianjing Building, 1399 Beijing Rd W, Shanghai Shanghai-200040 China. TEL: 817-776-5550 FAX: 817-776-5550 (c) Copyright Reserved 2007 From owner-xfs@oss.sgi.com Tue Oct 2 03:25:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 03:25:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92APAu5003667 for ; Tue, 2 Oct 2007 03:25:11 -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 3F62622D70; Tue, 2 Oct 2007 12:25:10 +0200 (CEST) From: Andi Kleen Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) To: Christoph Hellwig Subject: Re: [PATCH] Replace XFS bit functions with Linux functions Date: Tue, 2 Oct 2007 12:11:47 +0200 User-Agent: KMail/1.9.6 Cc: xfs@oss.sgi.com References: <200710021010.58284.ak@suse.de> <20071002095525.GA25405@infradead.org> In-Reply-To: <20071002095525.GA25405@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710021211.47718.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13222 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 > > > while (fields) { > > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields,64); > > I don't think we should add the case here but rather pass the fields > varialble as an unsigned long to start with. I actually did this first, but ran into some issues I unfortunately can't remember right now so I reverted it to the cast. > > > @@ -1428,11 +1428,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi > > > > /* find modified range */ > > > > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields, 64); > > ASSERT((1LL << f) & XFS_SB_MOD_BITS); > > first = xfs_sb_info[f].offset; > > > > - f = (xfs_sb_field_t)xfs_highbit64((__uint64_t)fields); > > + f = (xfs_sb_field_t)fls64((__uint64_t)fields) - 1; > > Same here. The casts here are actually not needed, but I was too lazy to remove them (they also don't hurt) > > > +/* All callers check for 0 arguments already; so no -1 handling */ > > +static inline int xfs_rtlobit(unsigned long v) > > +{ > > + return find_first_bit(&v, 32); > > +} > > + > > +#define XFS_RTLOBIT(w) xfs_rtlobit(w) > > I think just a > > #define XFS_RTLOBIT(w) find_first_bit(&(w), 32) > > should be fine. Nope -- not all callers pass sufficiently aligned unsigned longs as ffb requires. > Or make it just an inline, but not both a macro an > an inline. That should be probably done as a separate patch because there are much more macros that need this treatment in the rt code. -Andi From owner-xfs@oss.sgi.com Tue Oct 2 03:39:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 03:39:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_99,J_CHICKENPOX_53 autolearn=no version=3.3.0-r574664 Received: from fmmailgate04.web.de (fmmailgate04.web.de [217.72.192.242]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92AdfdR005603 for ; Tue, 2 Oct 2007 03:39:43 -0700 Received: from web.de by fmmailgate04.web.de (Postfix) with SMTP id 5F9AF343BAFD; Tue, 2 Oct 2007 12:11:42 +0200 (CEST) Received: from [85.49.237.239] by freemailng2501.web.de with HTTP; Tue, 02 Oct 2007 12:11:41 +0200 Date: Tue, 02 Oct 2007 12:11:41 +0200 Message-Id: <261780501@web.de> MIME-Version: 1.0 From: cvx cxvbb <1999ses@web.de> To: 1999ses@web.de Subject: PROMOTIONS!! Precedence: fm-user Organization: http://freemail.web.de/ X-Provags-Id: V01U2FsdGVkX1+P65MupExZxWmvvEzx/0imBn4xfKi/q/7g7uiOUvEZEYvrB s8k8qmFZWJFCKPZdKNn83NNporFgei+To5XmeajbF62wwgWD10= Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4452/Mon Oct 1 22:03:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13223 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: 1999ses@web.de Precedence: bulk X-list: xfs PROMOTIONS!! This is to inform you that your Email Address attached to a has won the prize Sum of Four Hundred and Fifty Thousand Euros (450,000.00) Euros, in an Email Loteria Shop Award program held in the-Espaia.Do contact the Details below for your claim agency Contact PROMOTION DATE: 1 October 2007 REFERENCE NUMBER:NES/0601/44/07 BATCH NUMBER:16/612/ACS LUCKY NO:10/23/44/72/80 Your full Names: Telephone: Chalet Financial Services Mr.Jaime Sanchez Tel:+34692473683 Contact Email:Chaletsp2@yahoo.es Congratulations! Please note that you will be required to pay for the issuance of your legal back up and legalization of certificate of deposit document in court,All winnings must be claimed not later than 14 days the age of 18 is automatically, Sincerely yours, Mrs.Moreno Plaza Winning Co -ordinator _________________________________________________________________________ In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=02214 From owner-xfs@oss.sgi.com Tue Oct 2 05:59:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 05:59:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l92Cxess004963 for ; Tue, 2 Oct 2007 05:59:45 -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 WAA01174; Tue, 2 Oct 2007 22:59: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 l92CxRdD47634188; Tue, 2 Oct 2007 22:59:29 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l92CxNs347522970; Tue, 2 Oct 2007 22:59:23 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 2 Oct 2007 22:59:23 +1000 From: David Chinner To: Andi Kleen Cc: xfs@oss.sgi.com, cattelan@thebarn.com Subject: Re: [PATCH] Replace XFS bit functions with Linux functions Message-ID: <20071002125923.GH995458@sgi.com> References: <200710021010.58284.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710021010.58284.ak@suse.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4454/Tue Oct 2 04:59:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13224 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 On Tue, Oct 02, 2007 at 10:10:58AM +0200, Andi Kleen wrote: > XFS had some own functions to find high and low bits. > > This patch replaces them with a call to the respective Linux functions. > The semantics of the Linux functions differ a little, but i checked > all call sites that they can deal with that. I think all callers > are ok; but i added a few more asserts for the 0 case (where Linux > and old XFS differ) just to make it easy to detect mistakes. > > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_iget.c > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c > @@ -55,8 +55,7 @@ xfs_ihash_init(xfs_mount_t *mp) > if (!mp->m_ihsize) { > icount = mp->m_maxicount ? mp->m_maxicount : > (mp->m_sb.sb_dblocks << mp->m_sb.sb_inopblog); > - mp->m_ihsize = 1 << max_t(uint, 8, > - (xfs_highbit64(icount) + 1) / 2); > + mp->m_ihsize = 1 << max_t(uint, 8, fls64(icount) / 2); > mp->m_ihsize = min_t(uint, mp->m_ihsize, > (64 * NBPP) / sizeof(xfs_ihash_t)); > } This is well out of date with where the XFS tree is now. You might want to rebase this on the XFS CVS code or the master branch of the XFS git tree... So the conversion is: xfs_highbit64 -> fls64() - 1 xfs_lowbit64(v) -> find_first_bit(&v, 64) xfs_highbit32 -> fls - 1 xfs_lowbit32(v) -> find_first_bit(&v, 32) and touching lots of places where the xfs functions are used. One thing that is notable here is that the XFS code returns -1 if no bits are set. fls/fls64 return 0 in the same case, so the magic "- 1" will make them behave the same. however, it appears that find_first_bit() will return the number of bits searched. That might leave us with som nasty, non-obvious error cases.... Also, I don't really like the fact it requires sprinkling magic "- 1" adjustments to the return value of the replacement functions. If that is the way the functions work and relate to the XFS bitmaps, then that *should* be hidden away in a macro/static inline so it doesn't get screwed up in future. Hence I'd prefer to keep the xfs wrappers whilst replacing the guts of them with the more efficient generic code. I'm not too concerned, though, but Russell might want to comment here... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 06:35:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 06:35:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92DZS2a010150 for ; Tue, 2 Oct 2007 06:35: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 mx2.suse.de (Postfix) with ESMTP id 33BD622CEC; Tue, 2 Oct 2007 15:35:27 +0200 (CEST) From: Andi Kleen Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) To: David Chinner Subject: Re: [PATCH] Replace XFS bit functions with Linux functions Date: Tue, 2 Oct 2007 15:35:14 +0200 User-Agent: KMail/1.9.6 Cc: xfs@oss.sgi.com, cattelan@thebarn.com References: <200710021010.58284.ak@suse.de> <20071002125923.GH995458@sgi.com> In-Reply-To: <20071002125923.GH995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710021535.14973.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4454/Tue Oct 2 04:59:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13225 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 > One thing that is notable here is that the XFS code returns > -1 if no bits are set. fls/fls64 return 0 in the same case, so > the magic "- 1" will make them behave the same. however, it > appears that find_first_bit() will return the number of bits > searched. That might leave us with som nasty, non-obvious error > cases.... See the changelog: The semantics of the Linux functions differ a little, but i checked all call sites that they can deal with that. > > Also, I don't really like the fact it requires sprinkling magic "- > 1" adjustments to the return value of the replacement functions. If > that is the way the functions work and relate to the XFS bitmaps, Not all callers use them as bitmap indexes, some also use them as true log2s. I also eliminated some + 1s. Whatever you do it's not the same for all. -Andi From owner-xfs@oss.sgi.com Tue Oct 2 09:37:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 09:37:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_66,T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92GbNP6005272 for ; Tue, 2 Oct 2007 09:37:26 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l92GbLgP018907; Tue, 2 Oct 2007 11:37:22 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <470273C1.60300@thebarn.com> Date: Tue, 02 Oct 2007 11:37:21 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: Andi Kleen CC: xfs@oss.sgi.com Subject: Re: [PATCH] Replace XFS bit functions with Linux functions References: <200710021010.58284.ak@suse.de> In-Reply-To: <200710021010.58284.ak@suse.de> Content-Type: multipart/mixed; boundary="------------030900060305090908070809" X-Virus-Scanned: ClamAV 0.91.2/4455/Tue Oct 2 06:49:51 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4456/Tue Oct 2 10:11:59 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13226 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------030900060305090908070809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: > XFS had some own functions to find high and low bits. > > This patch replaces them with a call to the respective Linux functions. > The semantics of the Linux functions differ a little, but i checked > all call sites that they can deal with that. I think all callers > are ok; but i added a few more asserts for the 0 case (where Linux > and old XFS differ) just to make it easy to detect mistakes. > > The resulting xfs.ko is about 500 bytes smaller on x86-64 > > This is similar to the patch Eric sent some days ago, but does > it more efficiently imho. It replaces his patch. > > I wasn't able to do a full XFS QA run over this unfortunately; but did careful > review. > > I would like to keep thing abstracted enough such that it is won't be to difficult keep to map to the FreeBSD bit functions. I have not looked closely at the freebsd functions to see how close they are semantically. > Signed-off-by: Andi Kleen > > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.c > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_bit.c > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.c > @@ -22,112 +22,9 @@ > #include "xfs_buf_item.h" > > /* > - * XFS bit manipulation routines, used in non-realtime code. > + * XFS bit manipulation routines > */ > > -#ifndef HAVE_ARCH_HIGHBIT > -/* > - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. > - */ > -static const char xfs_highbit[256] = { > - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ > - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ > - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ > - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ > - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ > - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ > - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ > - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ > - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ > - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ > -}; > -#endif > - > -/* > - * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. > - */ > -inline int > -xfs_highbit32( > - __uint32_t v) > -{ > -#ifdef HAVE_ARCH_HIGHBIT > - return highbit32(v); > -#else > - int i; > - > - if (v & 0xffff0000) > - if (v & 0xff000000) > - i = 24; > - else > - i = 16; > - else if (v & 0x0000ffff) > - if (v & 0x0000ff00) > - i = 8; > - else > - i = 0; > - else > - return -1; > - return i + xfs_highbit[(v >> i) & 0xff]; > -#endif > -} > - > -/* > - * xfs_lowbit64: get low bit set out of 64-bit argument, -1 if none set. > - */ > -int > -xfs_lowbit64( > - __uint64_t v) > -{ > - __uint32_t w = (__uint32_t)v; > - int n = 0; > - > - if (w) { /* lower bits */ > - n = ffs(w); > - } else { /* upper bits */ > - w = (__uint32_t)(v >> 32); > - if (w && (n = ffs(w))) > - n += 32; > - } > - return n - 1; > -} > - > -/* > - * xfs_highbit64: get high bit set out of 64-bit argument, -1 if none set. > - */ > -int > -xfs_highbit64( > - __uint64_t v) > -{ > - __uint32_t h = (__uint32_t)(v >> 32); > - > - if (h) > - return xfs_highbit32(h) + 32; > - return xfs_highbit32((__uint32_t)v); > -} > - > - > /* > * Return whether bitmap is empty. > * Size is number of words in the bitmap, which is padded to word boundary > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.h > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_bit.h > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_bit.h > @@ -46,15 +46,6 @@ static inline __uint64_t xfs_mask64lo(in > return ((__uint64_t)1 << (n)) - 1; > } > > -/* Get high bit set out of 32-bit argument, -1 if none set */ > -extern int xfs_highbit32(__uint32_t v); > - > -/* Get low bit set out of 64-bit argument, -1 if none set */ > -extern int xfs_lowbit64(__uint64_t v); > - > -/* Get high bit set out of 64-bit argument, -1 if none set */ > -extern int xfs_highbit64(__uint64_t); > - > /* Return whether bitmap is empty (1 == empty) */ > extern int xfs_bitmap_empty(uint *map, uint size); > > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_iget.c > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_iget.c > @@ -55,8 +55,7 @@ xfs_ihash_init(xfs_mount_t *mp) > if (!mp->m_ihsize) { > icount = mp->m_maxicount ? mp->m_maxicount : > (mp->m_sb.sb_dblocks << mp->m_sb.sb_inopblog); > - mp->m_ihsize = 1 << max_t(uint, 8, > - (xfs_highbit64(icount) + 1) / 2); > + mp->m_ihsize = 1 << max_t(uint, 8, fls64(icount) / 2); > mp->m_ihsize = min_t(uint, mp->m_ihsize, > (64 * NBPP) / sizeof(xfs_ihash_t)); > } > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_mount.c > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_mount.c > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_mount.c > @@ -439,7 +439,7 @@ xfs_xlatesb( > mem_ptr = (xfs_caddr_t)sb; > > while (fields) { > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields,64); > first = xfs_sb_info[f].offset; > size = xfs_sb_info[f + 1].offset - first; > > @@ -589,7 +589,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb > mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; > mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; > mp->m_sectbb_log = sbp->sb_sectlog - BBSHIFT; > - mp->m_agno_log = xfs_highbit32(sbp->sb_agcount - 1) + 1; > + mp->m_agno_log = fls(sbp->sb_agcount - 1); > mp->m_agino_log = sbp->sb_inopblog + sbp->sb_agblklog; > mp->m_litino = sbp->sb_inodesize - > ((uint)sizeof(xfs_dinode_core_t) + (uint)sizeof(xfs_agino_t)); > @@ -1428,11 +1428,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi > > /* find modified range */ > > - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields, 64); > ASSERT((1LL << f) & XFS_SB_MOD_BITS); > first = xfs_sb_info[f].offset; > > - f = (xfs_sb_field_t)xfs_highbit64((__uint64_t)fields); > + f = (xfs_sb_field_t)fls64((__uint64_t)fields) - 1; > ASSERT((1LL << f) & XFS_SB_MOD_BITS); > last = xfs_sb_info[f + 1].offset - 1; > > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.h > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_rtalloc.h > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.h > @@ -60,13 +60,19 @@ struct xfs_trans; > #define XFS_RTMIN(a,b) ((a) < (b) ? (a) : (b)) > #define XFS_RTMAX(a,b) ((a) > (b) ? (a) : (b)) > > -#define XFS_RTLOBIT(w) xfs_lowbit32(w) > -#define XFS_RTHIBIT(w) xfs_highbit32(w) > +/* All callers check for 0 arguments already; so no -1 handling */ > +static inline int xfs_rtlobit(unsigned long v) > +{ > + return find_first_bit(&v, 32); > +} > + > +#define XFS_RTLOBIT(w) xfs_rtlobit(w) > +#define XFS_RTHIBIT(w) (fls(w) - 1) > > #if XFS_BIG_BLKNOS > -#define XFS_RTBLOCKLOG(b) xfs_highbit64(b) > +#define XFS_RTBLOCKLOG(b) (fls64(b) - 1) > #else > -#define XFS_RTBLOCKLOG(b) xfs_highbit32(b) > +#define XFS_RTBLOCKLOG(b) (fls(b) - 1) > #endif > > > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.c > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_rtalloc.c > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_rtalloc.c > @@ -73,18 +73,6 @@ STATIC int xfs_rtmodify_summary(xfs_moun > */ > > /* > - * xfs_lowbit32: get low bit set out of 32-bit argument, -1 if none set. > - */ > -STATIC int > -xfs_lowbit32( > - __uint32_t v) > -{ > - if (v) > - return ffs(v) - 1; > - return -1; > -} > - > -/* > * Allocate space to the bitmap or summary file, and zero it, for growfs. > */ > STATIC int /* error */ > @@ -444,7 +432,8 @@ xfs_rtallocate_extent_near( > } > bbno = XFS_BITTOBLOCK(mp, bno); > i = 0; > - log2len = xfs_highbit32(minlen); > + ASSERT(minlen != 0); > + log2len = fls(minlen) - 1; > /* > * Loop over all bitmap blocks (bbno + i is current block). > */ > @@ -607,11 +596,13 @@ xfs_rtallocate_extent_size( > int error; /* error value */ > int i; /* bitmap block number */ > int l; /* level number (loop control) */ > + int end; > xfs_rtblock_t n; /* next block to be tried */ > xfs_rtblock_t r; /* result block number */ > xfs_suminfo_t sum; /* summary information for extents */ > > ASSERT(minlen % prod == 0 && maxlen % prod == 0); > + ASSERT(maxlen != 0); > /* > * Loop over all the levels starting with maxlen. > * At each level, look at all the bitmap blocks, to see if there > @@ -619,7 +610,7 @@ xfs_rtallocate_extent_size( > * Note, only on the initial level can the allocation fail if > * the summary says there's an extent. > */ > - for (l = xfs_highbit32(maxlen); l < mp->m_rsumlevels; l++) { > + for (l = fls(maxlen) - 1; l < mp->m_rsumlevels; l++) { > /* > * Loop over all the bitmap blocks. > */ > @@ -669,12 +660,15 @@ xfs_rtallocate_extent_size( > *rtblock = NULLRTBLOCK; > return 0; > } > + ASSERT(maxlen != 0); > + ASSERT(minlen != 0); > /* > * Loop over sizes, from maxlen down to minlen. > * This time, when we do the allocations, allow smaller ones > * to succeed. > */ > - for (l = xfs_highbit32(maxlen); l >= xfs_highbit32(minlen); l--) { > + end = fls(minlen) - 1; > + for (l = fls(maxlen) - 1; l >= end; l--) { > /* > * Loop over all the bitmap blocks, try an allocation > * starting in that block. > @@ -1863,7 +1857,6 @@ xfs_growfs_rt( > xfs_drfsbno_t nrblocks; /* new number of realtime blocks */ > xfs_extlen_t nrbmblocks; /* new number of rt bitmap blocks */ > xfs_drtbno_t nrextents; /* new number of realtime extents */ > - uint8_t nrextslog; /* new log2 of sb_rextents */ > xfs_extlen_t nrsumblocks; /* new number of summary blocks */ > uint nrsumlevels; /* new rt summary levels */ > uint nrsumsize; /* new size of rt summary, bytes */ > @@ -1900,8 +1893,7 @@ xfs_growfs_rt( > nrextents = nrblocks; > do_div(nrextents, in->extsize); > nrbmblocks = howmany_64(nrextents, NBBY * sbp->sb_blocksize); > - nrextslog = xfs_highbit32(nrextents); > - nrsumlevels = nrextslog + 1; > + nrsumlevels = fls(nrextents); > nrsumsize = (uint)sizeof(xfs_suminfo_t) * nrsumlevels * nrbmblocks; > nrsumblocks = XFS_B_TO_FSB(mp, nrsumsize); > nrsumsize = XFS_FSB_TO_B(mp, nrsumblocks); > @@ -1954,7 +1946,8 @@ xfs_growfs_rt( > nsbp->sb_blocksize * nsbp->sb_rextsize); > nsbp->sb_rextents = nsbp->sb_rblocks; > do_div(nsbp->sb_rextents, nsbp->sb_rextsize); > - nsbp->sb_rextslog = xfs_highbit32(nsbp->sb_rextents); > + ASSERT(nsbp->sb_rextents != 0); > + nsbp->sb_rextslog = fls(nsbp->sb_rextents) - 1; > nrsumlevels = nmp->m_rsumlevels = nsbp->sb_rextslog + 1; > nrsumsize = > (uint)sizeof(xfs_suminfo_t) * nrsumlevels * > @@ -2317,9 +2310,10 @@ xfs_rtpick_extent( > *seqp = 0; > } > seq = *seqp; > - if ((log2 = xfs_highbit64(seq)) == -1) > + if ((log2 = fls64(seq)) == 0) > b = 0; > else { > + log2--; > resid = seq - (1ULL << log2); > b = (mp->m_sb.sb_rextents * ((resid << 1) + 1ULL)) >> > (log2 + 1); > Index: linux-2.6.23-rc8-misc/fs/xfs/xfs_ialloc.h > =================================================================== > --- linux-2.6.23-rc8-misc.orig/fs/xfs/xfs_ialloc.h > +++ linux-2.6.23-rc8-misc/fs/xfs/xfs_ialloc.h > @@ -57,10 +57,10 @@ xfs_make_iptr(struct xfs_mount *mp, stru > #define XFS_IALLOC_FIND_FREE(fp) xfs_ialloc_find_free(fp) > static inline int xfs_ialloc_find_free(xfs_inofree_t *fp) > { > - return xfs_lowbit64(*fp); > + unsigned long v = *fp; /* Guarantee alignment */ > + return find_first_bit(&v, 64); > } > > - > #ifdef __KERNEL__ > /* > * Allocate an inode on disk. > > --------------030900060305090908070809 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------030900060305090908070809-- From owner-xfs@oss.sgi.com Tue Oct 2 09:41:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 09:41:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l92GfmoP006083 for ; Tue, 2 Oct 2007 09:41:50 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l92GfZ6I019009; Tue, 2 Oct 2007 11:41:36 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <470274BF.7070702@thebarn.com> Date: Tue, 02 Oct 2007 11:41:35 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: David Chinner CC: Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> In-Reply-To: <20071002091951.GE995458@sgi.com> Content-Type: multipart/mixed; boundary="------------080904050700000906050104" X-Virus-Scanned: ClamAV 0.91.2/4455/Tue Oct 2 06:49:51 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4456/Tue Oct 2 10:11:59 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13227 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------080904050700000906050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Chinner wrote: > On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote: > >> On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote: >> >>> The attached tool allows an inode64 filesystem to be converted to inode32. >>> For this to work, the filesystem has to be mounted inode32 before it's run. >>> >>> I'm not sure if there is any packaging changes required. >>> >> Together with the stop allocating from specific AGs patch this should be >> 90% towards an xfs_shrinkfs, right? >> > > Well, this just moves the inodes - it's one piece of the puzzle. We > still need to collide xfs_fsr with xfs_reno to move the data. > > After that, we need to work out how to move the orphan metadata > blocks out of the AGs that are to be truncated off. That's not > simple.... > > After that, we need the transaction to shrink the fs. > > At that point, we'll got a "working" shrink that will allow > shrinking to only 50% of the original size because the log will > get in the way. To fix that, we'll need to implement transactions > to move the log... > If we do that could be move to an inode based log? Keep it contagious so recovery won't have to parse up the file system to find the log. The normal running case should be easier to deal with if the log was just a file? > Cheers, > > Dave. > --------------080904050700000906050104 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------080904050700000906050104-- From owner-xfs@oss.sgi.com Tue Oct 2 14:32:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 14:32:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l92LW4xX012421 for ; Tue, 2 Oct 2007 14:32: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 HAA14228; Wed, 3 Oct 2007 07:31:59 +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 l92LVudD48430379; Wed, 3 Oct 2007 07:31:57 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l92LVrH648460231; Wed, 3 Oct 2007 07:31:53 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 3 Oct 2007 07:31:53 +1000 From: David Chinner To: Christoph Hellwig Cc: David Chinner , Andi Kleen , Timothy Shimmin , Martin Steigerwald , xfs@oss.sgi.com Subject: Re: Creation time in XFS Message-ID: <20071002213153.GI995458@sgi.com> References: <200709302124.38164.Martin@lichtvoll.de> <470042DC.2040009@sgi.com> <20071002092509.GF995458@sgi.com> <20071002093822.GA24907@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071002093822.GA24907@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13228 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 On Tue, Oct 02, 2007 at 10:38:22AM +0100, Christoph Hellwig wrote: > On Tue, Oct 02, 2007 at 07:25:10PM +1000, David Chinner wrote: > > > I don't think it is at all currently: > > > > So what is the point? Forensic analysis? > > Windows wants it, so I guess they added when they had to bump the inode > version anyway in preparation of a user interface for samba. Can you point me to whatever list this was discussed on? This is exactly the sort of stuff that needs to be discussed on -fsdevel. > We probably > should do the same for XFS when bumping the inode version for the crcs. Perhaps. I don't really like the idea of adding unused fields to the on disk structure just in case it is needed in the future.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 16:23:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 16:23:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l92NNH9d031791 for ; Tue, 2 Oct 2007 16:23: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 JAA16616; Wed, 3 Oct 2007 09:23:10 +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 l92NN8dD48252375; Wed, 3 Oct 2007 09:23:08 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l92NN5KF48445845; Wed, 3 Oct 2007 09:23:05 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 3 Oct 2007 09:23:05 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: sync_blockdev in xfs_flush_device_work Message-ID: <20071002232304.GG23367404@sgi.com> References: <20070929110921.GA2466@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070929110921.GA2466@lst.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13229 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 On Sat, Sep 29, 2007 at 01:09:21PM +0200, Christoph Hellwig wrote: > How is the sync_blockdev in the ENOSP path going to help it? It only > syncs the block device mapping which XFS doesn't use it at all. Not really sure - it's probably a left over from when XFs was using it, but still that makes no difference to ENOSPC flushing.. I think we can kill it... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 16:41:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 16:41:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l92NffT6001821 for ; Tue, 2 Oct 2007 16:41:45 -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 JAA17129; Wed, 3 Oct 2007 09:41:31 +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 l92NfSdD47350592; Wed, 3 Oct 2007 09:41:30 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l92NfR8H48501563; Wed, 3 Oct 2007 09:41:27 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 3 Oct 2007 09:41:27 +1000 From: David Chinner To: Russell Cattelan Cc: David Chinner , Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno Message-ID: <20071002234126.GH23367404@sgi.com> References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> <470274BF.7070702@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470274BF.7070702@thebarn.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13230 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 On Tue, Oct 02, 2007 at 11:41:35AM -0500, Russell Cattelan wrote: > >At that point, we'll got a "working" shrink that will allow > >shrinking to only 50% of the original size because the log will > >get in the way. To fix that, we'll need to implement transactions > >to move the log... > > If we do that could be move to an inode based log? What do we gain from doing that? (I'm a bit slow today) > Keep it contagious so recovery won't have to parse > up the file system to find the log. I'm worried by those contagious logs. What do you catch from them? :) > The normal running case should be easier to deal with if > the log was just a file? I don't see how it changes anything - we address the log directly by block number and device... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 18:01:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 18:01:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9311Kh2011198 for ; Tue, 2 Oct 2007 18:01:22 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 LAA18770; Wed, 3 Oct 2007 11:01:05 +1000 Date: Wed, 03 Oct 2007 11:05:05 +1000 To: "David Chinner" , "Christoph Hellwig" Subject: Re: REVIEW: xfs_reno From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , xfs-dev Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20071002091951.GE995458@sgi.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13231 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 02 Oct 2007 19:19:51 +1000, David Chinner wrote: > On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote: >> On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote: >> > >> > The attached tool allows an inode64 filesystem to be converted to >> inode32. >> > For this to work, the filesystem has to be mounted inode32 before >> it's run. >> > >> > I'm not sure if there is any packaging changes required. >> >> Together with the stop allocating from specific AGs patch this should be >> 90% towards an xfs_shrinkfs, right? > > Well, this just moves the inodes - it's one piece of the puzzle. We > still need to collide xfs_fsr with xfs_reno to move the data. > > After that, we need to work out how to move the orphan metadata > blocks out of the AGs that are to be truncated off. That's not > simple.... I believe xfs_bmap on all inodes can reveal extended attributes and directory data in extra AGs. Copying those like xfs_reno does with "blocked" AGs should perform the desired metadata moving. > After that, we need the transaction to shrink the fs. > > At that point, we'll got a "working" shrink that will allow > shrinking to only 50% of the original size because the log will > get in the way. To fix that, we'll need to implement transactions > to move the log... > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Tue Oct 2 18:31:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 18:31:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l931V4i0014599 for ; Tue, 2 Oct 2007 18:31:11 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19499; Wed, 3 Oct 2007 11:30:53 +1000 Message-ID: <4702F0CD.1070300@sgi.com> Date: Wed, 03 Oct 2007 11:30:53 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> In-Reply-To: <20071002091951.GE995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13232 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 David Chinner wrote: > At that point, we'll got a "working" shrink that will allow > shrinking to only 50% of the original size because the log will > get in the way. To fix that, we'll need to implement transactions > to move the log... > Moving the log sounds pretty tricky. Either we'd need to clean out the log (a la freeze) or copy the active part (tail->head) to the new location and zero out the rest of the new log space (or may even need to write sectors with previous cycle#s at the start of each sector for the rest). So how would one do that with the copying approach because we'd need to be writing in to the new log and we'd need the log pointer in the superblock to be logged somewhere ughhhh. I think a type of freezing may be the way to go. The trouble is we need to point the sb to the new log and the only place to log that is in the old log. So I guess before unfreezing you write the sb logptr change using the old log and then after the unfreeze, everything uses the new log. If you die before the sb change to disk then on mount you replay the sb change using the old log and then start writing to the new log. If you die before writing the sb change in the old log then you are stuck. You need this log change and freespace change (for making room for the log) in a transaction together and probably with other stuff. Okay, I'm getting lost :) --Tim From owner-xfs@oss.sgi.com Tue Oct 2 18:49:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 18:49:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l931nLTg016868 for ; Tue, 2 Oct 2007 18:49:24 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20001; Wed, 3 Oct 2007 11:49:11 +1000 Message-ID: <4702F517.3040502@sgi.com> Date: Wed, 03 Oct 2007 11:49:11 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Justin Piszcz CC: Lachlan McIlroy , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4456/Tue Oct 2 08:11:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13233 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 Hi Justin, Justin Piszcz wrote: > > > On Tue, 2 Oct 2007, Lachlan McIlroy wrote: > >> Yeah that about sums it up. In an attempt to prevent log replay of >> inodes >> in cases when we shouldn't replay we also prevented log replay of >> inodes in >> cases when we should replay. We end up with directories that refer to >> inodes >> that were not replayed and we read existing data off disk. That existing >> data is usually previous instances of inodes. We had cases of regular >> files >> turning into directories and inode version mismatches. >> >> Lachlan >> > In 2.6.23-rc8? > The bad change went into rc7 and was still there in rc8. It was backed out for rc9. --Tim From owner-xfs@oss.sgi.com Tue Oct 2 21:58:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 21:58:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l934wFht008537 for ; Tue, 2 Oct 2007 21:58:18 -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 OAA23805; Wed, 3 Oct 2007 14:58:07 +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 l934w6dD48633630; Wed, 3 Oct 2007 14:58:06 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l934w4tA48737508; Wed, 3 Oct 2007 14:58:04 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 3 Oct 2007 14:58:04 +1000 From: David Chinner To: Barry Naujok Cc: David Chinner , Christoph Hellwig , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno Message-ID: <20071003045804.GO23367404@sgi.com> References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4457/Tue Oct 2 21:10:00 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13234 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 On Wed, Oct 03, 2007 at 11:05:05AM +1000, Barry Naujok wrote: > On Tue, 02 Oct 2007 19:19:51 +1000, David Chinner wrote: > > >On Tue, Oct 02, 2007 at 10:02:16AM +0100, Christoph Hellwig wrote: > >>On Tue, Oct 02, 2007 at 05:08:59PM +1000, Barry Naujok wrote: > >>> > >>> The attached tool allows an inode64 filesystem to be converted to > >>inode32. > >>> For this to work, the filesystem has to be mounted inode32 before > >>it's run. > >>> > >>> I'm not sure if there is any packaging changes required. > >> > >>Together with the stop allocating from specific AGs patch this should be > >>90% towards an xfs_shrinkfs, right? > > > >Well, this just moves the inodes - it's one piece of the puzzle. We > >still need to collide xfs_fsr with xfs_reno to move the data. > > > >After that, we need to work out how to move the orphan metadata > >blocks out of the AGs that are to be truncated off. That's not > >simple.... > > I believe xfs_bmap on all inodes can reveal extended attributes and > directory data in extra AGs. Copying those like xfs_reno does with > "blocked" AGs should perform the desired metadata moving. Sure. But I'm thinking of metadata like the blocks in an extent btree that indexes the data or attribute fork of an inode. I don't think xfs_bmap can tell us where those blocks are, and they could be anywhere on the filesystem... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 2 22:50:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 02 Oct 2007 22:50:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l935oLrR014888 for ; Tue, 2 Oct 2007 22:50:23 -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 PAA24867; Wed, 3 Oct 2007 15:50:13 +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 l935oCdD48668758; Wed, 3 Oct 2007 15:50:12 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l935oB5R48481857; Wed, 3 Oct 2007 15:50:11 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 3 Oct 2007 15:50:11 +1000 From: David Chinner To: Timothy Shimmin Cc: David Chinner , Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: xfs_reno Message-ID: <20071003055011.GP23367404@sgi.com> References: <20071002090216.GA22721@infradead.org> <20071002091951.GE995458@sgi.com> <4702F0CD.1070300@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4702F0CD.1070300@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4457/Tue Oct 2 21:10:00 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13235 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 On Wed, Oct 03, 2007 at 11:30:53AM +1000, Timothy Shimmin wrote: > David Chinner wrote: > >At that point, we'll got a "working" shrink that will allow > >shrinking to only 50% of the original size because the log will > >get in the way. To fix that, we'll need to implement transactions > >to move the log... > > > Moving the log sounds pretty tricky. > > Either we'd need to clean out the log (a la freeze) or > copy the active part (tail->head) to the new location and zero out the rest > of > the new log space (or may even need to write sectors with > previous cycle#s at the start of each sector for the rest). > So how would one do that with the copying approach because > we'd need to be writing in to the new log and we'd need the log > pointer in the superblock to be logged somewhere ughhhh. > I think a type of freezing may be the way to go. Yes. > The trouble is we need to point the sb to the new log and the > only place to log that is in the old log. Sure. > So I guess before unfreezing you write the sb logptr change > using the old log and then after the unfreeze, everything uses the new log. Yes. > If you die before the sb change to disk then on mount you replay the sb > change > using the old log and then start writing to the new log. Yes. > If you die before > writing the > sb change in the old log then you are stuck. No, the log swap never occurred. These would be sync transactions, so if it never hit the disk no further transactions every occurred. Hence this doesn't really cause any problems. > You need this log change and freespace change (for making room for the log) > in a transaction together and probably with other stuff. a new log involves: freeze allocate new log space do log swap xaction sync old log free old log sync new log unfreeze Recovery is only complex in terms of freeing the new log space if we crash without the logswap transaction being on disk, or freeing the old log if we crash before that transaction hits the disk.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 3 01:11:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 01:11:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l938BnJq006459 for ; Wed, 3 Oct 2007 01:11:52 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 305561C0A76EE; Wed, 3 Oct 2007 04:11:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 2DA27400FCB4; Wed, 3 Oct 2007 04:11:50 -0400 (EDT) Date: Wed, 3 Oct 2007 04:11:50 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Timothy Shimmin cc: Lachlan McIlroy , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit In-Reply-To: <4702F517.3040502@sgi.com> Message-ID: References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> <4702F517.3040502@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4459/Tue Oct 2 22:30:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13236 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 On Wed, 3 Oct 2007, Timothy Shimmin wrote: > Hi Justin, > > Justin Piszcz wrote: >> >> >> On Tue, 2 Oct 2007, Lachlan McIlroy wrote: >> >>> Yeah that about sums it up. In an attempt to prevent log replay of inodes >>> in cases when we shouldn't replay we also prevented log replay of inodes >>> in >>> cases when we should replay. We end up with directories that refer to >>> inodes >>> that were not replayed and we read existing data off disk. That existing >>> data is usually previous instances of inodes. We had cases of regular >>> files >>> turning into directories and inode version mismatches. >>> >>> Lachlan >>> >> In 2.6.23-rc8? >> > The bad change went into rc7 and was still there in rc8. > It was backed out for rc9. > > --Tim > If one with was running 2.6.23-rc8 with XFS, does that mean we should run xfs_repair on our filesystems after upgrading to -rc9? Justin. From owner-xfs@oss.sgi.com Wed Oct 3 10:58:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 10:58:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.0-r574664 Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l93HwHm9023388 for ; Wed, 3 Oct 2007 10:58:19 -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 7F18E150A8; Wed, 3 Oct 2007 19:58:17 +0200 (CEST) From: Andi Kleen Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) To: Russell Cattelan Subject: Re: [PATCH] Replace XFS bit functions with Linux functions Date: Wed, 3 Oct 2007 19:58:13 +0200 User-Agent: KMail/1.9.6 Cc: xfs@oss.sgi.com References: <200710021010.58284.ak@suse.de> <470273C1.60300@thebarn.com> In-Reply-To: <470273C1.60300@thebarn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710031958.13422.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13237 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 > I would like to keep thing abstracted enough such that it is won't be to > difficult keep to map to the FreeBSD bit functions. It's no different to map linux bit functions to FreeBSD than mapping XFS bit functions to FreeBSD. Besides I expect it has fls already -- that is actually a BSDism. -Andi From owner-xfs@oss.sgi.com Wed Oct 3 11:20:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 11:20:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l93IKHtg027754 for ; Wed, 3 Oct 2007 11:20:19 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l93IKFDH062694; Wed, 3 Oct 2007 13:20:16 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4703DD5F.8080906@thebarn.com> Date: Wed, 03 Oct 2007 13:20:15 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.5 (X11/20070813) MIME-Version: 1.0 To: Andi Kleen CC: xfs@oss.sgi.com Subject: Re: [PATCH] Replace XFS bit functions with Linux functions References: <200710021010.58284.ak@suse.de> <470273C1.60300@thebarn.com> <200710031958.13422.ak@suse.de> In-Reply-To: <200710031958.13422.ak@suse.de> Content-Type: multipart/mixed; boundary="------------070300080201010504070703" X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4461/Wed Oct 3 03:50:48 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13238 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------070300080201010504070703 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Andi Kleen wrote: >> I would like to keep thing abstracted enough such that it is won't be to >> difficult keep to map to the FreeBSD bit functions. >> > > It's no different to map linux bit functions to FreeBSD than mapping > XFS bit functions to FreeBSD. Besides I expect it has fls already -- > that is actually a BSDism. > > Yes but for the most part the common code does not play favorites to linux or bsd or X in terms of which platform is favored. (with some execptions). I have been working getting the freebsd xfs code based updated and I've come across calls to spin_lock that may need to redone. I need to look at the XFS code paths more to figure out which freebsd lock is needed. For the most part freebsd tries not to use mutex spin_lock (disable interrupts and spin) since it is more expensive that just mtx_lock (do not disable interrupts and spin for awhile then sleep) and unless there is a good reason to disable interrupts they try avoiding doing so. Playing favorites is kinda what has fueled this whole "ported half of irix to linux" FUD that has dogged xfs forever. So for the same reason that people complained about mapping irix calls to linux calls I don't like the argument that linux calls should just be mapped to bsd calls. And I agree with Dave the -1 adjustments are bit hard to follow and would be better encapsulated in a inline call where it can be documented. Having the xfs_ call in the common code would also allow the fbsd port to catch up with this optimization as some point vs having to back stitch the current code into common layer and eventually having to realign. > -Andi > > --------------070300080201010504070703 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------070300080201010504070703-- From owner-xfs@oss.sgi.com Wed Oct 3 15:05:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 15:06:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,J_CHICKENPOX_13, J_CHICKENPOX_16,J_CHICKENPOX_22,J_CHICKENPOX_43,J_CHICKENPOX_44, J_CHICKENPOX_61,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l93M5k8h027103 for ; Wed, 3 Oct 2007 15:05:47 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IdC6U-0008SI-Bm for linux-xfs@oss.sgi.com; Wed, 03 Oct 2007 21:50:02 +0000 Received: from host-84-220-161-31.cust-adsl.tiscali.it ([84.220.161.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 21:50:02 +0000 Received: from alessandro.bono by host-84-220-161-31.cust-adsl.tiscali.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 21:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Alessandro Bono Subject: 2.6.23-rc9-git1 hang with XFS Date: Wed, 03 Oct 2007 23:03:29 +0200 Lines: 5652 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1831028.3B4dx51t4S" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: host-84-220-161-31.cust-adsl.tiscali.it User-Agent: KNode/0.10.5 X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13239 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alessandro.bono@gmail.com Precedence: bulk X-list: xfs --nextPart1831028.3B4dx51t4S Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8Bit Hi all I'm testing 2.6.23-rc9-git1 on my old home server Trying to reorganizer my xfs filesystem with xfs_fsr cause a sort of system hang In particular all I/O write on this filesystem hang process in D state but not seems to have problem on read I/O (I can login via ssh to machine but not logout for example) I can realibly create this situation running a different job that stress filesystem during xfs_fsr (in this case make distclean on a kernel build directory) Strange enough on every hang there was this message on kernel log possible SYN flooding on port 4664. Sending cookies. port 4664 is in use by mldonkey disk layout xfs on lvm2 on [sw raid5 + sw raid1] on 4 sata disk 2 sata disk on ata_piix 2 sata disk on sata_promise distribution is ubuntu dapper with this tools Gnu C 4.0.3 Gnu make 3.81beta4 binutils 2.16.91 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 jfsutils 1.1.8 reiserfsprogs 3.6.19 xfsprogs 2.7.7 PPP 2.4.4b1 Linux C Library 3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.6 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.93 udev 079 attached some info + trace of running process during hang --nextPart1831028.3B4dx51t4S Content-Type: text/plain; name="config" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9-git1 # Wed Oct 3 19:50:38 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_USER_NS=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y # CONFIG_SCHED_MC is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set # CONFIG_SECCOMP is not set CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set CONFIG_SUSPEND_SMP_POSSIBLE=y # CONFIG_SUSPEND is not set CONFIG_HIBERNATION_SMP_POSSIBLE=y # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=2000 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K7_ACPI=y # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set CONFIG_X86_P4_CLOCKMOD=m # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=m # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK_ENABLED=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m # CONFIG_NF_CT_PROTO_SCTP is not set CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m # CONFIG_NETFILTER_XT_MATCH_SCTP is not set CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m # CONFIG_IP_DCCP is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m # CONFIG_DECNET is not set CONFIG_LLC=m CONFIG_LLC2=m # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_FIFO=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=y CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_CLS_POLICE=y CONFIG_NET_CLS_IND=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=m # CONFIG_MTD is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=65536 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set # CONFIG_IDE is not set # # SCSI device support # CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m # CONFIG_SCSI_SAS_LIBSAS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set CONFIG_SCSI_IPR=m # CONFIG_SCSI_IPR_TRACE is not set # CONFIG_SCSI_IPR_DUMP is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_AHCI is not set # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=m # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set CONFIG_SATA_PROMISE=m # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIL24 is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_ISAPNP is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_LEGACY is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_QDI is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_WINBOND_VLB is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_MULTIPATH_EMC is not set # CONFIG_DM_MULTIPATH_RDAC is not set CONFIG_DM_DELAY=m # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # # Controllers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocols # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_NETDEVICES_MULTIQUEUE=y CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=m # # MII PHY device drivers # # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_FIXED_PHY is not set CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y # CONFIG_SC92031 is not set # CONFIG_NET_POCKET is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m CONFIG_E1000_NAPI=y # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET_MII=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_WAN=y # CONFIG_HOSTESS_SV11 is not set # CONFIG_COSA is not set # CONFIG_LANMEDIA is not set # CONFIG_SEALEVEL_4021 is not set CONFIG_HDLC=m CONFIG_HDLC_RAW=m CONFIG_HDLC_RAW_ETH=m CONFIG_HDLC_CISCO=m # CONFIG_HDLC_FR is not set CONFIG_HDLC_PPP=m # # X.25/LAPB support is disabled # # CONFIG_PCI200SYN is not set # CONFIG_WANXL is not set # CONFIG_PC300 is not set # CONFIG_PC300TOO is not set # CONFIG_N2 is not set # CONFIG_C101 is not set # CONFIG_FARSYNC is not set # CONFIG_DSCC4 is not set # CONFIG_DLCI is not set # CONFIG_WAN_ROUTER_DRIVERS is not set # CONFIG_SBNI is not set CONFIG_ATM_DRIVERS=y CONFIG_ATM_DUMMY=m CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set # CONFIG_ATM_ENI is not set # CONFIG_ATM_FIRESTREAM is not set # CONFIG_ATM_ZATM is not set # CONFIG_ATM_NICSTAR is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E_MAYBE is not set # CONFIG_ATM_HE is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_PPPOL2TP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set CONFIG_SHAPER=m CONFIG_NETCONSOLE=m CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_TSDEV=m CONFIG_INPUT_TSDEV_SCREEN_X=240 CONFIG_INPUT_TSDEV_SCREEN_Y=320 CONFIG_INPUT_EVDEV=m CONFIG_INPUT_EVBUG=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_XTKBD=m # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_ESPSERIAL is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_MOXA_SMARTIO_NEW is not set # CONFIG_ISI is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set # CONFIG_SYNCLINK_GT is not set CONFIG_N_HDLC=m # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALDRV is not set # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=m CONFIG_SERIAL_8250_PNP=m CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set CONFIG_HVC_DRIVER=y # CONFIG_IPMI_HANDLER is not set # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set CONFIG_DRM_MGA=m # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HPET=y CONFIG_HPET_RTC_IRQ=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_OCORES=m CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m # CONFIG_I2C_SIMTEC is not set CONFIG_SCx200_ACB=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_TAOS_EVM=m CONFIG_I2C_STUB=m CONFIG_I2C_TINY_USB=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m CONFIG_I2C_PCA_ISA=m # # Miscellaneous I2C Chip support # CONFIG_SENSORS_DS1337=m CONFIG_SENSORS_DS1374=m CONFIG_DS1682=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8574=m CONFIG_SENSORS_PCA9539=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_MAX6875=m CONFIG_SENSORS_TSL2550=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set CONFIG_W1=m CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2490=m CONFIG_W1_MASTER_DS2482=m # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y CONFIG_W1_SLAVE_DS2760=m CONFIG_POWER_SUPPLY=m # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_FSCPOS=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_HDAPS=m CONFIG_SENSORS_APPLESMC=m # CONFIG_HWMON_DEBUG_CHIP is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_DAB is not set # # Graphics support # CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_BACKLIGHT_CLASS_DEVICE=m # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_SYS_FOPS is not set CONFIG_FB_DEFERRED_IO=y # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set CONFIG_FB_MATROX=m # CONFIG_FB_MATROX_MILLENIUM is not set # CONFIG_FB_MATROX_MYSTIQUE is not set CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_VIDEO_SELECT=y CONFIG_MDA_CONSOLE=m CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m # # ISA devices # # CONFIG_SND_ADLIB is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_MIRO is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # CONFIG_SND_WAVEFRONT is not set # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDA_INTEL is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_AC97_POWER_SAVE=y # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # SoC Audio support for SuperH # # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT_POWERBOOK=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_SUSPEND=y # CONFIG_USB_PERSIST is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set CONFIG_USB_MON=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_AIRPRIME=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set CONFIG_USB_LCD=m # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set CONFIG_USB_TEST=m # # USB DSL modem support # CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # # USB Gadget Support # # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m # # LED drivers # # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m # CONFIG_RTC_DRV_M41T80_WDT is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_STK17TA8=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_M48T86=m CONFIG_RTC_DRV_M48T59=m CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # # # DMA Engine support # # CONFIG_DMA_ENGINE is not set # # DMA Clients # # # DMA Devices # # CONFIG_AUXDISPLAY is not set # CONFIG_VIRTUALIZATION is not set # # Userspace I/O # # CONFIG_UIO is not set CONFIG_LGUEST=m CONFIG_LGUEST_GUEST=y CONFIG_LGUEST_NET=y CONFIG_LGUEST_BLOCK=y # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_NOLOCK=m CONFIG_GFS2_FS_LOCKING_DLM=m CONFIG_OCFS2_FS=m CONFIG_OCFS2_DEBUG_MASKLOG=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_BIND34=y CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_EXPERIMENTAL=y CONFIG_CIFS_UPCALL=y # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # # Native Language Support # CONFIG_NLS=m CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Distributed Lock Manager # CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set CONFIG_INSTRUMENTATION=y CONFIG_PROFILING=y CONFIG_OPROFILE=m # CONFIG_KPROBES is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set CONFIG_TIMER_STATS=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_FRAME_POINTER is not set # CONFIG_FORCED_INLINING is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=m CONFIG_CRYPTO_ABLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_MANAGER=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_TEST=m # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y --nextPart1831028.3B4dx51t4S Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="dmesg" Linux version 2.6.23-rc9-git1 (root@grignolino) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #8 SMP Wed Oct 3 19:52:51 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003ff30000 (usable) BIOS-e820: 000000003ff30000 - 000000003ff40000 (ACPI data) BIOS-e820: 000000003ff40000 - 000000003fff0000 (ACPI NVS) BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved) BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 Entering add_active_range(0, 0, 261936) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem 229376 -> 261936 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 261936 On node 0 totalpages: 261936 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 254 pages used for memmap HighMem zone: 32306 pages, LIFO batch:7 Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F9E30, 0021 (r2 ACPIAM) ACPI: XSDT 3FF30100, 003C (r1 A M I OEMXSDT 10000426 MSFT 97) ACPI: FACP 3FF30290, 00F4 (r3 A M I OEMFACP 10000426 MSFT 97) ACPI: DSDT 3FF303F0, 3797 (r1 P4CED P4CED106 106 INTL 2002026) ACPI: FACS 3FF40000, 0040 ACPI: APIC 3FF30390, 005C (r1 A M I OEMAPIC 10000426 MSFT 97) ACPI: OEMB 3FF40040, 003F (r1 A M I OEMBIOS 10000426 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:3 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:3 APIC version 20 ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 50000000 (gap: 40000000:bfb80000) Built 1 zonelists in Zone order. Total pages: 259890 Kernel command line: root=/dev/md0 ro ht=on quiet splash mapped APIC to ffffb000 (fee00000) mapped IOAPIC to ffffa000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2798.760 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1031452k/1047744k available (1446k kernel code, 15608k reserved, 581k data, 204k init, 130240k highmem) virtual kernel memory layout: fixmap : 0xfff4c000 - 0xfffff000 ( 716 kB) pkmap : 0xff800000 - 0xffc00000 (4096 kB) vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc0301000 - 0xc0334000 ( 204 kB) .data : 0xc026992d - 0xc02faf9c ( 581 kB) .text : 0xc0100000 - 0xc026992d (1446 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 5600.91 BogoMIPS (lpj=28004566) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000041d 00000000 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b180 0000041d 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Compat vDSO mapped to ffffe000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code ACPI: Core revision 20070126 CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03 SMP alternatives: switching to SMP code Booting processor 1/1 eip 2000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5597.43 BogoMIPS (lpj=27987156) CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000041d 00000000 00000000 00000000 monitor/mwait feature present. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 00000000 00000000 0000b180 0000041d 00000000 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: Intel P4/Xeon Extended MCE MSRs (12) available CPU1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03 Total of 2 processors activated (11198.34 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs Booting paravirtualized kernel on bare hardware NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=3 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S5) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH4 GPIO PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - 01, should be F2 [20070126] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 14 devices ACPI: ACPI bus type pnp unregistered PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report ACPI: RTC can wake from S4 Time: tsc clocksource has been installed. pnp: 00:0a: ioport range 0x680-0x6ff has been reserved pnp: 00:0a: ioport range 0x290-0x297 has been reserved pnp: 00:0b: iomem range 0xfed20000-0xfed8ffff has been reserved pnp: 00:0b: iomem range 0xffb00000-0xffbfffff could not be reserved pnp: 00:0c: iomem range 0xfec00000-0xfec00fff has been reserved pnp: 00:0c: iomem range 0xfee00000-0xfee00fff has been reserved pnp: 00:0d: iomem range 0x0-0x9ffff could not be reserved pnp: 00:0d: iomem range 0xc0000-0xdffff could not be reserved pnp: 00:0d: iomem range 0xe0000-0xfffff could not be reserved pnp: 00:0d: iomem range 0x100000-0x3ffeffff could not be reserved PCI: Bridge: 0000:00:01.0 IO window: disabled. MEM window: fd800000-fe8fffff PREFETCH window: f3f00000-f7efffff PCI: Bridge: 0000:00:03.0 IO window: c000-cfff MEM window: fe900000-fe9fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:1e.0 IO window: d000-dfff MEM window: fea00000-feafffff PREFETCH window: disabled. PCI: Setting latency timer of device 0000:00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1572864 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 3833k freed audit: initializing netlink socket (disabled) audit(1191443929.079:1): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 io scheduler noop registered io scheduler deadline registered (default) Boot video device is 0000:01:00.0 isapnp: Scanning for PnP cards... Switched to high resolution mode on CPU 1 Switched to high resolution mode on CPU 0 isapnp: No Plug & Play device found RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice TCP cubic registered NET: Registered protocol family 1 Using IPI No-Shortcut mode Freeing unused kernel memory: 204k freed input: AT Translated Set 2 keyboard as /class/input/input0 vga16fb: initializing vga16fb: mapped to 0xc00a0000 fb0: VGA16 VGA frame buffer device md: raid1 personality registered for level 1 SCSI subsystem initialized libata version 2.21 loaded. sata_promise 0000:03:04.0: version 2.10 ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 23 (level, low) -> IRQ 16 scsi0 : sata_promise scsi1 : sata_promise scsi2 : sata_promise ata1: SATA max UDMA/133 cmd 0xf8812200 ctl 0xf8812238 bmdma 0x00000000 irq 16 ata2: SATA max UDMA/133 cmd 0xf8812280 ctl 0xf88122b8 bmdma 0x00000000 irq 16 ata3: PATA max UDMA/133 cmd 0xf8812300 ctl 0xf8812338 bmdma 0x00000000 irq 16 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: Maxtor 6L300S0, BACE1G20, max UDMA/133 ata1.00: 586114704 sectors, multi 0: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/133 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7: Maxtor 6L300S0, BACE1G20, max UDMA/133 ata2.00: 586114704 sectors, multi 0: LBA48 NCQ (depth 0/32) ata2.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA Maxtor 6L300S0 BACE PQ: 0 ANSI: 5 scsi 1:0:0:0: Direct-Access ATA Maxtor 6L300S0 BACE PQ: 0 ANSI: 5 ata_piix 0000:00:1f.1: version 2.12 PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1f.1 to 64 scsi3 : ata_piix scsi4 : ata_piix ata4: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14 ata5: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15 ata4.00: ATAPI: PIONEER DVD-RW DVR-111D, 1.02, max UDMA/66 ata4.00: limited to UDMA/33 due to 40-wire cable ata4.00: configured for UDMA/33 scsi 3:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.02 PQ: 0 ANSI: 5 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1f.2 to 64 scsi5 : ata_piix scsi6 : ata_piix ata6: SATA max UDMA/133 cmd 0x0001efe0 ctl 0x0001efae bmdma 0x0001ef90 irq 17 ata7: SATA max UDMA/133 cmd 0x0001efa0 ctl 0x0001efaa bmdma 0x0001ef98 irq 17 ata6.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133 ata6.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32) ata6.00: configured for UDMA/133 ata7.00: ATA-7: Maxtor 6V320F0, VA111900, max UDMA/133 ata7.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32) ata7.00: configured for UDMA/133 scsi 5:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5 scsi 6:0:0:0: Direct-Access ATA Maxtor 6V320F0 VA11 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 586114704 512-byte hardware sectors (300091 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 586114704 512-byte hardware sectors (300091 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk sd 1:0:0:0: [sdb] 586114704 512-byte hardware sectors (300091 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 586114704 512-byte hardware sectors (300091 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sd 1:0:0:0: [sdb] Attached SCSI disk sd 5:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB) sd 5:0:0:0: [sdc] Write Protect is off sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 5:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB) sd 5:0:0:0: [sdc] Write Protect is off sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sd 5:0:0:0: [sdc] Attached SCSI disk sd 6:0:0:0: [sdd] 625142448 512-byte hardware sectors (320073 MB) sd 6:0:0:0: [sdd] Write Protect is off sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 6:0:0:0: [sdd] 625142448 512-byte hardware sectors (320073 MB) sd 6:0:0:0: [sdd] Write Protect is off sd 6:0:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdd: sdd1 sdd2 sd 6:0:0:0: [sdd] Attached SCSI disk sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 3:0:0:0: Attached scsi CD-ROM sr0 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1d.0 to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:1d.0: irq 18, io base 0x0000eec0 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:00:1d.1 to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000ef00 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1d.2 to 64 uhci_hcd 0000:00:1d.2: UHCI Host Controller uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1d.2: irq 17, io base 0x0000ef20 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1d.3 to 64 uhci_hcd 0000:00:1d.3: UHCI Host Controller uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:1d.3: irq 18, io base 0x0000ef40 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 20 (level, low) -> IRQ 20 ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: irq 16, io mem 0xfebff800 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 8 ports detected ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[20] MMIO=[feaff800-feafffff] Max Packet=[2048] IR/IT contexts=[8/8] usb 2-2: new low speed USB device using uhci_hcd and address 2 xor: automatically using best checksumming function: pIII_sse pIII_sse : 4302.400 MB/sec xor: using function: pIII_sse (4302.400 MB/sec) async_tx: api initialized (sync-only) raid6: int32x1 737 MB/s raid6: int32x2 716 MB/s usb 2-2: new low speed USB device using uhci_hcd and address 3 raid6: int32x4 582 MB/s raid6: int32x8 502 MB/s usb 2-2: configuration #1 chosen from 1 choice raid6: mmxx1 1300 MB/s raid6: mmxx2 1436 MB/s raid6: sse1x1 743 MB/s raid6: sse1x2 941 MB/s raid6: sse2x1 1453 MB/s raid6: sse2x2 1712 MB/s raid6: using algorithm sse2x2 (1712 MB/s) md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 usbcore: registered new interface driver hiddev md: md0 stopped. md: bind md: bind raid1: raid set md0 active with 2 out of 2 mirrors md: md1 stopped. md: bind md: bind md: bind md: bind md: md1: raid array is not clean -- starting background reconstruction raid5: device sdb2 operational as raid disk 0 raid5: device sdd2 operational as raid disk 3 raid5: device sdc2 operational as raid disk 2 raid5: device sda2 operational as raid disk 1 raid5: allocated 4211kB for md1 raid5: raid level 5 set md1 active with 4 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:4 disk 0, o:1, dev:sdb2 disk 1, o:1, dev:sda2 disk 2, o:1, dev:sdc2 disk 3, o:1, dev:sdd2 md: resync of RAID array md1 md: minimum _guaranteed_ speed: 1000 KB/sec/disk. md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. md: using 128k window, over a total of 245111552 blocks. md: md2 stopped. md: bind md: bind raid1: raid set md2 active with 2 out of 2 mirrors ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e0180000613551] EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. hiddev0: USB HID v1.10 Device [American Power Conversion Back-UPS RS 1000 FW:7.g9 .I USB FW:g9 ] on usb-0000:00:1d.1-2 usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver kjournald starting. Commit interval 5 seconds EXT3-fs: md0: orphan cleanup on readonly fs ext3_orphan_cleanup: deleting unreferenced inode 3244040 ext3_orphan_cleanup: deleting unreferenced inode 3244039 ext3_orphan_cleanup: deleting unreferenced inode 3244038 ext3_orphan_cleanup: deleting unreferenced inode 3244037 ext3_orphan_cleanup: deleting unreferenced inode 3244036 EXT3-fs: md0: 5 orphan inodes deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: Attached scsi generic sg1 type 0 sr 3:0:0:0: Attached scsi generic sg2 type 5 sd 5:0:0:0: Attached scsi generic sg3 type 0 sd 6:0:0:0: Attached scsi generic sg4 type 0 ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 21 w83627hf: Found W83627THF chip at 0x290 w83627hf w83627hf.656: Reading VID from GPIO5 Linux agpgart interface v0.102 agpgart: Detected an Intel i875 Chipset. agpgart: AGP aperture is 64M @ 0xf8000000 input: Power Button (FF) as /class/input/input1 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input2 ACPI: Power Button (CM) [PWRB] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 18 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:02:01.0 to 64 Driver for 1-wire Dallas network protocol. e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:a6:6e:a0:6d EXT3 FS on md0, internal journal Real Time Clock Driver v1.12ac input: PC Speaker as /class/input/input3 via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection matrox_w1 0000:01:00.0: Matrox G400 GPIO transport layer for 1-wire. ACPI: PCI Interrupt 0000:03:0b.0[A] -> GSI 23 (level, low) -> IRQ 16 eth1: VIA Rhine III at 0xfeaff400, 00:40:f4:79:7e:fe, IRQ 16. eth1: MII PHY found at address 1, status 0x786d advertising 05e1 Link 41e1. Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A parport_pc 00:09: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 21 PCI: Setting latency timer of device 0000:00:1f.5 to 64 intel8x0_measure_ac97_clock: measured 69296 usecs intel8x0: clocking to 49800 e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled SGI XFS Quota Management subsystem Filesystem "dm-0": Disabling barriers, not supported by the underlying device XFS mounting filesystem dm-0 Starting XFS recovery on filesystem: dm-0 (logdev: internal) ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (16384 buckets, 65536 max) eth1: link up, 100Mbps, full-duplex, lpa 0x41E1 u32 classifier Performance counters on input device check on Actions configured Ending XFS recovery on filesystem: dm-0 (logdev: internal) Adding 4194296k swap on /dev/mapper/Volume00-swap. Priority:-1 extents:1 across:4194296k IA-32 Microcode Update Driver: v1.14a lp0: using parport0 (interrupt-driven). ppdev: user-space parallel port driver NET: Registered protocol family 17 device eth0 entered promiscuous mode audit(1191443987.522:2): dev=eth0 prom=256 old_prom=0 auid=4294967295 --nextPart1831028.3B4dx51t4S Content-Type: text/plain; name="trace" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="trace" possible SYN flooding on port 4664. Sending cookies. possible SYN flooding on port 4664. Sending cookies. possible SYN flooding on port 4664. Sending cookies. possible SYN flooding on port 4664. Sending cookies. possible SYN flooding on port 4664. Sending cookies. d+0x34/0x55 [] kthread+0x0/0x55 [] kernel_thread_helper+0x7/0x10 ======================= xfssyncd D c1807dc0 0 9058 2 f6d4ff08 00000046 0001731b c1807dc0 00000002 f6d4fef0 dffd0ab0 dffd0bf0 c180ae00 00000000 0001c026 000000ff 00000000 00000000 0001731b ca3882b8 00000246 ca3882c0 dffd0ab0 c02688a4 00000001 dffd0ab0 c011a320 ca3882c4 Call Trace: [] __down+0xc2/0xd4 [] default_wake_function+0x0/0xc [] __down_failed+0x7/0xc [] xfs_iflock+0x16/0x17 [xfs] [] xfs_finish_reclaim+0xf5/0x11d [xfs] [] xfs_finish_reclaim_all+0x73/0xa7 [xfs] [] xfs_syncsub+0x5c/0x270 [xfs] [] xfs_sync+0x0/0x1f [xfs] [] vfs_sync+0x17/0x1a [xfs] [] vfs_sync_worker+0x18/0x37 [xfs] [] xfssyncd+0xbd/0xfd [xfs] [] xfssyncd+0x0/0xfd [xfs] [] kthread+0x34/0x55 [] kthread+0x0/0x55 [] kernel_thread_helper+0x7/0x10 ======================= acpid S f7fac7cc 0 10260 1 c1b01be4 00000082 f6c82400 f7fac7cc c01a3de7 dfc21270 f7849030 f7849170 c180ae00 00000000 00000000 f766a6a0 c017e3af 00438028 00000000 7fffffff 00000000 ffffffff 00000000 c0267af3 f766a6a0 f766a5c0 f766a5f8 f6c3ca20 Call Trace: [] __make_request+0x496/0x4d8 [] __find_get_block+0x1c4/0x1ce [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] unix_poll+0x15/0x8c [] do_sys_poll+0x25d/0x323 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] ext3_mark_iloc_dirty+0x27e/0x2d9 [ext3] [] ext3_mark_inode_dirty+0x20/0x27 [ext3] [] __wake_up+0x32/0x43 [] journal_stop+0x1af/0x1bb [jbd] [] __ext3_journal_stop+0x19/0x34 [ext3] [] ext3_ordered_commit_write+0xb4/0xc3 [ext3] [] ext3_journal_dirty_data+0x0/0x31 [ext3] [] generic_file_buffered_write+0x4cd/0x59c [] get_page_from_freelist+0x257/0x2d6 [] find_lock_page+0x1a/0x90 [] filemap_fault+0x227/0x387 [] __do_fault+0x30e/0x33b [] generic_file_aio_write+0x5b/0xb0 [] handle_mm_fault+0x36e/0x6f9 [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] vfs_write+0xfb/0x10b [] sys_poll+0x33/0x36 [] sysenter_past_esp+0x6b/0xa1 ======================= syslogd S c1807dc0 0 10277 1 f7377b40 00200086 0001731b c1807dc0 00000002 f7377b28 c192b030 c192b170 c180ae00 00000000 00023025 000000ff 00000000 00000000 0001731b 7fffffff f7377f9c 00000001 00000002 c0267af3 c02f90c0 c180ae50 f7377b80 c0118ed1 Call Trace: [] schedule_timeout+0x13/0x8d [] update_curr+0x103/0x12a [] add_wait_queue+0xf/0x30 [] datagram_poll+0x14/0xad [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] schedule+0x453/0x511 [] lock_timer_base+0x19/0x35 [] __mod_timer+0x97/0xa1 [] blk_plug_device+0x6b/0xb2 [] make_request+0x51b/0x537 [raid1] [] generic_make_request+0x3d0/0x401 [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] core_sys_select+0x1dd/0x283 [] do_sync_readv_writev+0xc1/0xfe [] wait_on_page_writeback_range+0xaf/0xf7 [] autoremove_wake_function+0x0/0x33 [] mapping_tagged+0x2b/0x32 [] rw_copy_check_uvector+0x57/0xc3 [] do_readv_writev+0xa3/0x16c [] pipe_write+0x0/0x3da [] sys_select+0x9d/0x167 [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sys_rt_sigprocmask+0x4b/0xc4 [] sysenter_past_esp+0x6b/0xa1 ======================= dd R running 0 10322 1 klogd S c0265a08 0 10327 1 f73abe5c 00200086 00000050 c0265a08 f73abe5c 00000000 c1924570 c19246b0 c180ae00 00000000 00000000 cc3ca880 00002857 00200246 c012deee f7561000 f7561000 f73abe78 f7d889c0 c0166f4a 00000000 c1924570 c012dd98 f7561004 Call Trace: [] unix_dgram_sendmsg+0x382/0x402 [] prepare_to_wait+0x12/0x4b [] pipe_wait+0x51/0x6f [] autoremove_wake_function+0x0/0x33 [] pipe_read+0x2cf/0x343 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] do_sync_read+0x0/0x10a [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= apcupsd R running 0 10355 1 apcupsd S f6d0fe14 0 10559 1 f6d0fe28 00200082 00000002 f6d0fe14 f6d0fe0c 00000000 c19c8570 c19c86b0 c1813e00 00000001 ffff950c 000000ff 00000000 00000000 00000000 7fffffff 7fffffff f6d0fe98 f6d0febc c0267af3 00000000 00200282 dfef76c4 d662d853 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] cp_new_stat64+0xf3/0x105 [] sys_send+0x37/0x3b [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= cupsd S c1807dc0 0 10424 1 f73a9b40 00200086 0001731b c1807dc0 00000002 f73a9b28 c1a25030 c1a25170 c180ae00 00000000 00023036 000000ff 00000000 00000000 0001731b f73a9b50 00023b25 00000005 00000020 c0267b50 00200246 c012dfc8 c0364164 f6c5abd8 Call Trace: [] schedule_timeout+0x70/0x8d [] add_wait_queue+0xf/0x30 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] dev_queue_xmit+0x289/0x2ae [] ip_mc_output+0x38d/0x3c6 [] ip_finish_output+0x0/0x218 [] ip_push_pending_frames+0x348/0x3da [] dst_output+0x0/0x7 [] udp_push_pending_frames+0x2ac/0x2fe [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] memcpy_toiovec+0x25/0x47 [] skb_copy_datagram_iovec+0x53/0x1cd [] skb_dequeue+0x39/0x3f [] skb_recv_datagram+0x6b/0x172 [] __kfree_skb+0xa3/0xfa [] udp_recvmsg+0x184/0x1d1 [] sock_common_recvmsg+0x3e/0x54 [] sock_recvmsg+0xcf/0xe8 [] sock_sendmsg+0xbc/0xd4 [] autoremove_wake_function+0x0/0x33 [] core_sys_select+0x1dd/0x283 [] move_addr_to_user+0x4e/0x66 [] sys_recvfrom+0x108/0x12b [] sys_getsockname+0x78/0xa2 [] skb_dequeue+0x39/0x3f [] skb_queue_purge+0x11/0x17 [] netlink_sock_destruct+0x2c/0xd1 [] sk_free+0xad/0xb9 [] sock_def_write_space+0x10/0x7d [] sock_wfree+0x21/0x36 [] __kfree_skb+0xa3/0xfa [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= slapd S f6e0de10 0 10598 1 f6e0de24 00200082 00000002 f6e0de10 f6e0de08 00000000 c19c5570 c19c56b0 c180ae00 00000000 ffff950d 000000ff 00000000 00000000 00000000 f7fb7074 f6e0de90 c038615c b786abf8 c01371bb f7f97358 00002970 00002970 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] flush_tlb_page+0x3d/0x61 [] __do_fault+0x30e/0x33b [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] do_page_fault+0x0/0x63d [] __switch_to+0xa2/0x126 [] schedule+0x453/0x511 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= slapd S cd957e80 0 10608 1 f6e33b40 00200082 c02e4c00 cd957e80 0000000e c02175df f7fcd030 f7fcd170 c180ae00 00000000 f7e6829c c0235251 00000000 c02e4a00 c02349fd 7fffffff f6e33f9c 00000022 00000004 c0267af3 f7e6829c 00000000 00200246 c012dfc8 Call Trace: [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] tcp_poll+0x18/0x120 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] core_sys_select+0x1dd/0x283 [] pipe_read+0x337/0x343 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= slapd S c01542ea 0 10634 1 f6e69e24 00200082 080f2000 c01542ea 080f2690 080f2000 c19d3030 c19d3170 c180ae00 00000000 f6dc28ec c01362da 00000057 f7fb7074 00200246 f7fb7074 f6e69e90 c0385928 080f2690 c01371bb 00000000 000001d5 000001d5 00000000 Call Trace: [] find_extend_vma+0x12/0x49 [] unqueue_me+0x77/0x80 [] futex_wait+0x1b6/0x2bc [] do_wp_page+0x47f/0x4b9 [] sock_aio_write+0xc8/0xd4 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] pick_next_task_fair+0x20/0x47 [] schedule+0x2d8/0x511 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= clamd S 00000000 0 10635 1 f6e7fe40 00200086 c0146f51 00000000 f78bd2b0 f78bd2b0 c19c5ab0 c19c5bf0 c180ae00 00000000 00000000 f6e7fe8c dfe32668 f78bd358 dfcd0408 7fffffff f7f3ed00 ffffff95 7fffffff c0267af3 c17e1300 00000000 c17e1300 c01508f7 Call Trace: [] find_lock_page+0x1a/0x90 [] schedule_timeout+0x13/0x8d [] __do_fault+0x30e/0x33b [] kunmap_atomic+0x52/0x7a [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] unix_accept+0x4e/0xd4 [] sys_accept+0xd8/0x1ad [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] check_pgt_cache+0x19/0x1b [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= freshclam S f7e0b740 0 10690 1 f6d03fac 00200086 00000000 f7e0b740 f7e0b784 08053008 dffd5ab0 dffd5bf0 c1813e00 00000001 f6d02000 c0121776 00000000 00000000 00000000 00000001 08053470 08053008 f6d02000 c012630e c0102802 00000001 b7e4c18c 00000001 Call Trace: [] alarm_setitimer+0x36/0x5c [] sys_pause+0x11/0x17 [] sysenter_past_esp+0x6b/0xa1 ======================= cyrmaster S c1807dc0 0 10713 1 f6e89b40 00200082 0001731b c1807dc0 00000002 f6e89b28 c1930ab0 c1930bf0 c180ae00 00000000 00023035 000000ff 00000000 00000000 0001731b f6e89b50 00023354 00000019 02000000 c0267b50 0000000c 00001000 c0364124 f2325b50 Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] d_rehash+0x1c/0x29 [] d_kill+0x37/0x46 [] mntput_no_expire+0x11/0x5d [] __link_path_walk+0xa8f/0xaa6 [] unix_dgram_sendmsg+0x382/0x402 [] ata_qc_issue_prot+0xe6/0x21c [libata] [] mntput_no_expire+0x11/0x5d [] link_path_walk+0xa9/0xb3 [] __alloc_skb+0x42/0xec [] do_path_lookup+0x161/0x1c4 [] core_sys_select+0x1dd/0x283 [] sk_free+0xa4/0xb9 [] skb_dequeue+0x39/0x3f [] unix_release_sock+0x1ac/0x1c4 [] unix_stream_connect+0x308/0x339 [] sys_connect+0x72/0x9c [] skb_dequeue+0x39/0x3f [] skb_queue_purge+0x11/0x17 [] unix_sock_destructor+0xe/0xd2 [] sk_free+0xa4/0xb9 [] getname+0x7b/0xad [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= gpm S f6e81b2c 0 10733 1 f6e81b40 00000082 00000002 f6e81b2c f6e81b24 00000000 c19cf570 c19cf6b0 c1813e00 00000001 ffff974a 000000ff 00000000 00000000 00000000 f6e81b50 00836d49 00000003 00000008 c0267b50 00000000 00001000 c18eec4c c18eec4c Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] kunmap_atomic+0x52/0x7a [] kunmap_atomic+0x5e/0x7a [] get_page_from_freelist+0x257/0x2d6 [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] dput+0x15/0xdd [] __alloc_pages+0x5b/0x2a4 [] shmem_permission+0x0/0xa [] inode_init_once+0x6b/0x118 [] __d_lookup+0x96/0xd5 [] do_lookup+0x4f/0x140 [] dput+0x15/0xdd [] __link_path_walk+0x987/0xaa6 [] do_lookup+0x4f/0x140 [] core_sys_select+0x1dd/0x283 [] get_unused_fd_flags+0x51/0xc3 [] tty_ioctl+0x1c1/0xb3f [] release_console_sem+0x17a/0x193 [] fasync_helper+0x3a/0xb5 [] release_console_sem+0x17a/0x193 [] file_kill+0x11/0x29 [] release_dev+0x416/0x5a0 [] chrdev_open+0x126/0x13a [] nameidata_to_filp+0x23/0x32 [] do_filp_open+0x32/0x39 [] sys_select+0x9d/0x167 [] sys_rt_sigaction+0x64/0x77 [] sysenter_past_esp+0x6b/0xa1 ======================= hpiod S 00000000 0 10738 1 f6dcde28 00200086 00000000 00000000 00000000 dfd0b2b0 c19d8570 c19d86b0 c180ae00 00000000 dfd0b2b0 dfd0b2b0 00000000 c014778a dfc18444 7fffffff 7fffffff f6dcde98 f6dcdebc c0267af3 f7f22988 00200282 00000000 00000000 Call Trace: [] filemap_fault+0x227/0x387 [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] inotify_d_instantiate+0x41/0x66 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] __switch_to+0xa2/0x126 [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= ddclient S c1807dc0 0 10741 1 f6f71f28 00000086 0001731b c1807dc0 00000002 f6f71f10 c192b570 c192b6b0 c180ae00 00000000 0001e242 000000ff 00000000 00000000 0001731b f6f71f40 00000001 00000001 bfbb6574 c0267ee0 00000001 00000000 bfbb6574 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= idled S c1807dc0 0 10744 1 f6f6fb40 00000082 0001731b c1807dc0 00000002 f6f6fb28 f7f78570 f7f786b0 c180ae00 00000000 00023095 000000ff 00000000 00000000 0001731b f6f6fb50 000230f8 00000006 00000040 c0267b50 769fbd72 0000fbea c0363f4c c0363f4c Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] nf_ct_deliver_cached_events+0x3e/0x91 [nf_conntrack] [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] tcp_v4_rcv+0x7f2/0x850 [] ip_local_deliver+0x189/0x230 [] ip_local_deliver_finish+0x0/0x1b1 [] ip_rcv+0x499/0x4d3 [] ip_rcv_finish+0x0/0x2a8 [] __alloc_skb+0x42/0xec [] rhine_napipoll+0x42b/0x435 [via_rhine] [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] net_rx_action+0x99/0x15b [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] __kfree_skb+0xa3/0xfa [] ext3_get_acl+0x51/0x2bf [ext3] [] __d_lookup+0x96/0xd5 [] do_lookup+0x4f/0x140 [] _atomic_dec_and_lock+0x2a/0x44 [] mntput_no_expire+0x11/0x5d [] __link_path_walk+0xa8f/0xaa6 [] __alloc_pages+0x5b/0x2a4 [] core_sys_select+0x1dd/0x283 [] get_unused_fd_flags+0x51/0xc3 [] do_path_lookup+0x161/0x1c4 [] __path_lookup_intent_open+0x6e/0x77 [] path_lookup_open+0x20/0x25 [] open_namei+0x72/0x54c [] irq_exit+0x53/0x6b [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= notifyd S f6821d08 0 10756 10713 f6821d1c 00000082 00000002 f6821d08 f6821d00 00000000 dffceab0 dffcebf0 c180ae00 00000000 ffff9774 000000ff 00000000 00000001 00000000 7fffffff f7509900 00000000 7fffffff c0267af3 c02fdfc4 c02676e9 f6821d74 00000082 Call Trace: [] schedule_timeout+0x13/0x8d [] schedule+0x453/0x511 [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] unix_dgram_recvmsg+0x5c/0x1c0 [] ext3_get_acl+0x51/0x2bf [ext3] [] sock_recvmsg+0xcf/0xe8 [] dput+0x15/0xdd [] autoremove_wake_function+0x0/0x33 [] mntput_no_expire+0x11/0x5d [] link_path_walk+0xa9/0xb3 [] nameidata_to_filp+0x23/0x32 [] sys_recvfrom+0xd7/0x12b [] do_path_lookup+0x161/0x1c4 [] cp_new_stat64+0xf3/0x105 [] sys_socketcall+0x1cd/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= python S c1807dc0 0 10758 1 f682fb40 00200082 00000818 c1807dc0 00000002 f682fb28 dffd5030 dffd5170 c180ae00 00000000 f682fb50 00200282 c01258f2 00000000 00200282 f682fb50 00023183 00000004 00000010 c0267b50 f6c87ec0 f7576680 f025bbf4 c02e98f8 Call Trace: [] __mod_timer+0x97/0xa1 [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] mempool_free+0x68/0x6d [] bio_put+0x23/0x24 [] mpage_end_io_read+0x5b/0x61 [] mpage_end_io_read+0x0/0x61 [] bio_endio+0x5b/0x63 [] __alloc_skb+0x42/0xec [] mempool_free+0x68/0x6d [] clone_endio+0xa5/0xb6 [dm_mod] [] clone_endio+0x0/0xb6 [dm_mod] [] bio_endio+0x5b/0x63 [] mempool_free+0x68/0x6d [] raid5_align_endio+0x88/0xe9 [raid456] [] do_IRQ+0x5c/0x71 [] raid5_align_endio+0x0/0xe9 [raid456] [] bio_endio+0x5b/0x63 [] __add_entropy_words+0x5b/0x176 [] core_sys_select+0x1dd/0x283 [] scsi_end_request+0x9b/0xa5 [scsi_mod] [] scsi_io_completion+0x153/0x36b [scsi_mod] [] scsi_dispatch_cmd+0x1d5/0x245 [scsi_mod] [] sd_rw_intr+0x321/0x329 [sd_mod] [] __ata_qc_complete+0x83/0x89 [libata] [] scsi_next_command+0x25/0x2f [scsi_mod] [] ata_hsm_move+0x6a7/0x6e4 [libata] [] scsi_finish_command+0x81/0x88 [scsi_mod] [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= inetd S f6e83b2c 0 10769 1 f6e83b40 00000086 00000002 f6e83b2c f6e83b24 00000000 c1930570 c19306b0 c180ae00 00000000 ffff9789 000000ff 00000000 00000000 00000000 7fffffff f6e83f9c 00000006 00000040 c0267af3 00000246 c012dfc8 00000246 c012dfc8 Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] add_wait_queue+0xf/0x30 [] tcp_poll+0x18/0x120 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] kunmap_atomic+0x52/0x7a [] kunmap_atomic+0x5e/0x7a [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] handle_mm_fault+0x2f9/0x6f9 [] extract_buf+0x97/0xd2 [] find_lock_page+0x1a/0x90 [] filemap_fault+0x227/0x387 [] core_sys_select+0x1dd/0x283 [] generic_file_aio_read+0x158/0x18b [] handle_mm_fault+0x36e/0x6f9 [] __pagevec_free+0x18/0x22 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_select+0x9d/0x167 [] sys_rt_sigaction+0x4c/0x77 [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= irqbalance S c1807dc0 0 10773 1 f6837f28 00000086 0001731b c1807dc0 00000002 f6837f10 dffdb570 dffdb6b0 c180ae00 00000000 00022dad 000000ff 00000000 00000000 0001731b f6837f40 00000001 00000001 bfeee1f4 c0267ee0 00000001 00000000 bfeee1f4 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S f6847e10 0 10781 1 f6847e24 00000082 00000002 f6847e10 f6847e08 00000000 f7ed8570 f7ed86b0 c180ae00 00000000 ffffa8a0 000000ff 00000000 00000001 00000000 dfd245b4 f6847e90 f6847e3c 0817ed7c c0137213 00000000 00000009 00000009 00000000 Call Trace: [] futex_wait+0x20e/0x2bc [] hrtimer_wakeup+0x0/0x18 [] futex_wait+0x202/0x2bc [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] getnstimeofday+0x35/0xe9 [] ktime_get_ts+0x16/0x44 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S f6d27e10 0 10782 1 f6d27e24 00000082 00000002 f6d27e10 f6d27e08 00000000 dffdc030 dffdc170 c180ae00 00000000 ffffa8a0 000000ff 00000000 00000000 00000000 dfd245b4 f6d27e90 c0385964 08175bfc c01371bb 00000000 000077e9 000077e9 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] __posix_lock_file+0x45d/0x49b [] autoremove_wake_function+0x0/0x33 [] fcntl_setlk64+0x1c5/0x1cf [] sys_futex+0xc2/0xd4 [] sys_fcntl64+0x63/0x6b [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S c0130369 0 10789 1 f687fe24 00000082 c1807f18 c0130369 00000001 00000000 c192a570 c192a6b0 c180ae00 00000000 c0130d22 c01362da 083af6e1 0000019d 00000286 dfd245b4 f687fe90 f687fe3c 08158e5c c0137213 00000000 00000075 00000075 00000000 Call Trace: [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] unqueue_me+0x77/0x80 [] futex_wait+0x20e/0x2bc [] hrtimer_wakeup+0x0/0x18 [] futex_wait+0x202/0x2bc [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] enqueue_entity+0x1e2/0x203 [] getnstimeofday+0x35/0xe9 [] ktime_get_ts+0x16/0x44 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S c1810dc0 0 10791 1 f6883b40 00000082 00000400 c1810dc0 00000002 f6883b28 f7fc5570 f7fc56b0 c180ae00 00000000 0001b32c 000000ff 00000000 00000000 00000400 7fffffff f6883f9c 00000005 00000020 c0267af3 00000246 c012dfc8 f7e7e300 f6883bdc Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] datagram_poll+0x14/0xad [] udp_poll+0xe/0xd3 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] check_preempt_curr_fair+0x69/0x6f [] try_to_wake_up+0x2b0/0x2ba [] autoremove_wake_function+0x13/0x33 [] sock_def_write_space+0x10/0x7d [] sock_wfree+0x21/0x36 [] __kfree_skb+0xa3/0xfa [] e1000_unmap_and_free_tx_resource+0x1b/0x23 [e1000] [] e1000_clean_tx_irq+0xbc/0x2c4 [e1000] [] memcpy_toiovec+0x25/0x47 [] skb_copy_datagram_iovec+0x53/0x1cd [] skb_dequeue+0x39/0x3f [] skb_recv_datagram+0x6b/0x172 [] __kfree_skb+0xa3/0xfa [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] core_sys_select+0x1dd/0x283 [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] wake_futex+0x39/0x43 [] futex_wake+0xaa/0xb4 [] do_futex+0x80/0x999 [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] __kfree_skb+0xa3/0xfa [] sys_select+0x9d/0x167 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S c1807dc0 0 10793 1 f6887e24 00000082 0001731b c1807dc0 00000002 f6887e0c dffca030 dffca170 c180ae00 00000000 00022888 000000ff 00000000 00000000 0001731b dfd245b4 f6887e90 f6887e3c 0815953c c0137213 00000000 00000077 00000077 00000000 Call Trace: [] futex_wait+0x20e/0x2bc [] hrtimer_wakeup+0x0/0x18 [] futex_wait+0x202/0x2bc [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] enqueue_entity+0x1e2/0x203 [] getnstimeofday+0x35/0xe9 [] ktime_get_ts+0x16/0x44 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S c0130369 0 10795 1 f688be24 00000082 c1807f18 c0130369 00000001 00000000 c1923030 c1923170 c180ae00 00000000 c0130d22 c01362da 23fe10fc 00000196 00000286 dfd245b4 f688be90 f688be3c 08158ffc c0137213 00000000 0000016b 0000016b 00000000 Call Trace: [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] unqueue_me+0x77/0x80 [] futex_wait+0x20e/0x2bc [] hrtimer_wakeup+0x0/0x18 [] futex_wait+0x202/0x2bc [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] enqueue_entity+0x1e2/0x203 [] getnstimeofday+0x35/0xe9 [] ktime_get_ts+0x16/0x44 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S f62f9e10 0 10888 1 f62f9e24 00000082 00000002 f62f9e10 f62f9e08 00000000 f7851030 f7851170 c180ae00 00000000 ffff981d 000000ff 00000000 00000000 00000000 dfd245b4 f62f9e90 c0386120 0815fafc c01371bb c0149ceb 00000001 00000001 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] __alloc_pages+0x5b/0x2a4 [] find_mergeable_anon_vma+0x5e/0xb0 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] flush_tlb_mm+0x57/0x5c [] check_pgt_cache+0x19/0x1b [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mediatomb S f6375e10 0 10889 1 f6375e24 00000082 00000002 f6375e10 f6375e08 00000000 dffca570 dffca6b0 c1813e00 00000001 ffffa8a0 000000ff 00000000 00000000 00000000 dfd245b4 f6375e90 c0385784 0817e684 c01371bb 00000000 00000001 00000001 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] xfs_file_readdir+0x1d2/0x1e0 [xfs] [] filldir64+0x0/0xc4 [] dput+0x15/0xdd [] sys_futex+0xc2/0xd4 [] sys_clock_gettime+0x57/0x7d [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mysqld_safe S c1810dc0 0 10813 1 f68aff3c 00000082 00000400 c1810dc0 00000002 f68aff24 c192e570 c192e6b0 c1813e00 00000001 ffff97eb 000000ff 00000000 00000000 00000400 f7ed8030 00000001 c192e570 00000000 c0121237 00000001 c01016a3 c192e570 c192e570 Call Trace: [] do_wait+0x926/0x9da [] __switch_to+0xa2/0x126 [] default_wake_function+0x0/0xc [] sys_wait4+0x30/0x33 [] sys_waitpid+0x27/0x2b [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mysqld S f68c5b2c 0 10877 10813 f68c5b40 00200086 00000002 f68c5b2c f68c5b24 00000000 f7849570 f78496b0 c1813e00 00000001 ffff98e6 000000ff 00000000 00000000 00000000 7fffffff f68c5f9c 00000010 00010000 c0267af3 f7f291e8 f7f45dc0 00200246 c012dfc8 Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] add_wait_queue+0xf/0x30 [] unix_poll+0x15/0x8c [] do_select+0x3a1/0x3f7 [] blk_plug_device+0x6b/0xb2 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] find_mergeable_anon_vma+0x4c/0xb0 [] anon_vma_prepare+0x57/0x9c [] handle_mm_fault+0x2f9/0x6f9 [] ext3_getblk+0x105/0x21c [ext3] [] ext3_find_entry+0x4a1/0x52f [ext3] [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] ip_setsockopt+0x9d7/0xa5a [] do_page_fault+0x2ed/0x63d [] ext3_get_acl+0x51/0x2bf [ext3] [] __d_lookup+0x96/0xd5 [] do_page_fault+0x0/0x63d [] error_code+0x72/0x78 [] kunmap_atomic+0x52/0x7a [] kunmap_atomic+0x5e/0x7a [] file_read_actor+0x77/0xc7 [] core_sys_select+0x1dd/0x283 [] __rmqueue+0x78/0xcb [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] wake_up_new_task+0xab/0xbb [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S c01542ea 0 10879 10813 f6b3fe24 00200086 08ad3000 c01542ea 08ad3ba0 08ad3000 c19cfab0 c19cfbf0 c180ae00 00000000 00000000 f6853bfc f6853bfc dfe70934 00200246 dfe70934 f6b3fe90 c0385658 08ad3ba0 c01371bb f6853ca4 00000001 00000001 00000000 Call Trace: [] find_extend_vma+0x12/0x49 [] futex_wait+0x1b6/0x2bc [] __do_fault+0x30e/0x33b [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] do_page_fault+0x0/0x63d [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mysqld S c01542ea 0 10880 10813 f6b41e24 00200086 08ad3000 c01542ea 08ad3c10 08ad3000 c19d5030 c19d5170 c1813e00 00000001 c011a316 00000800 00000000 dfe70934 00200246 dfe70934 f6b41e90 c0385464 08ad3c10 c01371bb 014d8000 00000007 00000007 00000000 Call Trace: [] find_extend_vma+0x12/0x49 [] try_to_wake_up+0x2b0/0x2ba [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] pagevec_lookup_tag+0x23/0x2a [] wait_on_page_writeback_range+0xaf/0xf7 [] ext3_sync_file+0xa3/0xb8 [ext3] [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S f6b43e10 0 10881 10813 f6b43e24 00200086 00000002 f6b43e10 f6b43e08 00000000 c19c1ab0 c19c1bf0 c180ae00 00000000 ffff98f2 000000ff 00000000 00000000 00000000 dfe70934 f6b43e90 c0385590 08ad3c80 c01371bb c0149ceb 00000005 00000005 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mysqld S f6b45e10 0 10882 10813 f6b45e24 00200086 00000002 f6b45e10 f6b45e08 00000000 c1a25ab0 c1a25bf0 c180ae00 00000000 ffff9d24 000000ff 00000000 00000000 00000000 dfe70934 f6b45e90 c0385ae0 08ad3cf0 c01371bb 00000000 00000003 00000003 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] __wake_up_common+0x32/0x55 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] schedule+0x453/0x511 [] sys_futex+0xc2/0xd4 [] sys_pwrite64+0x57/0x5e [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S c1807dc0 0 10884 10813 f610fb40 00200086 0001731b c1807dc0 00000002 f610fb28 c1a4e030 c1a4e170 c180ae00 00000000 00023088 000000ff 00000000 00000000 0001731b f610fb50 000230eb 00000000 f6c240c0 c0267b50 eb7c9300 c15dcfa0 c0363ee4 f6111b50 Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] enqueue_entity+0x1e2/0x203 [] task_rq_lock+0x42/0x69 [] try_to_wake_up+0x2b0/0x2ba [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] lock_timer_base+0x19/0x35 [] __mod_timer+0x97/0xa1 [] __nf_ct_refresh_acct+0xe9/0x118 [nf_conntrack] [] tcp_packet+0xa09/0xa1b [nf_conntrack] [] mpage_end_io_read+0x0/0x61 [] tcp_error+0x107/0x1d7 [nf_conntrack] [] __wake_up+0x32/0x43 [] ipt_do_table+0x486/0x4bc [ip_tables] [] tcp_check_req+0x1e5/0x2f9 [] tcp_v4_do_rcv+0x2f1/0x323 [] core_sys_select+0x1dd/0x283 [] tcp_v4_rcv+0x7f2/0x850 [] ip_local_deliver+0x189/0x230 [] ip_local_deliver_finish+0x0/0x1b1 [] ip_rcv+0x499/0x4d3 [] ip_rcv_finish+0x0/0x2a8 [] __alloc_skb+0x42/0xec [] rhine_napipoll+0x42b/0x435 [via_rhine] [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S c1807dc0 0 10885 10813 f6111b40 00200086 0001731b c1807dc0 00000002 f6111b28 c19d9ab0 c19d9bf0 c180ae00 00000000 00023024 000000ff 00000000 00000000 0001731b f6111b50 000230eb 00000000 f6c240c0 c0267b50 02932e00 00000001 f610fb50 c0363ee4 Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] update_curr+0x103/0x12a [] rb_insert_color+0x8a/0xad [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] try_to_wake_up+0x2b0/0x2ba [] tcp_packet+0xa09/0xa1b [nf_conntrack] [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] e1000_xmit_frame+0x995/0x9be [e1000] [] __wake_up+0x32/0x43 [] packet_rcv+0x2bd/0x307 [af_packet] [] packet_rcv+0x0/0x307 [af_packet] [] dev_hard_start_xmit+0x200/0x275 [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] core_sys_select+0x1dd/0x283 [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_forward+0x275/0x2d2 [] ip_forward_finish+0x0/0x2e [] ip_rcv+0x499/0x4d3 [] ip_rcv_finish+0x0/0x2a8 [] __alloc_skb+0x42/0xec [] rhine_napipoll+0x42b/0x435 [via_rhine] [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S f6113e10 0 10886 10813 f6113e24 00200086 00000002 f6113e10 f6113e08 00000000 f7f72030 f7f72170 c1813e00 00000001 ffffcbf2 000000ff 00000000 00000001 00000000 dfe70934 f6113e90 c03856d0 0878ee88 c01371bb 00000000 00000007 00000007 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] sys_futex+0xc2/0xd4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mysqld S f62c5eb4 0 10887 10813 f62c5ec8 00200086 00000002 f62c5eb4 f62c5eac 00000000 c1a25570 c1a256b0 c1813e00 00000001 ffffa74b 000000ff 00000000 00000001 00000000 7fffffff 7fffffff 00000000 00000000 c0267af3 c0126371 00000000 00000000 0000000d Call Trace: [] schedule_timeout+0x13/0x8d [] __dequeue_signal+0x10/0x11c [] recalc_sigpending+0xb/0x1d [] dequeue_signal+0x99/0x112 [] getnstimeofday+0x35/0xe9 [] sys_rt_sigtimedwait+0x177/0x245 [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] do_setitimer+0x13b/0x2e1 [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sys_rt_sigprocmask+0x4b/0xc4 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S 00000001 0 10993 10813 f3bffd88 00200086 00000001 00000001 00004000 001257e8 c19c6030 c19c6170 c1813e00 00000001 c01258f2 00000001 00200286 00200286 f7f1b080 7fffffff f6e23080 f6e230ec 00000004 c0267af3 f6e23080 dfcef0b0 0020d9a4 00000020 Call Trace: [] __mod_timer+0x97/0xa1 [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] sk_wait_data+0x64/0x97 [] autoremove_wake_function+0x0/0x33 [] tcp_recvmsg+0x33a/0x720 [] __d_lookup+0x96/0xd5 [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] do_sync_read+0xc7/0x10a [] specific_send_sig_info+0x8c/0x97 [] autoremove_wake_function+0x0/0x33 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S f3441d74 0 10996 10813 f3441d88 00200086 00000002 f3441d74 f3441d6c 00000000 f7f46ab0 f7f46bf0 c180ae00 00000000 ffffa2d5 000000ff 00000000 00000000 00000000 7fffffff f3efe580 f3efe5ec 00000004 c0267af3 00000199 eb237680 c020d9a4 eb2376a0 Call Trace: [] schedule_timeout+0x13/0x8d [] sk_reset_timer+0xc/0x16 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] sk_wait_data+0x64/0x97 [] autoremove_wake_function+0x0/0x33 [] tcp_recvmsg+0x33a/0x720 [] find_lock_page+0x1a/0x90 [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S f358bd74 0 10998 10813 f358bd88 00200086 00000002 f358bd74 f358bd6c 00000000 c19d3ab0 c19d3bf0 c180ae00 00000000 ffffc7a8 000000ff 00000000 00000001 00000000 7fffffff f3506a80 f3506aec 00000004 c0267af3 f3506a80 c1b138b0 0020d9a4 00000020 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] sk_wait_data+0x64/0x97 [] autoremove_wake_function+0x0/0x33 [] tcp_recvmsg+0x33a/0x720 [] try_to_wake_up+0x2b0/0x2ba [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S c1807dc0 0 11000 10813 f35fbd88 00200086 00000400 c1807dc0 00000002 f35fbd70 c19c0570 c19c06b0 c180ae00 00000000 ffffa2c2 000000ff 00000000 00000000 00000400 7fffffff f35b0a80 f35b0aec 00000004 c0267af3 0000019b f6c93c80 c020d9a4 f6c93ca0 Call Trace: [] schedule_timeout+0x13/0x8d [] sk_reset_timer+0xc/0x16 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] sk_wait_data+0x64/0x97 [] autoremove_wake_function+0x0/0x33 [] tcp_recvmsg+0x33a/0x720 [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] __wake_up+0x32/0x43 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= mysqld S f08a5d74 0 11293 10813 f08a5d88 00200086 00000002 f08a5d74 f08a5d6c 00000000 f14afab0 f14afbf0 c1813e00 00000001 ffffa2d6 000000ff 00000000 00000000 00000000 7fffffff f0883a80 f0883aec 00000004 c0267af3 00000189 eb237680 c020d9a4 eb2376a0 Call Trace: [] schedule_timeout+0x13/0x8d [] sk_reset_timer+0xc/0x16 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] sk_wait_data+0x64/0x97 [] autoremove_wake_function+0x0/0x33 [] tcp_recvmsg+0x33a/0x720 [] __d_lookup+0x96/0xd5 [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= logger S f68b9e48 0 10878 10813 f68b9e5c 00000082 00000002 f68b9e48 f68b9e40 00000000 f7ed8030 f7ed8170 c1813e00 00000001 ffff9821 000000ff 00000000 00000000 00000000 f789e200 f789e200 f68b9e78 c1972d40 c0166f4a 00000000 f7ed8030 c012dd98 f789e204 Call Trace: [] pipe_wait+0x51/0x6f [] autoremove_wake_function+0x0/0x33 [] pipe_read+0x2cf/0x343 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] sys_send+0x37/0x3b [] do_sync_read+0x0/0x10a [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= ntop S c1807dc0 0 10961 1 f42bdf28 00200082 0001731b c1807dc0 00000002 f42bdf10 f7fab570 f7fab6b0 c180ae00 00000000 00022da0 000000ff 00000000 00000000 0001731b f42bdf40 00000001 00000001 bf84d158 c0267ee0 00000001 00000000 0087e000 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= ntop S f311be10 0 11002 1 f311be24 00200082 00000002 f311be10 f311be08 00000000 dffd0570 dffd06b0 c180ae00 00000000 ffff9977 000000ff 00000000 00000000 00000000 f7ef1074 f311be90 c038584c b68b9ad0 c01371bb 00000000 00000001 00000001 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] __wake_up_common+0x32/0x55 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] recalc_sigpending+0xb/0x1d [] do_notify_resume+0x4fa/0x5ef [] __switch_to+0xa2/0x126 [] convert_fxsr_from_user+0x15/0xd2 [] sys_futex+0xc2/0xd4 [] sys_rt_sigreturn+0xc3/0xe6 [] sysenter_past_esp+0x6b/0xa1 ======================= ntop S c1807dc0 0 11003 1 f311df28 00200082 0001731b c1807dc0 00000002 f311df10 dffda570 dffda6b0 c180ae00 00000000 00022da1 000000ff 00000000 00000000 0001731b f311df40 00000001 00000001 b56e33a8 c0267ee0 00000001 00000000 00002ad1 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= ntop S c1807dc0 0 11004 1 f311ff28 00200082 0001731b c1807dc0 00000002 f311ff10 dffe1570 dffe16b0 c180ae00 00000000 00022dd0 000000ff 00000000 00000000 0001731b f311ff40 00000001 00000001 b4ee23b8 c0267ee0 00000001 00000000 00002ad1 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= ntop S c1807dc0 0 11005 1 f3121e24 00200082 0001731b c1807dc0 00000002 f3121e0c c19cf030 c19cf170 c180ae00 00000000 000225f2 000000ff 00000000 00000000 0001731b f7ef1074 f3121e90 c0385860 b68b9b1c c01371bb f3121edc 0000000f 0000000f 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] __switch_to+0xa2/0x126 [] sys_futex+0xc2/0xd4 [] sys_write+0x5f/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= ntop S c1807dc0 0 11008 1 f31ffb40 00200082 0001731b c1807dc0 00000002 f31ffb28 dffd5570 dffd56b0 c180ae00 00000000 00022d9f 000000ff 00000000 00000000 0001731b f31ffb50 00023186 00000002 00000004 c0267b50 f31fff9c c0103324 e540d478 df090914 Call Trace: [] schedule_timeout+0x70/0x8d [] apic_timer_interrupt+0x28/0x30 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] try_to_wake_up+0x2b0/0x2ba [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] sock_def_readable+0x37/0x61 [] unix_dgram_sendmsg+0x382/0x402 [] ata_qc_issue+0x43c/0x480 [libata] [] __scsi_get_command+0x13/0x51 [scsi_mod] [] scsi_get_command+0x7d/0x96 [scsi_mod] [] scsi_done+0x0/0x16 [scsi_mod] [] ata_scsi_translate+0xfb/0x156 [libata] [] scsi_prep_fn+0xb6/0x216 [scsi_mod] [] elv_next_request+0x191/0x1a1 [] scsi_dispatch_cmd+0x1d5/0x245 [scsi_mod] [] core_sys_select+0x1dd/0x283 [] scsi_end_request+0x9b/0xa5 [scsi_mod] [] scsi_io_completion+0x153/0x36b [scsi_mod] [] del_timer+0x45/0x4b [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] __kfree_skb+0xa3/0xfa [] net_tx_action+0x71/0xf0 [] irq_exit+0x53/0x6b [] do_IRQ+0x5c/0x71 [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] __kfree_skb+0xa3/0xfa [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= ntop S c1807dc0 0 11009 1 f3257f28 00200082 0001731b c1807dc0 00000002 f3257f10 dffe0030 dffe0170 c180ae00 00000000 00022f99 000000ff 00000000 00000000 0001731b f3257f40 00000001 00000001 b36aaa28 c0267ee0 00000001 00000000 00000000 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= ntop R running 0 11010 1 ntop S c1807dc0 0 11389 1 eed7df28 00200082 0001731b c1807dc0 00000002 eed7df10 f1bdfab0 f1bdfbf0 c180ae00 00000000 00022db6 000000ff 00000000 00000000 0001731b eed7df40 00000001 00000001 b26a91b8 c0267ee0 00000001 00000000 00002ad1 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c1807dc0 0 10978 1 f39cbf28 00000082 0001731b c1807dc0 00000002 f39cbf10 c1926030 c1926170 c180ae00 00000000 000230a5 000000ff 00000000 00000000 0001731b f39cbf40 00000001 00000001 bfe8d874 c0267ee0 00000001 00000000 bfe8d874 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= pdns_server S 00000000 0 10979 1 f39ede40 00000082 c0146f51 00000000 dfd0b2b0 dfd0b2b0 dffdbab0 dffdbbf0 c1813e00 00000001 c1673a20 f39d2000 00000000 c0149ceb 00000002 7fffffff f7509700 ffffff95 7fffffff c0267af3 c02db5d0 00000001 00000000 00000001 Call Trace: [] find_lock_page+0x1a/0x90 [] get_page_from_freelist+0x257/0x2d6 [] schedule_timeout+0x13/0x8d [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] unix_accept+0x4e/0xd4 [] sys_accept+0xd8/0x1ad [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= pdns_server S f39efe10 0 10980 10978 f39efe24 00000086 00000002 f39efe10 f39efe08 00000000 c19c5030 c19c5170 c1813e00 00000001 ffff9966 000000ff 00000000 00000001 00000000 dfd24af4 f39efe90 c03857c0 b439bbf8 c01371bb c0149ceb 00002af9 00002af9 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] __rmqueue+0x78/0xcb [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] schedule+0x453/0x511 [] sys_futex+0xc2/0xd4 [] sys_clone+0x36/0x3b [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c1677420 0 10990 10978 f3bd9e5c 00000086 c1677420 c1677420 f3bd9e8c f769ae9c dffe0ab0 dffe0bf0 c1813e00 00000001 00000000 00000000 c17e1600 00000246 c012deee f7f06c00 f7f06c00 f3bd9e78 f7e6fac0 c0166f4a 00000000 dffe0ab0 c012dd98 f7f06c04 Call Trace: [] prepare_to_wait+0x12/0x4b [] pipe_wait+0x51/0x6f [] autoremove_wake_function+0x0/0x33 [] pipe_read+0x2cf/0x343 [] handle_mm_fault+0x36e/0x6f9 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_sync_read+0x0/0x10a [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= pdns_server S 00000000 0 10991 10978 f3bdbe28 00000086 00000000 00000000 c19d9030 00000000 c19d9030 c19d9170 c1813e00 00000001 f3bdbe08 f3bdbe08 00000000 00000000 c0169457 7fffffff 7fffffff f3bdbe98 f3bdbebc c0267af3 00000000 00000282 dfc18c44 d662d853 Call Trace: [] __link_path_walk+0x932/0xaa6 [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] cp_new_stat64+0xf3/0x105 [] sys_send+0x37/0x3b [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c1807dc0 0 10992 10978 f3bddf28 00000086 0001731b c1807dc0 00000002 f3bddf10 dffd7ab0 dffd7bf0 c180ae00 00000000 000230a7 000000ff 00000000 00000000 0001731b f3bddf40 00000001 00000001 b6ba01d4 c0267ee0 00000001 00000000 b6ba01d4 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S 00000000 0 10994 10978 f343db40 00000086 00000000 00000000 00000000 00000000 c1912030 c1912170 c1813e00 00000001 00000000 00000000 00000000 00000000 00000000 7fffffff f343df9c 00000007 00000080 c0267af3 00000000 00000000 00000246 c012dfc8 Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] tcp_poll+0x18/0x120 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] find_lock_page+0x1a/0x90 [] filemap_fault+0x227/0x387 [] core_sys_select+0x1dd/0x283 [] handle_mm_fault+0x36e/0x6f9 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= pdns_server S f343fe10 0 10995 10978 f343fe24 00000086 00000002 f343fe10 f343fe08 00000000 dffe1030 dffe1170 c1813e00 00000001 ffffa2d6 000000ff 00000000 00000000 00000000 dfd24af4 f343fe90 c03855f4 0814c378 c01371bb 7fffffff 00000000 00000000 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] do_gettimeofday+0x35/0xfe [] sys_futex+0xc2/0xd4 [] sys_gettimeofday+0x26/0x52 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c01542ea 0 10997 10978 f3589e24 00000086 0814c000 c01542ea 0814c378 0814c000 dffce030 dffce170 c180ae00 00000000 00000000 00000000 dffce030 dfd24af4 00000246 dfd24af4 f3589e90 c03855f4 0814c378 c01371bb 7fffffff 00000000 00000000 00000000 Call Trace: [] find_extend_vma+0x12/0x49 [] futex_wait+0x1b6/0x2bc [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] do_gettimeofday+0x35/0xfe [] sys_futex+0xc2/0xd4 [] sys_gettimeofday+0x26/0x52 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c01542ea 0 10999 10978 f35f9e24 00000086 0814c000 c01542ea 0814c378 0814c000 dffd7030 dffd7170 c1813e00 00000001 00000000 00000000 dffd7030 dfd24af4 00000246 dfd24af4 f35f9e90 c03855f4 0814c378 c01371bb 7fffffff 00000000 00000000 00000000 Call Trace: [] find_extend_vma+0x12/0x49 [] futex_wait+0x1b6/0x2bc [] sock_common_recvmsg+0x3e/0x54 [] sock_aio_read+0xd1/0xdd [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] do_gettimeofday+0x35/0xfe [] sys_futex+0xc2/0xd4 [] sys_gettimeofday+0x26/0x52 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S c1807dc0 0 11001 10978 f373dd0c 00000086 00000400 c1807dc0 00000002 f373dcf4 f7ef3ab0 f7ef3bf0 c180ae00 00000000 ffffc7a4 000000ff 00000000 00000000 00000400 7fffffff f5cdfd00 00000000 7fffffff c0267af3 00000000 00000000 00000000 f373df58 Call Trace: [] schedule_timeout+0x13/0x8d [] memcpy_toiovec+0x25/0x47 [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] udp_recvmsg+0x5d/0x1d1 [] sock_common_recvmsg+0x3e/0x54 [] sock_recvmsg+0xcf/0xe8 [] autoremove_wake_function+0x0/0x33 [] try_to_wake_up+0x2b0/0x2ba [] __wake_up+0x32/0x43 [] sys_recvfrom+0xd7/0x12b [] futex_wake+0xaa/0xb4 [] do_futex+0x80/0x999 [] getnstimeofday+0x35/0xe9 [] lapic_next_event+0xc/0x10 [] clockevents_program_event+0x9e/0xaa [] sys_socketcall+0x1cd/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_server S f08a3e10 0 11292 10978 f08a3e24 00000086 00000002 f08a3e10 f08a3e08 00000000 f16b2570 f16b26b0 c180ae00 00000000 ffffa2d5 000000ff 00000000 00000000 00000000 dfd24af4 f08a3e90 c03855f4 0814c378 c01371bb c0149ceb 00000000 00000000 00000000 Call Trace: [] futex_wait+0x1b6/0x2bc [] get_page_from_freelist+0x257/0x2d6 [] __alloc_pages+0x5b/0x2a4 [] default_wake_function+0x0/0xc [] do_futex+0x6d/0x999 [] autoremove_wake_function+0x0/0x33 [] do_gettimeofday+0x35/0xfe [] sys_futex+0xc2/0xd4 [] sys_gettimeofday+0x26/0x52 [] sysenter_past_esp+0x6b/0xa1 ======================= pdns_recursor S c1807dc0 0 11011 1 f3313f28 00000086 0001731b c1807dc0 00000002 f3313f10 c192bab0 c192bbf0 c180ae00 00000000 0002308e 000000ff 00000000 00000000 0001731b f3313f38 000230bf 00000020 00000206 c0267b50 0001e78b ec687380 c0363d84 c0363d84 Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] sys_epoll_wait+0x156/0x39f [] default_wake_function+0x0/0xc [] sys_gettimeofday+0x26/0x52 [] sysenter_past_esp+0x6b/0xa1 ======================= master S c1807dc0 0 11076 1 f2059b40 00000086 0001731b c1807dc0 c02db59c 000000d0 f2c8e570 f2c8e6b0 c180ae00 00000000 f2059b50 00000282 c01258f2 00000000 00000282 f2059b50 000242ac 0000005c 10000000 c0267b50 f2059bdc 00000000 c0363f9c c0363f9c Call Trace: [] __mod_timer+0x97/0xa1 [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] core_sys_select+0x1dd/0x283 [] do_sync_read+0xc7/0x10a [] getnstimeofday+0x35/0xe9 [] rb_insert_color+0x4a/0xad [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= pickup S c1807dc0 0 11079 11076 f2711b40 00200082 0001731b c1807dc0 00000002 f2711b28 f2c8eab0 f2c8ebf0 c180ae00 00000000 00022b3d 000000ff 00000000 00000000 0001731b f2711b50 0002524c 00000007 00000080 c0267b50 02625a00 00000000 c036401c c036401c Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] try_to_wake_up+0x2b0/0x2ba [] __wait_on_bit+0x4e/0x56 [] sync_buffer+0x0/0x33 [] out_of_line_wait_on_bit+0x63/0x6b [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] __find_get_block_slow+0x117/0x121 [] ext3_get_blocks_handle+0xc3/0x855 [ext3] [] __find_get_block+0x1c4/0x1ce [] task_rq_lock+0x42/0x69 [] try_to_wake_up+0x2b0/0x2ba [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] core_sys_select+0x1dd/0x283 [] sock_aio_write+0xc8/0xd4 [] filldir64+0x92/0xc4 [] do_sync_write+0xc7/0x10a [] getnstimeofday+0x35/0xe9 [] rb_insert_color+0x8a/0xad [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= qmgr S c1807dc0 0 11080 11076 f2799b40 00200086 0001731b c1807dc0 00000002 f2799b28 c192e030 c192e170 c180ae00 00000000 0001e48a 000000ff 00000000 00000000 0001731b f2799b50 0002a7d9 00000007 00000080 c0267b50 c01a36d8 00000000 e5d6f73c f02e7bf4 Call Trace: [] schedule_timeout+0x70/0x8d [] get_request+0x1fa/0x298 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] get_request+0x1fa/0x298 [] update_stats_wait_end+0x9b/0xbe [] elv_rb_add+0x61/0x6b [] deadline_add_rq_rb+0x19/0x2c [] deadline_add_request+0x18/0x39 [] pdc_qc_prep+0x2b/0x26a [sata_promise] [] ata_qc_issue+0x43c/0x480 [libata] [] ata_scsi_rw_xlat+0x151/0x19d [libata] [] scsi_done+0x0/0x16 [scsi_mod] [] ata_scsi_translate+0xfb/0x156 [libata] [] scsi_prep_fn+0x1aa/0x216 [scsi_mod] [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] schedule+0x453/0x511 [] submit_bio+0xb5/0xbc [] io_schedule+0x1d/0x27 [] ext3fs_dirhash+0x109/0x1d6 [ext3] [] core_sys_select+0x1dd/0x283 [] htree_dirblock_to_tree+0x11c/0x126 [ext3] [] filldir64+0x92/0xc4 [] call_filldir+0xaf/0xc6 [ext3] [] filldir64+0x0/0xc4 [] ext3_readdir+0x1fb/0x5d7 [ext3] [] getnstimeofday+0x35/0xe9 [] filldir64+0x0/0xc4 [] enqueue_hrtimer+0xdc/0xe7 [] sys_select+0x9d/0x167 [] getnstimeofday+0x35/0xe9 [] sysenter_past_esp+0x6b/0xa1 ======================= nmbd S c1807dc0 0 11090 1 f2325b40 00000086 0001731b c1807dc0 00000002 f2325b28 f3ee1030 f3ee1170 c180ae00 00000000 00022fab 000000ff 00000000 00000000 0001731b f2325b50 00023392 0000000c 00001000 c0267b50 00000246 c012dfc8 f6e89b50 ea1a4bd8 Call Trace: [] schedule_timeout+0x70/0x8d [] add_wait_queue+0xf/0x30 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] dev_queue_xmit+0x289/0x2ae [] ip_mc_output+0x38d/0x3c6 [] ip_finish_output+0x0/0x218 [] ip_push_pending_frames+0x348/0x3da [] dst_output+0x0/0x7 [] udp_push_pending_frames+0x2ac/0x2fe [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] memcpy_toiovec+0x25/0x47 [] skb_copy_datagram_iovec+0x53/0x1cd [] skb_dequeue+0x39/0x3f [] skb_recv_datagram+0x6b/0x172 [] __kfree_skb+0xa3/0xfa [] udp_recvmsg+0x184/0x1d1 [] sock_common_recvmsg+0x3e/0x54 [] sock_recvmsg+0xcf/0xe8 [] sock_sendmsg+0xbc/0xd4 [] autoremove_wake_function+0x0/0x33 [] core_sys_select+0x1dd/0x283 [] move_addr_to_user+0x4e/0x66 [] sys_recvfrom+0x108/0x12b [] __dev_get_by_name+0x5d/0x67 [] fasync_helper+0x3a/0xb5 [] __posix_lock_file+0x47d/0x49b [] _spin_lock_bh+0x8/0x18 [] inet_sock_destruct+0x161/0x1a7 [] _spin_lock_bh+0x8/0x18 [] sys_select+0x9d/0x167 [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= smbd S f1e5bb2c 0 11092 1 f1e5bb40 00200082 00000002 f1e5bb2c f1e5bb24 00000000 f3ee1570 f3ee16b0 c180ae00 00000000 ffff9a93 000000ff 00000000 00000000 00000000 7fffffff f1e5bf9c 00000017 00800000 c0267af3 c0119e96 02625a00 00200246 c012dfc8 Call Trace: [] schedule_timeout+0x13/0x8d [] enqueue_entity+0x1e2/0x203 [] add_wait_queue+0xf/0x30 [] add_wait_queue+0xf/0x30 [] pipe_poll+0x24/0x7b [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] extract_buf+0x97/0xd2 [] extract_buf+0x97/0xd2 [] __rmqueue+0x78/0xcb [] find_lock_page+0x1a/0x90 [] filemap_fault+0x227/0x387 [] __alloc_pages+0x5b/0x2a4 [] core_sys_select+0x1dd/0x283 [] flush_tlb_page+0x3d/0x61 [] handle_mm_fault+0x36e/0x6f9 [] tcp_v4_hash+0x164/0x176 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_select+0x9d/0x167 [] do_pipe+0x81/0xd5 [] do_fcntl+0x1c1/0x247 [] sysenter_past_esp+0x6b/0xa1 ======================= smbd4wins S c1807dc0 0 11096 1 f18b9b40 00000086 0001731b c1807dc0 00000002 f18b9b28 c19c6ab0 c19c6bf0 c180ae00 00000000 00022bb4 000000ff 00000000 00000000 0001731b f18b9b50 00023190 0000000d 00002000 c0267b50 00000246 c012dfc8 e5ed2bd8 c4409288 Call Trace: [] schedule_timeout+0x70/0x8d [] add_wait_queue+0xf/0x30 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] ip_local_deliver+0x189/0x230 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] local_bh_enable+0x87/0x95 [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_push_pending_frames+0x348/0x3da [] dst_output+0x0/0x7 [] udp_push_pending_frames+0x2ac/0x2fe [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] udp_sendmsg+0x4d2/0x5bf [] inet_sendmsg+0x39/0x43 [] sock_sendmsg+0xbc/0xd4 [] __ext3_get_inode_loc+0x117/0x2dd [ext3] [] core_sys_select+0x1dd/0x283 [] ext3_mark_inode_dirty+0x20/0x27 [ext3] [] __ext3_journal_stop+0x19/0x34 [ext3] [] __mark_inode_dirty+0xca/0x143 [] ext3_orphan_del+0x31/0x141 [ext3] [] cache_alloc_refill+0x64/0x487 [] fasync_helper+0x3a/0xb5 [] __posix_lock_file+0x47d/0x49b [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= smbd S f1909fb8 0 11098 11092 f1909fac 00200082 00000007 f1909fb8 f7f3fab0 00000001 f7f3fab0 f7f3fbf0 c180ae00 00000000 0000000e f1909fb8 c02a44ef 00000007 0000000e 00000001 00000001 bfd24260 f1908000 c012630e c0102802 00000001 b7d9f368 083e2e98 Call Trace: [] sys_pause+0x11/0x17 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= saslauthd S f1b67f40 0 11109 1 f1b67f54 00200086 00000002 f1b67f40 f1b67f38 00000000 c19daab0 c19dabf0 c180ae00 00000000 00014e38 000000ff 00000000 00200246 c012deee f5d65d1c f7e1e4c0 f1b67f7c 00000007 c016f23f 00000000 00000007 0000001c 00000000 Call Trace: [] prepare_to_wait+0x12/0x4b [] fcntl_setlk+0x14f/0x1cf [] autoremove_wake_function+0x0/0x33 [] sys_fcntl64+0x5a/0x6b [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= saslauthd S 00000000 0 11110 11109 f1b69f54 00200082 00000000 00000000 00000001 00000000 c19c0ab0 c19c0bf0 c180ae00 00000000 dfe34324 00000003 00200246 00200246 c012deee f20faa7c f7e1e4c0 f1b69f7c 00000007 c016f23f 00000000 00000007 0000001c 00000000 Call Trace: [] prepare_to_wait+0x12/0x4b [] fcntl_setlk+0x14f/0x1cf [] autoremove_wake_function+0x0/0x33 [] sys_fcntl64+0x5a/0x6b [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= saslauthd S 00000000 0 11111 11109 f1ba9e40 00200082 c0146f51 00000000 dfd0b2b0 dfd0b2b0 f2c5e570 f2c5e6b0 c180ae00 00000000 00000002 f1ba9e8c dffb095c dfd0b358 c1bea908 7fffffff f270a700 ffffff95 7fffffff c0267af3 c17e12c0 00000000 c17e12c0 c1810dac Call Trace: [] find_lock_page+0x1a/0x90 [] schedule_timeout+0x13/0x8d [] __next_cpu+0x12/0x1f [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] unix_accept+0x4e/0xd4 [] sys_accept+0xd8/0x1ad [] update_stats_wait_end+0x9b/0xbe [] update_curr_load+0x6e/0x83 [] __switch_to+0xa2/0x126 [] __posix_lock_file+0x47d/0x49b [] schedule+0x453/0x511 [] fcntl_setlk+0x1c5/0x1cf [] sys_socketcall+0xd6/0x262 [] sys_fcntl64+0x63/0x6b [] sysenter_past_esp+0x6b/0xa1 ======================= saslauthd S 00000003 0 11112 11109 f1babf54 00200082 00000000 00000003 f1babf90 0000000d f3ee1ab0 f3ee1bf0 c180ae00 00000000 f7fb7e74 f7fb7e40 b7b2fcef 00200246 c012deee f5d6517c f7e1e4c0 f1babf7c 00000007 c016f23f 00000000 00000007 0000001c 00000000 Call Trace: [] prepare_to_wait+0x12/0x4b [] fcntl_setlk+0x14f/0x1cf [] autoremove_wake_function+0x0/0x33 [] sys_fcntl64+0x5a/0x6b [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= saslauthd S f1bcdf40 0 11113 11109 f1bcdf54 00200082 00000002 f1bcdf40 f1bcdf38 00000000 c19ce570 c19ce6b0 c180ae00 00000000 0000d5f6 000000ff 00000000 00200246 c012deee f5d65bfc f7e1e4c0 f1bcdf7c 00000007 c016f23f 00000000 00000007 0000001c 00000000 Call Trace: [] prepare_to_wait+0x12/0x4b [] fcntl_setlk+0x14f/0x1cf [] autoremove_wake_function+0x0/0x33 [] sys_fcntl64+0x5a/0x6b [] sysenter_past_esp+0x6b/0xa1 ======================= sshd S c1807dc0 0 11130 1 f1427b40 00200086 0001731b c1807dc0 00000002 f1427b28 f7fcd570 f7fcd6b0 c180ae00 00000000 00022be7 000000ff 00000000 00000000 0001731b 7fffffff f1427f9c 00000006 00000040 c0267af3 f7586eb0 e8bea280 00200246 c012dfc8 Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] add_wait_queue+0xf/0x30 [] pipe_poll+0x24/0x7b [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] tcp_v4_do_rcv+0x2d9/0x323 [] nf_ct_deliver_cached_events+0x3e/0x91 [nf_conntrack] [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] tcp_v4_rcv+0x7f2/0x850 [] ip_local_deliver+0x189/0x230 [] ip_local_deliver_finish+0x0/0x1b1 [] ip_rcv+0x499/0x4d3 [] ip_rcv_finish+0x0/0x2a8 [] update_curr+0x103/0x12a [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] check_preempt_curr_fair+0x69/0x6f [] try_to_wake_up+0x2b0/0x2ba [] cache_alloc_refill+0x64/0x487 [] __alloc_skb+0x42/0xec [] sock_alloc_send_skb+0x6e/0x196 [] core_sys_select+0x1dd/0x283 [] flush_tlb_page+0x3d/0x61 [] handle_mm_fault+0x67f/0x6f9 [] do_sync_write+0xc7/0x10a [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_select+0x9d/0x167 [] filp_close+0x4f/0x56 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= ulogd S f152fd00 0 11143 1 f152fd14 00000082 00000002 f152fd00 f152fcf8 00000000 c19d8ab0 c19d8bf0 c180ae00 00000000 ffffa1f1 000000ff 00000000 00000001 00000000 7fffffff dfe2e000 00000000 7fffffff c0267af3 f6f219e8 00008000 00000000 00000c8c Call Trace: [] schedule_timeout+0x13/0x8d [] __ext3_journal_stop+0x19/0x34 [ext3] [] prepare_to_wait_exclusive+0x12/0x4a [] skb_recv_datagram+0x115/0x172 [] autoremove_wake_function+0x0/0x33 [] netlink_recvmsg+0x44/0x219 [] sock_recvmsg+0xcf/0xe8 [] __generic_file_aio_write_nolock+0x481/0x4c3 [] autoremove_wake_function+0x0/0x33 [] __do_fault+0x30e/0x33b [] generic_file_aio_write+0x5b/0xb0 [] sys_recvfrom+0xd7/0x12b [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] sys_socketcall+0x1cd/0x262 [] sysenter_past_esp+0x6b/0xa1 ======================= ntpd S c1807dc0 0 11257 1 f1117b40 00200082 0001731b c1807dc0 00000002 f1117b28 f1bdf030 f1bdf170 c180ae00 00000000 00023087 000000ff 00000000 00000000 0001731b 7fffffff f1117f9c 00000009 00000200 c0267af3 00200246 c012dfc8 f1b0d580 f1117bdc Call Trace: [] schedule_timeout+0x13/0x8d [] add_wait_queue+0xf/0x30 [] datagram_poll+0x14/0xad [] udp_poll+0xe/0xd3 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] __ext3_get_inode_loc+0x117/0x2dd [ext3] [] __ext3_journal_dirty_metadata+0x15/0x3b [ext3] [] ext3_mark_iloc_dirty+0x27e/0x2d9 [ext3] [] ext3_mark_inode_dirty+0x20/0x27 [ext3] [] __wake_up+0x32/0x43 [] journal_stop+0x1af/0x1bb [jbd] [] __ext3_journal_stop+0x19/0x34 [ext3] [] ext3_ordered_commit_write+0xb4/0xc3 [ext3] [] ext3_journal_dirty_data+0x0/0x31 [ext3] [] generic_file_buffered_write+0x4cd/0x59c [] __ext3_journal_stop+0x19/0x34 [ext3] [] __mark_inode_dirty+0x24/0x143 [] __generic_file_aio_write_nolock+0x481/0x4c3 [] core_sys_select+0x1dd/0x283 [] enqueue_hrtimer+0xdc/0xe7 [] hrtimer_start+0xe5/0xef [] convert_fxsr_to_user+0xe2/0x12e [] save_i387+0x121/0x133 [] setup_sigcontext+0xdd/0x117 [] recalc_sigpending+0xb/0x1d [] do_notify_resume+0x4fa/0x5ef [] convert_fxsr_from_user+0x15/0xd2 [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= mdadm S f1081b2c 0 11272 1 f1081b40 00000086 00000002 f1081b2c f1081b24 00000000 f1ba7ab0 f1ba7bf0 c180ae00 00000000 f1081b50 00000282 c01258f2 00000000 00000282 f1081b50 00024319 00000005 00000020 c0267b50 c01821f7 c017efdf c0363fa4 e2d83db0 Call Trace: [] __mod_timer+0x97/0xa1 [] schedule_timeout+0x70/0x8d [] mpage_end_io_read+0x0/0x61 [] bio_endio+0x5b/0x63 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] __add_entropy_words+0x5b/0x176 [] __wake_up+0x32/0x43 [] scsi_run_queue+0x17a/0x189 [scsi_mod] [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] __wake_up+0x32/0x43 [] md_wakeup_thread+0x24/0x26 [md_mod] [] md_ioctl+0x11d1/0x1213 [md_mod] [] enqueue_entity+0x1e2/0x203 [] core_sys_select+0x1dd/0x283 [] blkdev_driver_ioctl+0x54/0x5d [] check_disk_change+0x14/0x5a [] md_open+0x49/0x50 [md_mod] [] do_open+0x1d1/0x240 [] may_open+0x4e/0x194 [] blkdev_open+0x0/0x51 [] blkdev_open+0x25/0x51 [] __dentry_open+0xdd/0x16a [] nameidata_to_filp+0x23/0x32 [] do_filp_open+0x32/0x39 [] sys_select+0x9d/0x167 [] mntput_no_expire+0x11/0x5d [] filp_close+0x4f/0x56 [] sysenter_past_esp+0x6b/0xa1 ======================= dhcpd3 S f0df7b2c 0 11290 1 f0df7b40 00000086 00000002 f0df7b2c f0df7b24 00000000 f2003570 f20036b0 c180ae00 00000000 0001b069 000000ff 00000000 00000000 00000000 f0df7b50 007a0069 00000008 00000100 c0267b50 00000246 c012dfc8 c03643c4 c03643c4 Call Trace: [] schedule_timeout+0x70/0x8d [] add_wait_queue+0xf/0x30 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] dx_probe+0x95/0x2d2 [ext3] [] ifind_fast+0x2a/0x69 [] ext3_get_acl+0x51/0x2bf [ext3] [] __wake_up_common+0x32/0x55 [] memcpy_toiovec+0x25/0x47 [] skb_copy_datagram_iovec+0x53/0x1cd [] skb_dequeue+0x39/0x3f [] skb_recv_datagram+0x6b/0x172 [] __kfree_skb+0xa3/0xfa [] udp_recvmsg+0x184/0x1d1 [] sock_common_recvmsg+0x3e/0x54 [] sock_recvmsg+0xcf/0xe8 [] autoremove_wake_function+0x0/0x33 [] core_sys_select+0x1dd/0x283 [] move_addr_to_user+0x4e/0x66 [] sys_recvfrom+0x108/0x12b [] cp_new_stat64+0xf3/0x105 [] do_page_fault+0x0/0x63d [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= atd S f0bbbf14 0 11307 1 f0bbbf28 00000086 00000002 f0bbbf14 f0bbbf0c 00000000 f1576ab0 f1576bf0 c1813e00 00000001 ffff9c29 000000ff 00000000 00000000 00000000 f0bbbf40 00000001 00000001 bfe9c124 c0267ee0 00000001 00000000 bfe9c124 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= cron S c1807dc0 0 11317 1 f0bf1f28 00000086 0001731b c1807dc0 00000002 f0bf1f10 f1576570 f15766b0 c180ae00 00000000 00021e93 000000ff 00000000 00000000 0001731b f0bf1f40 00000001 00000001 bfec71b4 c0267ee0 00000001 00000000 bfec71b4 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sigprocmask+0xa1/0xc4 [] sys_nanosleep+0x49/0x5c [] sysenter_past_esp+0x6b/0xa1 ======================= apache2 S c1807dc0 0 11343 1 f0159b40 00200086 0001731b c1807dc0 00000002 f0159b28 f1463ab0 f1463bf0 c180ae00 00000000 00023054 000000ff 00000000 00000000 0001731b f0159b50 000230b7 00000000 dffbabcc c0267b50 dffbabcc c0103267 c0363d44 c0363d44 Call Trace: [] schedule_timeout+0x70/0x8d [] common_interrupt+0x23/0x28 [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] rb_insert_color+0x8a/0xad [] enqueue_entity+0x1e2/0x203 [] __check_preempt_curr_fair+0x4c/0x71 [] mempool_free+0x68/0x6d [] bio_put+0x23/0x24 [] mpage_end_io_read+0x5b/0x61 [] mpage_end_io_read+0x0/0x61 [] bio_endio+0x5b/0x63 [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] tcp_packet+0xa09/0xa1b [nf_conntrack] [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] e1000_xmit_frame+0x995/0x9be [e1000] [] __wake_up+0x32/0x43 [] packet_rcv+0x2bd/0x307 [af_packet] [] packet_rcv+0x0/0x307 [af_packet] [] dev_hard_start_xmit+0x200/0x275 [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] core_sys_select+0x1dd/0x283 [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_forward+0x275/0x2d2 [] ip_forward_finish+0x0/0x2e [] ip_rcv+0x499/0x4d3 [] ip_rcv_finish+0x0/0x2a8 [] __alloc_skb+0x42/0xec [] rhine_napipoll+0x42b/0x435 [via_rhine] [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] remove_wait_queue+0xc/0x34 [] do_wait+0x970/0x9da [] sys_select+0x9d/0x167 [] sysenter_past_esp+0x6b/0xa1 ======================= getty S 00000008 0 11361 1 f01f9ec0 00000082 00000020 00000008 0000000a c00bc434 f1570570 f15706b0 c180ae00 00000000 00000000 010000c0 f01f0000 c02da200 00000246 7fffffff f7ee8800 f01f9f3c bf824cbb c0267af3 c014a460 c15fb7c0 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] vgacon_set_cursor_size+0xeb/0x103 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= getty S c1810dc0 0 11362 1 f0479ec0 00000086 00000600 c1810dc0 00000002 f0479ea8 f18e5030 f18e5170 c1813e00 00000001 ffff9d1f 000000ff 00000000 00000000 00000600 7fffffff f72b9800 f0479f3c bf8a9d3b c0267af3 c014a460 c15fa720 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= getty S c1807dc0 0 11363 1 f05c9ec0 00000082 00000400 c1807dc0 00000002 f05c9ea8 c19c8030 c19c8170 c180ae00 00000000 ffff9d1f 000000ff 00000000 00000000 00000400 7fffffff f7266800 f05c9f3c bfa486db c0267af3 c014a460 c15fb7c0 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= getty S c1810dc0 0 11364 1 f049bec0 00000086 00000400 c1810dc0 00000002 f049bea8 dffdc570 dffdc6b0 c1813e00 00000001 ffff9d1f 000000ff 00000000 00000000 00000400 7fffffff f72dc000 f049bf3c bfd7da0b c0267af3 c014a460 c15fa720 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= getty S 00000008 0 11365 1 f0bfbec0 00000086 00000020 00000008 ffffffff 00000000 f1576030 f1576170 c1813e00 00000001 00000000 01000020 f0bf0000 c02da200 00000246 7fffffff f72b9000 f0bfbf3c bfd7da0b c0267af3 c014a460 c15fa720 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= getty S 00000008 0 11366 1 f060dec0 00000082 00000020 00000008 ffffffff 00000000 c192eab0 c192ebf0 c1813e00 00000001 00000000 01000020 f0600000 c02da200 00000246 7fffffff f6cc1000 f060df3c bfd7da0b c0267af3 c014a460 c15fa720 002da200 c02da200 Call Trace: [] schedule_timeout+0x13/0x8d [] __pagevec_free+0x18/0x22 [] release_pages+0x14e/0x156 [] release_console_sem+0x17a/0x193 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= runsvdir S c1807dc0 0 11367 1 f025bbe4 00000086 0001731b c1807dc0 00000002 f025bbcc c19ce030 c19ce170 c180ae00 00000000 00023002 000000ff 00000000 00000000 0001731b f025bbf4 000231f7 000001f6 00000000 c0267b50 00000c31 00000c31 c0364114 f682fb50 Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_sys_poll+0x25d/0x323 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] io_schedule+0x1d/0x27 [] __wait_on_bit+0x4e/0x56 [] sync_buffer+0x0/0x33 [] sync_buffer+0x0/0x33 [] out_of_line_wait_on_bit+0x63/0x6b [] wake_bit_function+0x0/0x3c [] ext3_find_entry+0x457/0x52f [ext3] [] ata_qc_issue_prot+0xe6/0x21c [libata] [] ifind_fast+0x2a/0x69 [] inotify_d_instantiate+0x41/0x66 [] d_rehash+0x1c/0x29 [] d_splice_alias+0x9b/0xb6 [] __d_lookup+0x96/0xd5 [] do_lookup+0x4f/0x140 [] dput+0x15/0xdd [] __link_path_walk+0x987/0xaa6 [] scsi_request_fn+0x2eb/0x326 [scsi_mod] [] mntput_no_expire+0x11/0x5d [] link_path_walk+0xa9/0xb3 [] do_wait+0x970/0x9da [] do_path_lookup+0x161/0x1c4 [] _atomic_dec_and_lock+0x2a/0x44 [] mntput_no_expire+0x11/0x5d [] cp_new_stat+0x154/0x16d [] sys_newstat+0x23/0x28 [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sys_poll+0x33/0x36 [] sysenter_past_esp+0x6b/0xa1 ======================= runsv S f02e7bd0 0 11378 11367 f02e7be4 00000082 00000002 f02e7bd0 f02e7bc8 00000000 dffdaab0 dffdabf0 c180ae00 00000000 000123a2 000000ff 00000000 00000001 00000000 f02e7bf4 0002aa43 000186a2 00000000 c0267b50 f76eeec0 f8bea851 f2799b50 c03641dc Call Trace: [] schedule_timeout+0x70/0x8d [] xfs_icsb_modify_counters+0x53/0x1cd [xfs] [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_sys_poll+0x25d/0x323 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] xfs_buf_rele+0x23/0x6c [xfs] [] xfs_trans_unlock_chunk+0x79/0xb9 [xfs] [] xfs_trans_tail_ail+0x13/0x2b [xfs] [] xlog_assign_tail_lsn+0x1d/0x3e [xfs] [] xlog_state_release_iclog+0x18/0x91 [xfs] [] xfs_log_release_iclog+0xf/0x38 [xfs] [] _xfs_trans_commit+0x278/0x2e0 [xfs] [] activate_page+0x81/0xa6 [] mark_page_accessed+0x1c/0x30 [] filemap_fault+0x227/0x387 [] xfs_ifree+0x96/0xc1 [xfs] [] xfs_trans_unlocked_item+0x25/0x3c [xfs] [] __do_fault+0x30e/0x33b [] xfs_reclaim+0xd1/0xd8 [xfs] [] pipe_read+0x2e4/0x343 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] remove_wait_queue+0xc/0x34 [] do_gettimeofday+0x35/0xfe [] recalc_sigpending+0xb/0x1d [] sigprocmask+0xa1/0xc4 [] sys_poll+0x33/0x36 [] sysenter_past_esp+0x6b/0xa1 ======================= multilog S efc83e48 0 11379 11378 efc83e5c 00000086 00000002 efc83e48 efc83e40 00000000 f1463570 f14636b0 c180ae00 00000000 ffff9f1d 000000ff 00000000 00000000 00000000 f789e400 f789e400 efc83e78 dfd360c0 c0166f4a 00000000 f1463570 c012dd98 f789e404 Call Trace: [] pipe_wait+0x51/0x6f [] autoremove_wake_function+0x0/0x33 [] pipe_read+0x2cf/0x343 [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_sync_read+0x0/0x10a [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= mlnet D 00000000 0 11380 11378 efcfdc3c 00000086 00000008 00000000 efcfdc88 00000000 f16b2ab0 f16b2bf0 c180ae00 00000000 f7dfec40 0a93c293 00000000 00000000 f72cc980 f7364e80 00000246 f7364e88 f16b2ab0 c02688a4 00000001 f16b2ab0 c011a320 f7364e8c Call Trace: [] __down+0xc2/0xd4 [] default_wake_function+0x0/0xc [] __down_failed+0x7/0xc [] xfs_buf_lock+0x31/0x33 [xfs] [] xfs_getsb+0x22/0x2d [xfs] [] xfs_trans_getsb+0x37/0x68 [xfs] [] xfs_trans_apply_sb_deltas+0x12/0x3ff [xfs] [] _xfs_trans_commit+0xf1/0x2e0 [xfs] [] xfs_dir2_leaf_addname+0x77b/0x792 [xfs] [] xfs_dir_createname+0xf5/0x106 [xfs] [] __mark_inode_dirty+0xca/0x143 [] xfs_create+0x491/0x615 [xfs] [] xfs_iunlock+0x51/0x6d [xfs] [] xfs_vn_create+0x0/0xd [xfs] [] xfs_vn_mknod+0x182/0x28f [xfs] [] xfs_vn_create+0x0/0xd [xfs] [] vfs_create+0x73/0xe1 [] open_namei+0x173/0x54c [] do_filp_open+0x25/0x39 [] get_unused_fd_flags+0x51/0xc3 [] do_sys_open+0x44/0xc0 [] sys_open+0x1a/0x1c [] syscall_call+0x7/0xb ======================= apache2 S c1807dc0 0 11384 11343 ef3b3e28 00200082 00000600 c1807dc0 00000002 ef3b3e10 f156f030 f156f170 c180ae00 00000000 ffff9d52 000000ff 00000000 00000000 00000600 7fffffff 7fffffff ef3b3e98 ef3b3ebc c0267af3 c19f2208 00200282 00000000 00000000 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] __alloc_pages+0x5b/0x2a4 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= apache2 S c02db5d0 0 11385 11343 ef3b5e28 00200082 000a00d2 c02db5d0 00000000 f04f8844 f2003ab0 f2003bf0 c180ae00 00000000 f04f8844 f04f8844 00000000 c014778a c15da380 7fffffff 7fffffff ef3b5e98 ef3b5ebc c0267af3 c19f2208 00200282 00000000 00000000 Call Trace: [] filemap_fault+0x227/0x387 [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] __alloc_pages+0x5b/0x2a4 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= apache2 S eec33e14 0 11386 11343 eec33e28 00200086 00000002 eec33e14 eec33e0c 00000000 f156fab0 f156fbf0 c180ae00 00000000 ffff9d52 000000ff 00000000 00000000 00000000 7fffffff 7fffffff eec33e98 eec33ebc c0267af3 c19f2208 00200282 00000000 00000000 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] __alloc_pages+0x5b/0x2a4 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= apache2 S c1807dc0 0 11387 11343 eec53e28 00200086 00000400 c1807dc0 00000002 eec53e10 f7ef3570 f7ef36b0 c180ae00 00000000 ffff9d52 000000ff 00000000 00000000 00000400 7fffffff 7fffffff eec53e98 eec53ebc c0267af3 c19f2208 00200282 00000000 00000000 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] __alloc_pages+0x5b/0x2a4 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= apache2 S eecb3e14 0 11388 11343 eecb3e28 00200086 00000002 eecb3e14 eecb3e0c 00000000 f156f570 f156f6b0 c180ae00 00000000 ffff9d52 000000ff 00000000 00000001 00000000 7fffffff 7fffffff eecb3e98 eecb3ebc c0267af3 00000010 00200282 c02da200 00200286 Call Trace: [] schedule_timeout+0x13/0x8d [] _spin_lock_bh+0x8/0x18 [] lock_sock_nested+0x84/0x8c [] init_once+0x0/0x8 [] cache_alloc_refill+0x64/0x487 [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] inet_csk_accept+0x97/0x1e0 [] autoremove_wake_function+0x0/0x33 [] inet_accept+0x1f/0xa1 [] sock_attach_fd+0x52/0xae [] sys_accept+0xd8/0x1ad [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] do_page_fault+0x2ed/0x63d [] sys_socketcall+0xd6/0x262 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= mlnet S c1807dc0 0 11392 11380 ec1f9be4 00000086 0001731b c1807dc0 00000002 ec1f9bcc f1570ab0 f1570bf0 c180ae00 00000000 00023027 000000ff 00000000 00000000 0001731b ec1f9bf4 000230ee 000000c8 00000000 c0267b50 ec1f9c54 00000000 c0363efc c0363efc Call Trace: [] schedule_timeout+0x70/0x8d [] process_timeout+0x0/0x5 [] schedule_timeout+0x6b/0x8d [] do_sys_poll+0x25d/0x323 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] __next_cpu+0x12/0x1f [] find_busiest_group+0x1c5/0x560 [] __switch_to+0x104/0x126 [] schedule+0x453/0x511 [] enqueue_entity+0x1e2/0x203 [] inc_nr_running+0x13/0x24 [] try_to_wake_up+0x2b0/0x2ba [] signal_wake_up+0x1e/0x2c [] __group_send_sig_info+0x72/0x7d [] group_send_sig_info+0x4c/0x54 [] kill_pid_info+0x3e/0x4e [] rhine_interrupt+0x64b/0x6a8 [via_rhine] [] pdc_interrupt+0x68/0x308 [sata_promise] [] __kfree_skb+0xa3/0xfa [] net_tx_action+0x71/0xf0 [] irq_exit+0x53/0x6b [] do_IRQ+0x5c/0x71 [] irq_exit+0x53/0x6b [] sys_poll+0x33/0x36 [] syscall_call+0x7/0xb ======================= mlnet S c1807dc0 0 11393 11392 ec1fbf28 00000086 0001731b c1807dc0 00000002 ec1fbf10 f14b0570 f14b06b0 c180ae00 00000000 0002301e 000000ff 00000000 00000000 0001731b ec1fbf40 00000001 00000001 00000000 c0267ee0 00000001 00000000 4703fca9 c0130d65 Call Trace: [] do_nanosleep+0x46/0x71 [] hrtimer_nanosleep+0x39/0xdc [] hrtimer_wakeup+0x0/0x18 [] do_nanosleep+0x3b/0x71 [] sys_nanosleep+0x49/0x5c [] syscall_call+0x7/0xb ======================= sshd S c1813e84 0 11394 11130 eaf57b40 00000086 4fe738eb c1813e84 4d84deeb 0000000a f1bdf570 f1bdf6b0 c1813e00 00000001 c02e09b0 00400000 c02e09b0 00000000 00000001 7fffffff eaf57f9c 00000009 00000200 c0267af3 00000086 f75be00c 00000286 f7dccc40 Call Trace: [] schedule_timeout+0x13/0x8d [] tty_ldisc_deref+0x53/0x62 [] tty_poll+0x52/0x5f [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] __qdisc_run+0x94/0x15a [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_queue_xmit+0x309/0x34b [] dst_output+0x0/0x7 [] update_curr+0x103/0x12a [] tcp_transmit_skb+0x624/0x64b [] lock_timer_base+0x19/0x35 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] tcp_sendmsg+0x906/0x9e0 [] __wake_up+0x32/0x43 [] core_sys_select+0x1dd/0x283 [] sock_aio_write+0xc8/0xd4 [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] sys_select+0x9d/0x167 [] vfs_write+0xfb/0x10b [] sys_write+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= bash S ea917f28 0 11398 11394 ea917f3c 00000082 00000002 ea917f28 ea917f20 00000000 dffce570 dffce6b0 c180ae00 00000000 0000ba07 000000ff 00000000 00000000 00000000 f14b0ab0 00000001 dffce570 00000000 c0121237 00000000 00000000 00000001 f75b0600 Call Trace: [] do_wait+0x926/0x9da [] default_wake_function+0x0/0xc [] sys_wait4+0x30/0x33 [] sys_waitpid+0x27/0x2b [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= sshd S c180ae84 0 11422 11130 f6d45b40 00000082 c01aaaea c180ae84 ab45db34 00000014 c19c1570 c19c16b0 c180ae00 00000000 c02e09b0 00200000 c02e09b0 00000000 00000001 7fffffff f6d45f9c 00000009 00000200 c0267af3 00000086 f75a000c 00000286 f7fb47c0 Call Trace: [] rb_insert_color+0x8a/0xad [] schedule_timeout+0x13/0x8d [] tty_ldisc_deref+0x53/0x62 [] tty_poll+0x52/0x5f [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] __qdisc_run+0x94/0x15a [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_queue_xmit+0x309/0x34b [] dst_output+0x0/0x7 [] update_curr+0x103/0x12a [] tcp_transmit_skb+0x624/0x64b [] lock_timer_base+0x19/0x35 [] __mod_timer+0x97/0xa1 [] sk_reset_timer+0xc/0x16 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] tcp_sendmsg+0x906/0x9e0 [] __check_preempt_curr_fair+0x4c/0x71 [] core_sys_select+0x1dd/0x283 [] sock_aio_write+0xc8/0xd4 [] autoremove_wake_function+0x13/0x33 [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] sys_select+0x9d/0x167 [] vfs_write+0xfb/0x10b [] sys_write+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= bash R running 0 11426 11422 xfs_fsr S eeeb9f3c 0 11442 11398 eeeb9f50 00000082 00000002 eeeb9f3c eeeb9f34 00000000 f14b0ab0 f14b0bf0 c1813e00 00000001 0000ba0b 000000ff 00000000 00000000 00000000 f14b0030 00000001 f14b0ab0 00000000 c0121237 f14b0ab0 f7ef1040 f3259d24 c02676e9 Call Trace: [] do_wait+0x926/0x9da [] schedule+0x453/0x511 [] default_wake_function+0x0/0xc [] sys_wait4+0x30/0x33 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= xfs_fsr D f7f45648 0 11443 11442 eee99c10 00000086 f7f45648 f7f45648 00000001 00000092 f14b0030 f14b0170 c180ae00 00000000 f70c31cc 00000000 f70c31cc 00000000 00000001 eee99c50 eee99c54 eee99c2c eee99c38 c0267a94 00000001 f14b0030 c011a320 eee99c58 Call Trace: [] wait_for_completion+0x6b/0xa8 [] default_wake_function+0x0/0xc [] flush_cpu_workqueue+0x64/0x6c [] wq_barrier_func+0x0/0x8 [] flush_workqueue+0x2b/0x3f [] xfs_end_io_direct+0x50/0x5a [xfs] [] xfs_end_io_direct+0x0/0x5a [xfs] [] dio_complete+0x90/0xc8 [] __blockdev_direct_IO+0xacf/0xb3a [] xfs_iomap+0x4c7/0x4e6 [xfs] [] xfs_vm_direct_IO+0x116/0x135 [xfs] [] xfs_get_blocks_direct+0x0/0x2d [xfs] [] xfs_end_io_direct+0x0/0x5a [xfs] [] raid5_congested+0x0/0x32 [raid456] [] file_read_actor+0x77/0xc7 [] generic_file_direct_IO+0xd8/0x108 [] generic_file_direct_write+0x55/0x11f [] current_fs_time+0x13/0x15 [] xfs_write+0x61c/0xa3a [xfs] [] xfs_file_aio_write+0x72/0x7a [xfs] [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] do_sync_write+0x0/0x10a [] vfs_write+0x89/0x10b [] sys_write+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= sshd S d6b2bda8 0 11448 11130 d6b2bdbc 00000086 00000002 d6b2bda8 d6b2bda0 00000000 f1ba7570 f1ba76b0 c180ae00 00000000 00017b7b 000000ff 00000000 00000000 00000000 7fffffff f7f3e300 d6b2be48 f7f3e49c c0267af3 d6b2be14 d6b2be08 d6b2bf30 dfc27b40 Call Trace: [] schedule_timeout+0x13/0x8d [] dput+0x15/0xdd [] __link_path_walk+0x987/0xaa6 [] prepare_to_wait+0x12/0x4b [] unix_stream_recvmsg+0x1fe/0x454 [] autoremove_wake_function+0x0/0x33 [] sock_aio_read+0xd1/0xdd [] do_path_lookup+0x161/0x1c4 [] do_sync_read+0xc7/0x10a [] chrdev_open+0x126/0x13a [] autoremove_wake_function+0x0/0x33 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= sshd S c1807dc0 0 11452 11448 e5481b40 00000086 0001731b c1807dc0 00000002 e5481b28 f18e5570 f18e56b0 c180ae00 00000000 0001e966 000000ff 00000000 00000000 0001731b 7fffffff e5481f9c 0000000b 00000800 c0267af3 00000086 f6de480c 00000286 f7dccd40 Call Trace: [] schedule_timeout+0x13/0x8d [] tty_ldisc_deref+0x53/0x62 [] tty_poll+0x52/0x5f [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] ipv4_confirm+0x36/0x3b [nf_conntrack_ipv4] [] __qdisc_run+0x94/0x15a [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_queue_xmit+0x309/0x34b [] dst_output+0x0/0x7 [] dst_output+0x0/0x7 [] tcp_transmit_skb+0x624/0x64b [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] tcp_sendmsg+0x906/0x9e0 [] __check_preempt_curr_fair+0x4c/0x71 [] core_sys_select+0x1dd/0x283 [] sock_aio_write+0xc8/0xd4 [] autoremove_wake_function+0x13/0x33 [] do_sync_write+0xc7/0x10a [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] sys_select+0x9d/0x167 [] vfs_write+0xfb/0x10b [] sys_write+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= bash S 00200286 0 11453 11452 ca76bec0 00200082 00000000 00200286 c01e4cf2 bfaba38c f1ba7030 f1ba7170 c180ae00 00000000 0a775065 c114ee2c ca771be8 b7efafcc c0152b45 7fffffff cc4b8000 ca76bf3c bfaba34f c0267af3 0a775065 c017131b 00200206 00000001 Call Trace: [] tty_ioctl+0xb06/0xb3f [] handle_mm_fault+0x67f/0x6f9 [] schedule_timeout+0x13/0x8d [] destroy_inode+0x24/0x33 [] add_wait_queue+0xf/0x30 [] read_chan+0x333/0x579 [] default_wake_function+0x0/0xc [] tty_ldisc_deref+0x53/0x62 [] read_chan+0x0/0x579 [] tty_read+0x6f/0xad [] tty_read+0x0/0xad [] vfs_read+0x87/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 ======================= rm D efd9fc6c 0 12377 1 efd9fc80 00200082 00000002 efd9fc6c efd9fc64 00000000 f7f72570 f7f726b0 c180ae00 00000000 0001b48f 000000ff 00000000 00000001 00000000 f76eeec0 00200246 f76eeec8 f7f72570 c02688a4 00000001 f7f72570 c011a320 f735fc94 Call Trace: [] __down+0xc2/0xd4 [] default_wake_function+0x0/0xc [] __down_failed+0x7/0xc [] xlog_state_get_iclog_space+0x5e/0x16c [xfs] [] xlog_write+0x17d/0x4a9 [xfs] [] xfs_log_write+0x41/0x6b [xfs] [] _xfs_trans_commit+0x17d/0x2e0 [xfs] [] xfs_trans_log_inode+0x14/0x2e [xfs] [] xfs_remove+0x372/0x4a7 [xfs] [] xfs_vn_unlink+0x17/0x3b [xfs] [] link_path_walk+0xa9/0xb3 [] xfs_trans_unlocked_item+0x25/0x3c [xfs] [] xfs_access+0x34/0x3a [xfs] [] xfs_vn_permission+0xf/0x13 [xfs] [] xfs_vn_permission+0x0/0x13 [xfs] [] permission+0x86/0xa2 [] may_delete+0x50/0x103 [] vfs_unlink+0x47/0x70 [] do_unlinkat+0x97/0xfd [] irq_exit+0x53/0x6b [] do_IRQ+0x5c/0x71 [] irq_exit+0x53/0x6b [] smp_apic_timer_interrupt+0x70/0x7c [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= sshd S c1807dc0 0 12494 11130 d70c7dbc 00000082 0001731b c1807dc0 00000002 d70c7da4 d5301570 d53016b0 c180ae00 00000000 000230a7 000000ff 00000000 00000000 0001731b 7fffffff dff7c880 d70c7e48 dff7ca1c c0267af3 c012ddab 00000000 d70cde34 e2638e1c Call Trace: [] schedule_timeout+0x13/0x8d [] autoremove_wake_function+0x13/0x33 [] __wake_up_common+0x32/0x55 [] prepare_to_wait+0x12/0x4b [] unix_stream_recvmsg+0x1fe/0x454 [] autoremove_wake_function+0x0/0x33 [] sock_aio_read+0xd1/0xdd [] do_sync_read+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] update_curr+0x103/0x12a [] update_stats_wait_end+0x9b/0xbe [] __switch_to+0xa2/0x126 [] vfs_read+0x9b/0x109 [] sys_read+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= sshd S 080aeb18 0 12497 12494 d70cdb40 00000086 00000000 080aeb18 00000000 00000000 e577a570 e577a6b0 c180ae00 00000000 00000000 00000000 c0268ab9 02932e00 f8b8fb7a 7fffffff d70cdf9c 00000004 00000010 c0267af3 eafcf4f8 f8b92ff9 00000246 c012dfc8 Call Trace: [] _write_lock_bh+0x8/0x1a [] __nf_ct_refresh_acct+0xdd/0x118 [nf_conntrack] [] schedule_timeout+0x13/0x8d [] tcp_packet+0xa09/0xa1b [nf_conntrack] [] add_wait_queue+0xf/0x30 [] tcp_poll+0x18/0x120 [] do_select+0x3a1/0x3f7 [] __pollwait+0x0/0xac [] default_wake_function+0x0/0xc [] getnstimeofday+0x35/0xe9 [] rhine_start_tx+0x1d8/0x249 [via_rhine] [] dev_hard_start_xmit+0x200/0x275 [] __qdisc_run+0x94/0x15a [] dev_queue_xmit+0x289/0x2ae [] ip_output+0x276/0x2b1 [] ip_finish_output+0x0/0x218 [] ip_queue_xmit+0x309/0x34b [] dst_output+0x0/0x7 [] update_curr+0x103/0x12a [] tcp_v4_send_check+0x86/0xbc [] tcp_transmit_skb+0x624/0x64b [] __switch_to+0xa2/0x126 [] lock_timer_base+0x19/0x35 [] __mod_timer+0x97/0xa1 [] sk_reset_timer+0xc/0x16 [] __tcp_push_pending_frames+0x6f9/0x79e [] _spin_lock_bh+0x8/0x18 [] release_sock+0x10/0x8b [] tcp_sendmsg+0x906/0x9e0 [] __alloc_pages+0x5b/0x2a4 [] core_sys_select+0x1dd/0x283 [] sock_aio_write+0xc8/0xd4 [] do_sync_write+0xc7/0x10a [] autoremove_wake_function+0x0/0x33 [] do_page_fault+0x0/0x63d [] sys_select+0x9d/0x167 [] vfs_write+0xfb/0x10b [] sys_write+0x41/0x67 [] sysenter_past_esp+0x6b/0xa1 [] xfrm_policy_insert+0x2d3/0x342 ======================= --nextPart1831028.3B4dx51t4S-- From owner-xfs@oss.sgi.com Wed Oct 3 15:27:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 15:27:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-8.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_66,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.0-r574664 Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l93MRLGg030154 for ; Wed, 3 Oct 2007 15:27:23 -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 258A2150E1 for ; Thu, 4 Oct 2007 00:27:21 +0200 (CEST) From: Andi Kleen Organization: SUSE Linux Products GmbH, Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) To: xfs@oss.sgi.com Subject: [PATCH] XFS bitops to Linux again Date: Thu, 4 Oct 2007 00:27:16 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710040027.16926.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13240 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 This time against CVS Replace XFS bit functions with call Linux functions XFS had some own functions to find high and low bits. This patch replaces them with a call to the respective Linux functions. The semantics of the Linux functions differ a little, but i checked all call sites that they can deal with that. The resulting xfs.ko is about 500 bytes smaller on x86-64 Signed-off-by: Andi Kleen Index: linux-2.6-xfs/fs/xfs/xfs_bit.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bit.c +++ linux-2.6-xfs/fs/xfs/xfs_bit.c @@ -22,112 +22,9 @@ #include "xfs_buf_item.h" /* - * XFS bit manipulation routines, used in non-realtime code. + * XFS bit manipulation routines */ -#ifndef HAVE_ARCH_HIGHBIT -/* - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. - */ -static const char xfs_highbit[256] = { - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ -}; -#endif - -/* - * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. - */ -inline int -xfs_highbit32( - __uint32_t v) -{ -#ifdef HAVE_ARCH_HIGHBIT - return highbit32(v); -#else - int i; - - if (v & 0xffff0000) - if (v & 0xff000000) - i = 24; - else - i = 16; - else if (v & 0x0000ffff) - if (v & 0x0000ff00) - i = 8; - else - i = 0; - else - return -1; - return i + xfs_highbit[(v >> i) & 0xff]; -#endif -} - -/* - * xfs_lowbit64: get low bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_lowbit64( - __uint64_t v) -{ - __uint32_t w = (__uint32_t)v; - int n = 0; - - if (w) { /* lower bits */ - n = ffs(w); - } else { /* upper bits */ - w = (__uint32_t)(v >> 32); - if (w && (n = ffs(w))) - n += 32; - } - return n - 1; -} - -/* - * xfs_highbit64: get high bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_highbit64( - __uint64_t v) -{ - __uint32_t h = (__uint32_t)(v >> 32); - - if (h) - return xfs_highbit32(h) + 32; - return xfs_highbit32((__uint32_t)v); -} - - /* * Return whether bitmap is empty. * Size is number of words in the bitmap, which is padded to word boundary Index: linux-2.6-xfs/fs/xfs/xfs_bit.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bit.h +++ linux-2.6-xfs/fs/xfs/xfs_bit.h @@ -46,15 +46,6 @@ static inline __uint64_t xfs_mask64lo(in return ((__uint64_t)1 << (n)) - 1; } -/* Get high bit set out of 32-bit argument, -1 if none set */ -extern int xfs_highbit32(__uint32_t v); - -/* Get low bit set out of 64-bit argument, -1 if none set */ -extern int xfs_lowbit64(__uint64_t v); - -/* Get high bit set out of 64-bit argument, -1 if none set */ -extern int xfs_highbit64(__uint64_t); - /* Return whether bitmap is empty (1 == empty) */ extern int xfs_bitmap_empty(uint *map, uint size); Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c +++ linux-2.6-xfs/fs/xfs/xfs_mount.c @@ -479,7 +479,7 @@ xfs_sb_to_disk( return; while (fields) { - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields,64); first = xfs_sb_info[f].offset; size = xfs_sb_info[f + 1].offset - first; @@ -621,7 +621,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; mp->m_sectbb_log = sbp->sb_sectlog - BBSHIFT; - mp->m_agno_log = xfs_highbit32(sbp->sb_agcount - 1) + 1; + mp->m_agno_log = fls(sbp->sb_agcount - 1); mp->m_agino_log = sbp->sb_inopblog + sbp->sb_agblklog; mp->m_litino = sbp->sb_inodesize - ((uint)sizeof(xfs_dinode_core_t) + (uint)sizeof(xfs_agino_t)); @@ -1420,11 +1420,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi /* find modified range */ - f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields); + f = (xfs_sb_field_t)find_first_bit((unsigned long *)&fields, 64); ASSERT((1LL << f) & XFS_SB_MOD_BITS); first = xfs_sb_info[f].offset; - f = (xfs_sb_field_t)xfs_highbit64((__uint64_t)fields); + f = (xfs_sb_field_t)fls64((__uint64_t)fields) - 1; ASSERT((1LL << f) & XFS_SB_MOD_BITS); last = xfs_sb_info[f + 1].offset - 1; Index: linux-2.6-xfs/fs/xfs/xfs_rtalloc.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rtalloc.h +++ linux-2.6-xfs/fs/xfs/xfs_rtalloc.h @@ -60,13 +60,19 @@ struct xfs_trans; #define XFS_RTMIN(a,b) ((a) < (b) ? (a) : (b)) #define XFS_RTMAX(a,b) ((a) > (b) ? (a) : (b)) -#define XFS_RTLOBIT(w) xfs_lowbit32(w) -#define XFS_RTHIBIT(w) xfs_highbit32(w) +/* All callers check for 0 arguments already; so no -1 handling */ +static inline int xfs_rtlobit(unsigned long v) +{ + return find_first_bit(&v, 32); +} + +#define XFS_RTLOBIT(w) xfs_rtlobit(w) +#define XFS_RTHIBIT(w) (fls(w) - 1) #if XFS_BIG_BLKNOS -#define XFS_RTBLOCKLOG(b) xfs_highbit64(b) +#define XFS_RTBLOCKLOG(b) (fls64(b) - 1) #else -#define XFS_RTBLOCKLOG(b) xfs_highbit32(b) +#define XFS_RTBLOCKLOG(b) (fls(b) - 1) #endif Index: linux-2.6-xfs/fs/xfs/xfs_rtalloc.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rtalloc.c +++ linux-2.6-xfs/fs/xfs/xfs_rtalloc.c @@ -73,18 +73,6 @@ STATIC int xfs_rtmodify_summary(xfs_moun */ /* - * xfs_lowbit32: get low bit set out of 32-bit argument, -1 if none set. - */ -STATIC int -xfs_lowbit32( - __uint32_t v) -{ - if (v) - return ffs(v) - 1; - return -1; -} - -/* * Allocate space to the bitmap or summary file, and zero it, for growfs. */ STATIC int /* error */ @@ -444,7 +432,8 @@ xfs_rtallocate_extent_near( } bbno = XFS_BITTOBLOCK(mp, bno); i = 0; - log2len = xfs_highbit32(minlen); + ASSERT(minlen != 0); + log2len = fls(minlen) - 1; /* * Loop over all bitmap blocks (bbno + i is current block). */ @@ -607,11 +596,13 @@ xfs_rtallocate_extent_size( int error; /* error value */ int i; /* bitmap block number */ int l; /* level number (loop control) */ + int end; xfs_rtblock_t n; /* next block to be tried */ xfs_rtblock_t r; /* result block number */ xfs_suminfo_t sum; /* summary information for extents */ ASSERT(minlen % prod == 0 && maxlen % prod == 0); + ASSERT(maxlen != 0); /* * Loop over all the levels starting with maxlen. * At each level, look at all the bitmap blocks, to see if there @@ -619,7 +610,7 @@ xfs_rtallocate_extent_size( * Note, only on the initial level can the allocation fail if * the summary says there's an extent. */ - for (l = xfs_highbit32(maxlen); l < mp->m_rsumlevels; l++) { + for (l = fls(maxlen) - 1; l < mp->m_rsumlevels; l++) { /* * Loop over all the bitmap blocks. */ @@ -669,12 +660,15 @@ xfs_rtallocate_extent_size( *rtblock = NULLRTBLOCK; return 0; } + ASSERT(maxlen != 0); + ASSERT(minlen != 0); /* * Loop over sizes, from maxlen down to minlen. * This time, when we do the allocations, allow smaller ones * to succeed. */ - for (l = xfs_highbit32(maxlen); l >= xfs_highbit32(minlen); l--) { + end = fls(minlen) - 1; + for (l = fls(maxlen) - 1; l >= end; l--) { /* * Loop over all the bitmap blocks, try an allocation * starting in that block. @@ -1863,7 +1857,6 @@ xfs_growfs_rt( xfs_drfsbno_t nrblocks; /* new number of realtime blocks */ xfs_extlen_t nrbmblocks; /* new number of rt bitmap blocks */ xfs_drtbno_t nrextents; /* new number of realtime extents */ - uint8_t nrextslog; /* new log2 of sb_rextents */ xfs_extlen_t nrsumblocks; /* new number of summary blocks */ uint nrsumlevels; /* new rt summary levels */ uint nrsumsize; /* new size of rt summary, bytes */ @@ -1900,8 +1893,7 @@ xfs_growfs_rt( nrextents = nrblocks; do_div(nrextents, in->extsize); nrbmblocks = howmany_64(nrextents, NBBY * sbp->sb_blocksize); - nrextslog = xfs_highbit32(nrextents); - nrsumlevels = nrextslog + 1; + nrsumlevels = fls(nrextents); nrsumsize = (uint)sizeof(xfs_suminfo_t) * nrsumlevels * nrbmblocks; nrsumblocks = XFS_B_TO_FSB(mp, nrsumsize); nrsumsize = XFS_FSB_TO_B(mp, nrsumblocks); @@ -1954,7 +1946,8 @@ xfs_growfs_rt( nsbp->sb_blocksize * nsbp->sb_rextsize); nsbp->sb_rextents = nsbp->sb_rblocks; do_div(nsbp->sb_rextents, nsbp->sb_rextsize); - nsbp->sb_rextslog = xfs_highbit32(nsbp->sb_rextents); + ASSERT(nsbp->sb_rextents != 0); + nsbp->sb_rextslog = fls(nsbp->sb_rextents) - 1; nrsumlevels = nmp->m_rsumlevels = nsbp->sb_rextslog + 1; nrsumsize = (uint)sizeof(xfs_suminfo_t) * nrsumlevels * @@ -2317,9 +2310,10 @@ xfs_rtpick_extent( *seqp = 0; } seq = *seqp; - if ((log2 = xfs_highbit64(seq)) == -1) + if ((log2 = fls64(seq)) == 0) b = 0; else { + log2--; resid = seq - (1ULL << log2); b = (mp->m_sb.sb_rextents * ((resid << 1) + 1ULL)) >> (log2 + 1); Index: linux-2.6-xfs/fs/xfs/xfs_ialloc.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_ialloc.h +++ linux-2.6-xfs/fs/xfs/xfs_ialloc.h @@ -52,10 +52,10 @@ xfs_make_iptr(struct xfs_mount *mp, stru #define XFS_IALLOC_FIND_FREE(fp) xfs_ialloc_find_free(fp) static inline int xfs_ialloc_find_free(xfs_inofree_t *fp) { - return xfs_lowbit64(*fp); + unsigned long v = *fp; /* Guarantee alignment */ + return find_first_bit(&v, 64); } - #ifdef __KERNEL__ /* * Allocate an inode on disk. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c @@ -222,8 +222,6 @@ EXPORT_SYMBOL(xfs_file_last_byte); EXPORT_SYMBOL(xfs_finish_reclaim_all); EXPORT_SYMBOL(xfs_freesb); EXPORT_SYMBOL(xfs_fs_cmn_err); -EXPORT_SYMBOL(xfs_highbit32); -EXPORT_SYMBOL(xfs_highbit64); EXPORT_SYMBOL(xfs_idestroy); EXPORT_SYMBOL(xfs_iaccess); EXPORT_SYMBOL(xfs_iextract); From owner-xfs@oss.sgi.com Wed Oct 3 15:57:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 15:57:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32 autolearn=no version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l93MvqwY000703 for ; Wed, 3 Oct 2007 15:57:54 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id 69BC292C814; Thu, 4 Oct 2007 08:57:50 +1000 (EST) Received: from 192.168.3.1 (proxying for 211.28.181.43) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Thu, 4 Oct 2007 08:58:11 +1000 (EST) Message-ID: <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> In-Reply-To: <200710040027.16926.ak@suse.de> References: <200710040027.16926.ak@suse.de> Date: Thu, 4 Oct 2007 08:58:11 +1000 (EST) Subject: Re: [PATCH] XFS bitops to Linux again From: nscott@aconex.com To: "Andi Kleen" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13241 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs > > This time against CVS > > Replace XFS bit functions with call Linux functions > > XFS had some own functions to find high and low bits. > > This patch replaces them with a call to the respective Linux functions. > The semantics of the Linux functions differ a little, but i checked > all call sites that they can deal with that. Several of these call sites are also compiled in userspace in libxfs. It would be a good idea from that POV also to keep some level of abstraction so that these calls can be mapped to userspace routines as well. > The resulting xfs.ko is about 500 bytes smaller on x86-64 Thats it? To be honest, this sounds like just code churn and risk introduction. What testing was done? Changes to some of these routines has introuced subtle log recovery bugs in the past - has recovery been tested at all? The QA suite has some log recovery tests, it'd be a good idea to verify with those.. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Oct 3 17:26:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 17:26:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l940QId5013343 for ; Wed, 3 Oct 2007 17:26:20 -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 KAA17750; Thu, 4 Oct 2007 10:26:16 +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 l940QEdD49841231; Thu, 4 Oct 2007 10:26:14 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l940QBpr50003658; Thu, 4 Oct 2007 10:26:11 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 4 Oct 2007 10:26:11 +1000 From: David Chinner To: Justin Piszcz Cc: Timothy Shimmin , Lachlan McIlroy , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit Message-ID: <20071004002611.GB23367404@sgi.com> References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> <4702F517.3040502@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13242 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 On Wed, Oct 03, 2007 at 04:11:50AM -0400, Justin Piszcz wrote: > If one with was running 2.6.23-rc8 with XFS, does that mean we should run > xfs_repair on our filesystems after upgrading to -rc9? Only if you had unclean shutdowns while running 2.6.23-rc8. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 3 17:39:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 17:39:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l940diOS014885 for ; Wed, 3 Oct 2007 17:39:46 -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 KAA18005; Thu, 4 Oct 2007 10:39: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 l940dcdD49993196; Thu, 4 Oct 2007 10:39:38 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l940dZ1w50039822; Thu, 4 Oct 2007 10:39:35 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 4 Oct 2007 10:39:35 +1000 From: David Chinner To: Alessandro Bono Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.23-rc9-git1 hang with XFS Message-ID: <20071004003935.GC23367404@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-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13243 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 On Wed, Oct 03, 2007 at 11:03:29PM +0200, Alessandro Bono wrote: > Hi all > > I'm testing 2.6.23-rc9-git1 on my old home server > Trying to reorganizer my xfs filesystem with xfs_fsr cause a sort of system > hang xfs_fsr is waiting for a direct I/O to complete. Other processes are waiting for the superblock I/O to compete (which is why writes are hanging), an dothers are waiting for iclog space to be freed up. I think something is holding off I/O completion, and this: > possible SYN flooding on port 4664. Sending cookies. > possible SYN flooding on port 4664. Sending cookies. > possible SYN flooding on port 4664. Sending cookies. > possible SYN flooding on port 4664. Sending cookies. > possible SYN flooding on port 4664. Sending cookies. indicates someone trying a DOS on your box. Perhaps it's succeeding by denying interrupt service to you disks? If you pull the network cable, does the system start to respond properly again? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 3 21:21:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 21:21:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l944L4lJ009875 for ; Wed, 3 Oct 2007 21:21:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 OAA22309; Thu, 4 Oct 2007 14:21:03 +1000 Date: Thu, 04 Oct 2007 14:25:16 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: xfs_reno #2 From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------MAhJ3q66PgIP4VwapyTDNq MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4461/Wed Oct 3 01:50:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13244 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------MAhJ3q66PgIP4VwapyTDNq Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit A couple changes from the first xfs_reno: - Major one is that symlinks are now supported, but only owner, group and extended attributes are copied for them (not times or inode attributes). - Man page! To make this better, ideally we need some form of "swap inodes" function in the kernel, where the entire contents of the inode themselves are swapped. This form can handle any inode and without any of the dir/file/attr/etc copy/swap mechanisms we have in xfs_reno. Barry. ------------MAhJ3q66PgIP4VwapyTDNq Content-Disposition: attachment; filename=xfs_reno.patch Content-Type: application/octet-stream; name=xfs_reno.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNkdW1wL01ha2Vm aWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEveGZz ZHVtcC9NYWtlZmlsZQkyMDA3LTEwLTA0IDE0OjE2OjM5LjAwMDAwMDAwMCAr MTAwMAorKysgYi94ZnNkdW1wL01ha2VmaWxlCTIwMDctMDktMTQgMTc6MzE6 MzEuOTE2NDM3MTQwICsxMDAwCkBAIC0xNiw3ICsxNiw3IEBACiAJTG9ncy8q IGJ1aWx0IC5jZW5zdXMgaW5zdGFsbC4qIGluc3RhbGwtZGV2LiogKi5negog CiBTVUJESVJTID0gaW5jbHVkZSBsaWJybXQgXAotCWNvbW1vbiBlc3RpbWF0 ZSBmc3IgaW52ZW50b3J5IGludnV0aWwgZHVtcCByZXN0b3JlIFwKKwljb21t b24gZXN0aW1hdGUgZnNyIGludmVudG9yeSBpbnZ1dGlsIGR1bXAgcmVubyBy ZXN0b3JlIFwKIAltNCBtYW4gZG9jIHBvIGRlYmlhbiBidWlsZAogCiBkZWZh dWx0OiAkKENPTkZJR1VSRSkKCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQp4ZnNkdW1wL21hbi9tYW44L3hmc19yZW5vLjgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09CgotLS0gYS94ZnNkdW1wL21hbi9tYW44L3hm c19yZW5vLjgJMjAwNi0wNi0xNyAwMDo1ODoyNC4wMDAwMDAwMDAgKzEwMDAK KysrIGIveGZzZHVtcC9tYW4vbWFuOC94ZnNfcmVuby44CTIwMDctMTAtMDQg MTQ6MTA6MzAuMzE2MDI3Njk0ICsxMDAwCkBAIC0wLDAgKzEsMTE3IEBACisu VEggeGZzX3Jlbm8gOAorLlNIIE5BTUUKK3hmc19yZW5vIFwtIHJlbnVtYmVy IFhGUyBpbm9kZXMKKy5TSCBTWU5PUFNJUworLkIgeGZzX3Jlbm8KK1sKKy5C IFwtZm5wcXYKK10gWworLkIgXC1QCisuSSBpbnRlcnZhbAorXQorLkkgcGF0 aAorLmJyCisuQiB4ZnNfcmVubyBcLXIKKy5JIHJlY292ZXJfZmlsZQorLlNI IERFU0NSSVBUSU9OCisuQiB4ZnNfcmVubworaXMgYXBwbGljYWJsZSBvbmx5 IHRvIFhGUyBmaWxlc3lzdGVtcy4KKy5QUAorLkIgeGZzX3Jlbm8KK3JlbnVt YmVycyBpbm9kZXMuIFhGUyBzdXBwb3J0cyA2NC1iaXQgaW5vZGUgbnVtYmVy cywgYWx0aG91Z2ggYnkKK2RlZmF1bHQgaXQgd2lsbCBhdm9pZCBjcmVhdGlu ZyBpbm9kZXMgd2l0aCBudW1iZXJzIGdyZWF0ZXIgdGhhbgord2hhdCBjYW4g YmUgY29udGFpbmVkIHdpdGhpbiBhIDMyLWJpdCBudW1iZXIuIElmIGEgZmls ZXN5c3RlbSBkb2VzCitjb250YWluIGlub2RlIG51bWJlcnMgZ3JlYXRlciB0 aGFuIDMyLWJpdHMsIHRoZW4gdGhpcyBjYW4gY29uZmxpY3Qgd2l0aAorYXBw bGljYXRpb25zIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhlbS4KK1RvIHJlY292 ZXIgZnJvbSB0aGlzIHNpdHVhdGlvbiBwcmV2aW91c2x5LCBhZmZlY3RlZCBm aWxlcyB3b3VsZCBuZWVkCit0byBiZSBjb3BpZWQgKGFuZCBzbyBnZXQgYSBu ZXcgaW5vZGUgbnVtYmVyKSBhbmQgdGhlIG9sZCB2ZXJzaW9uCityZW1vdmVk LiBUaGlzIGNhbiBiZSB0aW1lIGNvbnN1bWluZyBhbmQgaW1wcmFjdGljYWwg Zm9yIHZlcnkgbGFyZ2UKK2ZpbGVzIGFuZCBmaWxlc3lzdGVtcy4KKy5CIHhm c19yZW5vCitjYW4gYmUgdXNlZCB0byByZW51bWJlciBzdWNoIGlub2RlcyBx dWlja2x5LgorLkIgeGZzX3Jlbm8KK3dpbGwgY29weSB0aGUgaW5vZGVzIG9m IGFmZmVjdGVkIGZpbGVzIGFuZCBtb3ZlIHRoZSBkYXRhIGZyb20gdGhlIG9s ZAoraW5vZGUgdG8gdGhlIG5ldyB3aXRob3V0IGhhdmluZyB0byBjb3B5IHRo ZSBkYXRhLgorLkIgeGZzX3Jlbm8KK3JlbGllcyBvbiBYRlMgaW4gdGhlIGtl cm5lbCB0byBhbGxvY2F0ZSBhIG5ldyBpbm9kZSBudW1iZXIsIHNvIGlmIHRo ZQorZmlsZXN5c3RlbSBoYXMgYmVlbiBtb3VudGVkIHdpdGggdGhlCisuSSBp bm9kZTY0Cittb3VudCBvcHRpb24sIHRoZSBuZXcgaW5vZGVzIHdpbGwgcXVp dGUgcG9zc2libHkgaGF2ZSBpbm9kZSBudW1iZXJzCitncmVhdGVyIHRoYW4g MzItYml0cy4KKy5QUAorLkIgeGZzX3Jlbm8KK3Nob3VsZCBvbmx5IGJlIHVz ZWQgb24gYSBmaWxlc3lzdGVtIHdoZXJlIGl0IGlzIG5lY2Vzc2FyeSB0bwor cmVudW1iZXIgaW5vZGVzLiBVc2Ugb2YKKy5CIHhmc19yZW5vCitvbiBhIHJl Z3VsYXIgYmFzaXMgaXMKKy5JUiAibm90IHJlY29tbWVuZGVkIiAuCitBcGFy dCBmcm9tIGFwcGxpY2F0aW9uIGNvbXBhdGliaWxpdHksIHRoZXJlIGlzIG5v IHBhcnRpY3VsYXIgYWR2YW50YWdlCit0byBiZSBoYWQgZnJvbSByZW51bWJl cmluZyBpbm9kZXMuCisuUFAKKy5CIHhmc19yZW5vCit3b3JrcyBieSB0cmF2 ZXJzaW5nIGEgZGlyZWN0b3J5IHRyZWUsIHNjYW5uaW5nIGFsbCB0aGUgZGly ZWN0b3JpZXMKK2FuZCBub3Rpbmcgd2hpY2ggZmlsZXMgcmVxdWlyZSByZW51 bWJlcmluZy4gT25jZSB0aGUgc2Nhbm5pbmcgcGhhc2UKK2lzIGRvbmUsIGl0 IHdpbGwgcHJvY2VzcyB0aGUgYXBwcm9wcmlhdGUgZmlsZXMgYW5kIGRpcmVj dG9yaWVzLiBUaGUKK2RpcmVjdG9yeSdzIGFic29sdXRlIHBhdGhuYW1lIG11 c3QgYmUgZ2l2ZW4gdG8KKy5CUiB4ZnNfcmVubyAuCitUaGUgZm9sbG93aW5n IG9wdGlvbnMgYXJlIGFjY2VwdGVkIGJ5CisuQlIgeGZzX3Jlbm8gLgorLlRQ CisuQiBcLWYKK0ZvcmNlIGNvbnZlcnNpb24gb24gYWxsIGlub2RlcywgcmF0 aGVyIHRoYW4ganVzdCB0aG9zZSB3aXRoIGEgNjQtYml0Citpbm9kZSBudW1i ZXIuIFRoaXMgaXMgbm90IHBhcnRpY3VsYXJseSB1c2VmdWwgZXhjZXB0IGZv ciBkZWJ1Z2dpbmcKK3B1cnBvc2VzLgorLlRQCisuQiBcLW4KK0RvIG5vdGhp bmcsIHBlcmZvcm0gYSB0cmlhbCBydW4uCisuVFAKKy5CIFwtdgorSW5jcmVh c2VzIHRoZSB2ZXJib3NpdHkgb2YgcHJvZ3Jlc3MgYW5kIGVycm9yIG1lc3Nh Z2VzLiAgQWRkaXRpb25hbAorLkJSIFwtdiAncworY2FuIGJlIHVzZWQgdG8g ZnVydGhlciBpbmNyZWFzZSB2ZXJib3NpdHkuCisuVFAKKy5CIFwtcQorRG8g bm90IHJlcG9ydCBwcm9ncmVzcywgb25seSBlcnJvcnMuCisuVFAKKy5CIFwt cAorU2hvdyBwcm9ncmVzcyBzdGF0dXMuCisuVFAKKy5CSSBcLVAgIiBzZWNv bmRzIgorU2V0IHRoZSBpbnRlcnZhbCBmb3IgdGhlIHByb2dyZXNzIHN0YXR1 cyBpbiBzZWNvbmRzLiAgVGhlIGRlZmF1bHQgaXMgMQorc2Vjb25kLgorLlRQ CisuQiBcLXIKK1JlY292ZXIgZnJvbSBhbiBpbnRlcnJ1cHRlZCBydW4uICBJ ZgorLkIgeGZzX3Jlbm8KK2lzIGludGVycnVwdGVkLCBpdCB3aWxsIGxlYXZl IGEgZmlsZSBjYWxsZWQKKy5JIHhmc19yZW5vLnJlY292ZXIKK2luIHRoZSBk aXJlY3Rvcnkgc3BlY2lmaWVkIG9uIHRoZSBjb21tYW5kIGxpbmUuICBUaGlz IGZpbGUgd2lsbAorY29udGFpbiBlbm91Z2ggaW5mb3JtYXRpb24gc28gdGhh dAorLkIgeGZzX3Jlbm8KK2NhbiBlaXRoZXIgZmluaXNoIHByb2Nlc3Npbmcg dGhlIGZpbGUgaXQgd2FzIHdvcmtpbmcgb24gd2hlbgoraW50ZXJydXB0ZWQg b3IgYmFjayBvdXQgdGhlIGxhc3QgY2hhbmdlIGl0IG1hZGUsIGRlcGVuZGlu ZyBvbiBob3cgZmFyCit0aHJvdWdoIHRoZSBwcm9jZXNzIGl0IGhhZCBwcm9n cmVzc2VkLgorLkIgeGZzX3Jlbm8KK3dpbGwgb25seSByZWNvdmVyIHRoZSBz aW5nbGUgZmlsZSBpdCB3YXMgd29ya2luZyBvbiBzbyBpdCB3aWxsIG5lZWQK K3RvIGJlIHJ1biBhZ2FpbiBvbiB0aGUgZGlyZWN0b3J5IHRvIGJlIHN1cmUg dGhhdCBhbGwgdGhlIGFwcHJvcHJpYXRlCitpbm9kZXMgaGF2ZSBiZWVuIGNv bnZlcnRlZC4KKy5TSCBFWEFNUExFUworVG8gcmVudW1iZXIgaW5vZGVzIHdp dGggNjQtYml0IGlub2RlIG51bWJlcnM6CisuSVAKKy5CICMgeGZzX3Jlbm8g LXAgL3BhdGgvdG8vZGlyZWN0b3J5CisuUFAKK1RvIHJlY292ZXIgZnJvbSBh biBpbnRlcnJ1cHRlZCBydW46CisuSVAKKy5CICMgeGZzX3Jlbm8gLXIgL3Bh dGgvdG8vZGlyZWN0b3J5L3hmc19yZW5vLnJlY292ZXIKKy5QUAorLlNIIEZJ TEVTCisuUEQKKy5UUAorLkkgL3BhdGgveGZzX3Jlbm8ucmVjb3ZlcgorcmVj b3JkcyB0aGUgc3RhdGUgd2hlcmUgcmVudW1iZXJpbmcgd2FzIGludGVycnVw dGVkLgorLlBECisuU0ggU0VFIEFMU08KKy5CUiB4ZnNfZnNyICg4KSwKKy5C UiB4ZnNfbmNoZWNrICg4KSwKKy5CUiBmc3RhYiAoNSksCisuQlIgeGZzICg1 KS4KCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNkdW1wL3Jl bm8vTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cgot LS0gYS94ZnNkdW1wL3Jlbm8vTWFrZWZpbGUJMjAwNi0wNi0xNyAwMDo1ODoy NC4wMDAwMDAwMDAgKzEwMDAKKysrIGIveGZzZHVtcC9yZW5vL01ha2VmaWxl CTIwMDctMTAtMDIgMTc6MDY6MTguNjU4MzIwNzM4ICsxMDAwCkBAIC0wLDAg KzEsMTkgQEAKKyMKKyMgQ29weXJpZ2h0IChjKSAyMDA3IFNpbGljb24gR3Jh cGhpY3MsIEluYy4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCisjCisKK1RPUERJ UiA9IC4uCitpbmNsdWRlICQoVE9QRElSKS9pbmNsdWRlL2J1aWxkZGVmcwor CitMVENPTU1BTkQgPSB4ZnNfcmVubworQ0ZJTEVTID0geGZzX3Jlbm8uYwor TExETElCUyA9ICQoTElCQVRUUikKKworZGVmYXVsdDogJChMVENPTU1BTkQp CisKK2luY2x1ZGUgJChCVUlMRFJVTEVTKQorCitpbnN0YWxsOiBkZWZhdWx0 CisJJChJTlNUQUxMKSAtbSA3NTUgLWQgJChQS0dfQklOX0RJUikKKwkkKExU SU5TVEFMTCkgLW0gNzU1ICQoTFRDT01NQU5EKSAkKFBLR19CSU5fRElSKQor aW5zdGFsbC1kZXY6Cgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K eGZzZHVtcC9yZW5vL3hmc19yZW5vLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09CgotLS0gYS94ZnNkdW1wL3Jlbm8veGZzX3Jlbm8uYwkyMDA2 LTA2LTE3IDAwOjU4OjI0LjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNkdW1w L3Jlbm8veGZzX3Jlbm8uYwkyMDA3LTEwLTA0IDE0OjExOjQzLjEwMjUyMTE2 MSArMTAwMApAQCAtMCwwICsxLDIwNDAgQEAKKy8qCisgKiBDb3B5cmlnaHQg KGMpIDIwMDcgU2lsaWNvbiBHcmFwaGljcywgSW5jLgorICogQWxsIFJpZ2h0 cyBSZXNlcnZlZC4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0 d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCisgKiBtb2Rp ZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSBhcworICogcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3 YXJlIEZvdW5kYXRpb24uCisgKgorICogVGhpcyBwcm9ncmFtIGlzIGRpc3Ry aWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsLAor ICogYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhl IGltcGxpZWQgd2FycmFudHkgb2YKKyAqIE1FUkNIQU5UQUJJTElUWSBvciBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyAq IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMu CisgKgorICogWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0 aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKKyAqIGFsb25nIHdpdGgg dGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb24sCisgKiBJbmMuLCAgNTEgRnJhbmtsaW4gU3QsIEZpZnRo IEZsb29yLCBCb3N0b24sIE1BICAwMjExMC0xMzAxICBVU0EKKyAqLworCisv KgorICogeGZzX3Jlbm8gLSByZW51bWJlciA2NC1iaXQgaW5vZGVzCisgKgor ICogeGZzX3Jlbm8gWy1mXSBbLW5dIFstcF0gWy1xXSBbLXZdIFstUCBzZWNv bmRzXSBwYXRoIC4uLgorICogeGZzX3Jlbm8gWy1yXSBwYXRoIC4uLgorICoK KyAqIFJlbnVtYmVycyBhbGwgaW5vZGVzID4gMzIgYml0cyBpbnRvIDMyIGJp dCBzcGFjZS4gUmVxdWlyZXMgdGhlIGZpbGVzeXRlbQorICogdG8gYmUgbW91 bnRlZCB3aXRoIGlub2RlMzIuCisgKgorICoJLWYJCWZvcmNlIGNvbnZlcnNp b24gb24gYWxsIGlub2RlcyByYXRoZXIgdGhhbiBqdXN0CisgKgkJCXRob3Nl IHdpdGggYSA2NGJpdCBpbm9kZSBudW1iZXIuCisgKgktbgkJbm90aGluZywg ZG8gbm90IHJlbnVtYmVyIGlub2RlcworICoJLXAJCXNob3cgcHJvZ3Jlc3Mg c3RhdHVzLgorICoJLXEJCXF1aWV0LCBkbyBub3QgcmVwb3J0IHByb2dyZXNz LCBvbmx5IGVycm9ycy4KKyAqCS12CQl2ZXJib3NlLCBtb3JlIC12J3MgbW9y ZSB2ZXJib3NlLgorICoJLVAgc2Vjb25kcwlzZXQgdGhlIGludGVydmFsIGZv ciB0aGUgcHJvZ3Jlc3Mgc3RhdHVzIGluIHNlY29uZHMuCisgKgktcgkJcmVj b3ZlciBmcm9tIGFuIGludGVycnVwdGVkIHJ1bi4KKyAqLworCisjaW5jbHVk ZSA8eGZzL3hmcy5oPgorCisjaW5jbHVkZSA8ZGlyZW50Lmg+CisjaW5jbHVk ZSA8ZXJybm8uaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPGZ0 dy5oPgorI2luY2x1ZGUgPGxpYmdlbi5oPgorI2luY2x1ZGUgPG1hbGxvYy5o PgorI2luY2x1ZGUgPHNpZ25hbC5oPgorI2luY2x1ZGUgPHN0ZGludC5oPgor I2luY2x1ZGUgPHN5cy9pb2N0bC5oPgorI2luY2x1ZGUgPGF0dHIvYXR0cmli dXRlcy5oPgorI2luY2x1ZGUgPHhmcy94ZnNfZGZyYWcuaD4KKyNpbmNsdWRl IDx4ZnMveGZzX2ludW0uaD4KKworI2RlZmluZSBBVFRSQlVGU0laRQkxMDI0 CisKKyNkZWZpbmUgU0NBTl9QSEFTRQkweDAwCisjZGVmaW5lIERJUl9QSEFT RQkweDEwCS8qIG5vdGhpbmcgZG9uZSBvciBhbGwgZG9uZSAqLworI2RlZmlu ZSBESVJfUEhBU0VfMQkweDExCS8qIHRhcmdldCBkaXIgY3JlYXRlZCAqLwor I2RlZmluZSBESVJfUEhBU0VfMgkweDEyCS8qIHRlbXAgZGlyIGNyZWF0ZWQg Ki8KKyNkZWZpbmUgRElSX1BIQVNFXzMJMHgxMwkvKiBhdHRyaWJ1dGVzIGJh Y2tlZCB1cCB0byB0ZW1wICovCisjZGVmaW5lIERJUl9QSEFTRV80CTB4MTQJ LyogZGlyZW50cyBtb3ZlZCB0byB0YXJnZXQgZGlyICovCisjZGVmaW5lIERJ Ul9QSEFTRV81CTB4MTUJLyogYXR0cmlidXRlcyBhcHBsaWVkIHRvIHRhcmdl dCBkaXIgKi8KKyNkZWZpbmUgRElSX1BIQVNFXzYJMHgxNgkvKiBzcmMgZGly IHJlbW92ZWQgKi8KKyNkZWZpbmUgRElSX1BIQVNFXzcJMHgxNwkvKiB0ZW1w IGRpciByZW1vdmVkICovCisjZGVmaW5lIERJUl9QSEFTRV9NQVgJMHgxNwor I2RlZmluZSBGSUxFX1BIQVNFCTB4MjAJLyogbm90aGluZyBkb25lIG9yIGFs bCBkb25lICovCisjZGVmaW5lIEZJTEVfUEhBU0VfMQkweDIxCS8qIHRlbXAg ZmlsZSBjcmVhdGVkICovCisjZGVmaW5lIEZJTEVfUEhBU0VfMgkweDIyCS8q IHN3YXBwZWQgZXh0ZW50cyAqLworI2RlZmluZSBGSUxFX1BIQVNFXzMJMHgy MwkvKiB1bmxpbmtlZCBzb3VyY2UgKi8KKyNkZWZpbmUgRklMRV9QSEFTRV80 CTB4MjQJLyogcmVuYW1lZCB0ZW1wIHRvIHNvdXJjZSBuYW1lICovCisjZGVm aW5lIEZJTEVfUEhBU0VfTUFYCTB4MjQKKyNkZWZpbmUgU0xJTktfUEhBU0UJ MHgzMAkvKiBub3RoaW5nIGRvbmUgb3IgYWxsIGRvbmUgKi8KKyNkZWZpbmUg U0xJTktfUEhBU0VfMQkweDMxCS8qIHRlbXAgc3ltbGluayBjcmVhdGVkICov CisjZGVmaW5lIFNMSU5LX1BIQVNFXzIJMHgzMgkvKiBzeW1saW5rIGF0dHJz IGNvcGllZCAqLworI2RlZmluZSBTTElOS19QSEFTRV8zCTB4MzMJLyogdW5s aW5rZWQgc291cmNlICovCisjZGVmaW5lIFNMSU5LX1BIQVNFXzQJMHgzNAkv KiByZW5hbWVkIHRlbXAgdG8gc291cmNlIG5hbWUgKi8KKyNkZWZpbmUgU0xJ TktfUEhBU0VfTUFYCTB4MzQKKworc3RhdGljIHZvaWQgdXBkYXRlX3JlY292 ZXJmaWxlKHZvaWQpOworI2RlZmluZSBTRVRfUEhBU0UoeCkJKGN1cl9waGFz ZSA9IHgsIHVwZGF0ZV9yZWNvdmVyZmlsZSgpKQorCisjZGVmaW5lIExPR19F UlIJCTAKKyNkZWZpbmUgTE9HX05PUk1BTAkxCisjZGVmaW5lIExPR19JTkZP CTIKKyNkZWZpbmUgTE9HX0RFQlVHCTMKKyNkZWZpbmUgTE9HX05JVFRZCTQK KworI2RlZmluZSBOSF9CVUNLRVRTCTY1NTM2CisjZGVmaW5lIE5IX0hBU0go aW5vKQkobm9kZWhhc2ggKyAoKGlubykgJSBOSF9CVUNLRVRTKSkKKwordHlw ZWRlZiBzdHJ1Y3QgeworCXhmc19pbm9fdAlpbm87CisJaW50CQlmdHdfZmxh Z3M7CisJbmxpbmtfdAkJbnVtcGF0aHM7CisJY2hhcgkJKipwYXRoczsKK30g Ymlnbm9kZV90OworCit0eXBlZGVmIHN0cnVjdCB7CisJYmlnbm9kZV90CSpu b2RlczsKKwl1aW50NjRfdAlsaXN0bGVuOworCXVpbnQ2NF90CWxhc3Rub2Rl OworfSBub2RlbGlzdF90OworCitzdGF0aWMgY29uc3QgY2hhcgkqY21kX3By ZWZpeCA9ICJ4ZnNfcmVub18iOworCitzdGF0aWMgY2hhcgkJKnByb2duYW1l Oworc3RhdGljIGludAkJbG9nX2xldmVsID0gTE9HX05PUk1BTDsKK3N0YXRp YyBpbnQJCWZvcmNlX2FsbDsKK3N0YXRpYyBub2RlbGlzdF90CSpub2RlaGFz aDsKK3N0YXRpYyBpbnQJCXJlYWx1aWQ7CitzdGF0aWMgdWludDY0X3QJCW51 bWRpcm5vZGVzOworc3RhdGljIHVpbnQ2NF90CQludW1maWxlbm9kZXM7Citz dGF0aWMgdWludDY0X3QJCW51bXNsaW5rbm9kZXM7CitzdGF0aWMgdWludDY0 X3QJCW51bWRpcnNkb25lOworc3RhdGljIHVpbnQ2NF90CQludW1maWxlc2Rv bmU7CitzdGF0aWMgdWludDY0X3QJCW51bXNsaW5rc2RvbmU7CitzdGF0aWMg aW50CQlwb2xsX2ludGVydmFsOworc3RhdGljIHRpbWVfdAkJc3RhcnR0aW1l Oworc3RhdGljIGJpZ25vZGVfdAkqY3VyX25vZGU7CitzdGF0aWMgY2hhcgkJ KmN1cl90YXJnZXQ7CitzdGF0aWMgY2hhcgkJKmN1cl90ZW1wOworc3RhdGlj IGludAkJY3VyX3BoYXNlOworc3RhdGljIGludAkJaGlnaGVzdF9udW1wYXRo czsKK3N0YXRpYyBjaGFyCQkqcmVjb3Zlcl9maWxlOworc3RhdGljIGludAkJ cmVjb3Zlcl9mZDsKK3N0YXRpYyB2b2xhdGlsZSBpbnQJcG9sbF9vdXRwdXQ7 CitzdGF0aWMgaW50CQlnbG9iYWxfcnZhbDsKKworLyoKKyAqIG1lc3NhZ2Ug aGFuZGxpbmcKKyAqLworc3RhdGljIHZvaWQKK2xvZ19tZXNzYWdlKAorCWlu dAkJbGV2ZWwsCisJY2hhcgkJKmZtdCwgLi4uKQoreworCWNoYXIJCWJ1Zlsx MDI0XTsKKwl2YV9saXN0CQlhcDsKKworCWlmIChsb2dfbGV2ZWwgPCBsZXZl bCkKKwkJcmV0dXJuOworCisJdmFfc3RhcnQoYXAsIGZtdCk7CisJdnNucHJp bnRmKGJ1ZiwgMTAyNCwgZm10LCBhcCk7CisJdmFfZW5kKGFwKTsKKworCXBy aW50ZigiJWMlczogJXNcbiIsIHBvbGxfb3V0cHV0ID8gJ1xuJyA6ICdccics IHByb2duYW1lLCBidWYpOworCXBvbGxfb3V0cHV0ID0gMDsKK30KKworc3Rh dGljIHZvaWQKK2Vycl9tZXNzYWdlKAorCWNoYXIJCSpmbXQsIC4uLikKK3sK KwljaGFyCQlidWZbMTAyNF07CisJdmFfbGlzdAkJYXA7CisKKwl2YV9zdGFy dChhcCwgZm10KTsKKwl2c25wcmludGYoYnVmLCAxMDI0LCBmbXQsIGFwKTsK Kwl2YV9lbmQoYXApOworCisJZnByaW50ZihzdGRlcnIsICIlYyVzOiAlc1xu IiwgcG9sbF9vdXRwdXQgPyAnXG4nIDogJ1xyJywgcHJvZ25hbWUsIGJ1Zik7 CisJcG9sbF9vdXRwdXQgPSAwOworfQorCitzdGF0aWMgdm9pZAorZXJyX25v bWVtKHZvaWQpCit7CisJZXJyX21lc3NhZ2UoXygiT3V0IG9mIG1lbW9yeSIp KTsKK30KKworc3RhdGljIHZvaWQKK2Vycl9vcGVuKAorCWNvbnN0IGNoYXIJ KnMpCit7CisJZXJyX21lc3NhZ2UoXygiQ2Fubm90IG9wZW4gJXM6ICVzIiks IHMsIHN0cmVycm9yKGVycm5vKSk7Cit9CisKK3N0YXRpYyB2b2lkCitlcnJf bm90X3hmcygKKwljb25zdCBjaGFyIAkqcykKK3sKKwllcnJfbWVzc2FnZShf KCIlcyBpcyBub3Qgb24gYW4gWEZTIGZpbGVzeXN0ZW0iKSwgcyk7Cit9CisK K3N0YXRpYyB2b2lkCitlcnJfc3RhdCgKKwljb25zdCBjaGFyCSpzKQorewor CWVycl9tZXNzYWdlKF8oIkNhbm5vdCBzdGF0ICVzOiAlc1xuIiksIHMsIHN0 cmVycm9yKGVycm5vKSk7Cit9CisKKy8qCisgKiB1c2FnZSBtZXNzYWdlCisg Ki8KK3N0YXRpYyB2b2lkCit1c2FnZSh2b2lkKQoreworCWZwcmludGYoc3Rk ZXJyLCBfKCIlcyBbLWZucHF2XSBbLVAgPGludGVydmFsPl0gWy1yXSA8cGF0 aD5cbiIpLAorCQkJcHJvZ25hbWUpOworCWV4aXQoMSk7Cit9CisKKworLyoK KyAqIFhGUyBpbnRlcmZhY2UgZnVuY3Rpb25zCisgKi8KKworc3RhdGljIGlu dAoreGZzX2J1bGtzdGF0X3NpbmdsZShpbnQgZmQsIHhmc19pbm9fdCAqbGFz dGlwLCB4ZnNfYnN0YXRfdCAqdWJ1ZmZlcikKK3sKKwl4ZnNfZnNvcF9idWxr cmVxX3QgIGJ1bGtyZXE7CisKKwlidWxrcmVxLmxhc3RpcCA9IChfX3U2NCAq KWxhc3RpcDsKKwlidWxrcmVxLmljb3VudCA9IDE7CisJYnVsa3JlcS51YnVm ZmVyID0gdWJ1ZmZlcjsKKwlidWxrcmVxLm9jb3VudCA9IE5VTEw7CisJcmV0 dXJuIGlvY3RsKGZkLCBYRlNfSU9DX0ZTQlVMS1NUQVRfU0lOR0xFLCAmYnVs a3JlcSk7Cit9CisKK3N0YXRpYyBpbnQKK3hmc19zd2FwZXh0KGludCBmZCwg eGZzX3N3YXBleHRfdCAqc3gpCit7CisJcmV0dXJuIGlvY3RsKGZkLCBYRlNf SU9DX1NXQVBFWFQsIHN4KTsKK30KKworc3RhdGljIGludAoreGZzX2dldHhh dHRyKGludCBmZCwgc3RydWN0IGZzeGF0dHIgKmF0dHIpCit7CisJcmV0dXJu IGlvY3RsKGZkLCBYRlNfSU9DX0ZTR0VUWEFUVFIsIGF0dHIpOworfQorCitz dGF0aWMgaW50Cit4ZnNfc2V0eGF0dHIoaW50IGZkLCBzdHJ1Y3QgZnN4YXR0 ciAqYXR0cikKK3sKKwlyZXR1cm4gaW9jdGwoZmQsIFhGU19JT0NfRlNTRVRY QVRUUiwgYXR0cik7Cit9CisKKy8qCisgKiBBIGhhc2ggdGFibGUgb2YgaW5v ZGUgbnVtYmVycyBhbmQgYXNzb2NpYXRlZCBwYXRocy4KKyAqLworc3RhdGlj IG5vZGVsaXN0X3QgKgoraW5pdF9ub2RlaGFzaCh2b2lkKQoreworCWludAkJ aTsKKworCW5vZGVoYXNoID0gY2FsbG9jKE5IX0JVQ0tFVFMsIHNpemVvZihu b2RlbGlzdF90KSk7CisJaWYgKG5vZGVoYXNoID09IE5VTEwpIHsKKwkJZXJy X25vbWVtKCk7CisJCXJldHVybiBOVUxMOworCX0KKworCWZvciAoaSA9IDA7 IGkgPCBOSF9CVUNLRVRTOyBpKyspIHsKKwkJbm9kZWhhc2hbaV0ubm9kZXMg PSBOVUxMOworCQlub2RlaGFzaFtpXS5sYXN0bm9kZSA9IDA7CisJCW5vZGVo YXNoW2ldLmxpc3RsZW4gPSAwOworCX0KKworCXJldHVybiBub2RlaGFzaDsK K30KKworc3RhdGljIHZvaWQKK2ZyZWVfbm9kZWhhc2godm9pZCkKK3sKKwlp bnQJCWksIGosIGs7CisKKwlmb3IgKGkgPSAwOyBpIDwgTkhfQlVDS0VUUzsg aSsrKSB7CisJCWJpZ25vZGVfdCAqbm9kZXMgPSBub2RlaGFzaFtpXS5ub2Rl czsKKworCQlmb3IgKGogPSAwOyBqIDwgbm9kZWhhc2hbaV0ubGFzdG5vZGU7 IGorKykgeworCQkJZm9yIChrID0gMDsgayA8IG5vZGVzW2pdLm51bXBhdGhz OyBrKyspIHsKKwkJCQlmcmVlKG5vZGVzW2pdLnBhdGhzW2tdKTsKKwkJCX0K KwkJCWZyZWUobm9kZXNbal0ucGF0aHMpOworCQl9CisKKwkJZnJlZShub2Rl cyk7CisJfQorCWZyZWUobm9kZWhhc2gpOworfQorCitzdGF0aWMgbmxpbmtf dAorYWRkX3BhdGgoCisJYmlnbm9kZV90CSpub2RlLAorCWNvbnN0IGNoYXIJ KnBhdGgpCit7CisJbm9kZS0+cGF0aHMgPSByZWFsbG9jKG5vZGUtPnBhdGhz LAorCQkJICAgICAgc2l6ZW9mKGNoYXIgKikgKiAobm9kZS0+bnVtcGF0aHMg KyAxKSk7CisJaWYgKG5vZGUtPnBhdGhzID09IE5VTEwpIHsKKwkJZXJyX25v bWVtKCk7CisJCWV4aXQoMSk7CisJfQorCisJbm9kZS0+cGF0aHNbbm9kZS0+ bnVtcGF0aHNdID0gc3RyZHVwKHBhdGgpOworCWlmIChub2RlLT5wYXRoc1tu b2RlLT5udW1wYXRoc10gPT0gTlVMTCkgeworCQllcnJfbm9tZW0oKTsKKwkJ ZXhpdCgxKTsKKwl9CisKKwlub2RlLT5udW1wYXRocysrOworCWlmIChub2Rl LT5udW1wYXRocyA+IGhpZ2hlc3RfbnVtcGF0aHMpCisJCWhpZ2hlc3RfbnVt cGF0aHMgPSBub2RlLT5udW1wYXRoczsKKworCXJldHVybiBub2RlLT5udW1w YXRoczsKK30KKworc3RhdGljIGJpZ25vZGVfdCAqCithZGRfbm9kZSgKKwlu b2RlbGlzdF90CSpsaXN0LAorCXhmc19pbm9fdAlpbm8sCisJaW50CQlmdHdf ZmxhZ3MsCisJY29uc3QgY2hhcgkqcGF0aCkKK3sKKwliaWdub2RlX3QJKm5v ZGU7CisKKwlpZiAobGlzdC0+bGFzdG5vZGUgPj0gbGlzdC0+bGlzdGxlbikg eworCQlsaXN0LT5saXN0bGVuICs9IDUwMDsKKwkJbGlzdC0+bm9kZXMgPSBy ZWFsbG9jKGxpc3QtPm5vZGVzLAorCQkJCQlzaXplb2YoYmlnbm9kZV90KSAq IGxpc3QtPmxpc3RsZW4pOworCQlpZiAobGlzdC0+bm9kZXMgPT0gTlVMTCkg eworCQkJZXJyX25vbWVtKCk7CisJCQlyZXR1cm4gTlVMTDsKKwkJfQorCX0K KworCW5vZGUgPSBsaXN0LT5ub2RlcyArIGxpc3QtPmxhc3Rub2RlOworCisJ bm9kZS0+aW5vID0gaW5vOworCW5vZGUtPmZ0d19mbGFncyA9IGZ0d19mbGFn czsKKwlub2RlLT5wYXRocyA9IE5VTEw7CisJbm9kZS0+bnVtcGF0aHMgPSAw OworCWFkZF9wYXRoKG5vZGUsIHBhdGgpOworCisJbGlzdC0+bGFzdG5vZGUr KzsKKworCXJldHVybiBub2RlOworfQorCitzdGF0aWMgYmlnbm9kZV90ICoK K2ZpbmRfbm9kZSgKKwl4ZnNfaW5vX3QJaW5vKQoreworCWludAkJaTsKKwlu b2RlbGlzdF90CSpub2RlbGlzdDsKKwliaWdub2RlX3QJKm5vZGVzOworCisJ bm9kZWxpc3QgPSBOSF9IQVNIKGlubyk7CisJbm9kZXMgPSBub2RlbGlzdC0+ bm9kZXM7CisKKwlmb3IoaSA9IDA7IGkgPCBub2RlbGlzdC0+bGFzdG5vZGU7 IGkrKykgeworCQlpZiAobm9kZXNbaV0uaW5vID09IGlubykgeworCQkJcmV0 dXJuICZub2Rlc1tpXTsKKwkJfQorCX0KKworCXJldHVybiBOVUxMOworfQor CitzdGF0aWMgYmlnbm9kZV90ICoKK2FkZF9ub2RlX3BhdGgoCisJeGZzX2lu b190CWlubywKKwlpbnQJCWZ0d19mbGFncywKKwljb25zdCBjaGFyCSpwYXRo KQoreworCW5vZGVsaXN0X3QJKm5vZGVsaXN0OworCWJpZ25vZGVfdAkqbm9k ZTsKKworCWxvZ19tZXNzYWdlKExPR19OSVRUWSwgImFkZF9ub2RlX3BhdGg6 IGlubyAlbGx1LCBwYXRoICVzIiwgaW5vLCBwYXRoKTsKKworCW5vZGUgPSBm aW5kX25vZGUoaW5vKTsKKwlpZiAobm9kZSA9PSBOVUxMKSB7CisJCW5vZGVs aXN0ID0gTkhfSEFTSChpbm8pOworCQlyZXR1cm4gYWRkX25vZGUobm9kZWxp c3QsIGlubywgZnR3X2ZsYWdzLCBwYXRoKTsKKwl9CisKKwlhZGRfcGF0aChu b2RlLCBwYXRoKTsKKwlyZXR1cm4gbm9kZTsKK30KKworc3RhdGljIHZvaWQK K2R1bXBfbm9kZSgKKwljaGFyCQkqbXNnLAorCWJpZ25vZGVfdAkqbm9kZSkK K3sKKwlpbnQJCWs7CisKKwlpZiAobG9nX2xldmVsIDwgTE9HX0RFQlVHKQor CQlyZXR1cm47CisKKwlsb2dfbWVzc2FnZShMT0dfREVCVUcsICIlczogJWxs dSAlbGx1ICVzIiwgbXNnLCBub2RlLT5pbm8sCisJCQlub2RlLT5udW1wYXRo cywgbm9kZS0+cGF0aHNbMF0pOworCisJZm9yIChrID0gMTsgayA8IG5vZGUt Pm51bXBhdGhzOyBrKyspCisJCWxvZ19tZXNzYWdlKExPR19ERUJVRywgIlx0 JXMiLCBub2RlLT5wYXRoc1trXSk7Cit9CisKK3N0YXRpYyB2b2lkCitkdW1w X25vZGVoYXNoKHZvaWQpCit7CisJaW50CQlpLCBqOworCisJaWYgKGxvZ19s ZXZlbCA8IExPR19OSVRUWSkKKwkJcmV0dXJuOworCisJZm9yIChpID0gMDsg aSA8IE5IX0JVQ0tFVFM7IGkrKykgeworCQliaWdub2RlX3QJKm5vZGVzID0g bm9kZWhhc2hbaV0ubm9kZXM7CisJCWZvciAoaiA9IDA7IGogPCBub2RlaGFz aFtpXS5sYXN0bm9kZTsgaisrLCBub2RlcysrKQorCQkJZHVtcF9ub2RlKCJu b2RlaGFzaCIsIG5vZGVzKTsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2Zvcl9h bGxfbm9kZXMoCisJaW50CQkoKmZuKShiaWdub2RlX3QgKm5vZGUpLAorCWlu dAkJZnR3X2ZsYWdzLAorCWludAkJcXVpdF9vbl9lcnJvcikKK3sKKwlpbnQJ CWk7CisJaW50CQlqOworCWludAkJcnZhbCA9IDA7CisKKwlmb3IgKGkgPSAw OyBpIDwgTkhfQlVDS0VUUzsgaSsrKSB7CisJCWJpZ25vZGVfdAkqbm9kZXMg PSBub2RlaGFzaFtpXS5ub2RlczsKKworCQlmb3IgKGogPSAwOyBqIDwgbm9k ZWhhc2hbaV0ubGFzdG5vZGU7IGorKywgbm9kZXMrKykgeworCQkJaWYgKG5v ZGVzLT5mdHdfZmxhZ3MgPT0gZnR3X2ZsYWdzKSB7CisJCQkJcnZhbCA9IGZu KG5vZGVzKTsKKwkJCQlpZiAocnZhbCAmJiBxdWl0X29uX2Vycm9yKQorCQkJ CQlnb3RvIHF1aXQ7CisJCQl9CisJCX0KKwl9CisKK3F1aXQ6CisJcmV0dXJu IHJ2YWw7Cit9CisKKy8qCisgKiBBZGRzIGFwcHJvcHJpYXRlIGZpbGVzIHRv IHRoZSBpbm9kZSBoYXNoIHRhYmxlCisgKi8KK3N0YXRpYyBpbnQKK25mdHdf YWRkbm9kZXMoCisJY29uc3QgY2hhcgkqcGF0aCwKKwljb25zdCBzdHJ1Y3Qg c3RhdDY0ICpzdCwKKwlpbnQJCWZsYWdzLAorCXN0cnVjdCBGVFcJKnNudGZ3 KQoreworCWlmIChzdC0+c3RfaW5vIDw9IFhGU19NQVhJTlVNQkVSXzMyICYm ICFmb3JjZV9hbGwpCisJCXJldHVybiAwOworCisJaWYgKGZsYWdzID09IEZU V19GKQorCQludW1maWxlbm9kZXMrKzsKKwllbHNlIGlmIChmbGFncyA9PSBG VFdfRCkKKwkJbnVtZGlybm9kZXMrKzsKKwllbHNlIGlmIChmbGFncyA9PSBG VFdfU0wpCisJCW51bXNsaW5rbm9kZXMrKzsKKwllbHNlCisJCXJldHVybiAw OworCisJYWRkX25vZGVfcGF0aChzdC0+c3RfaW5vLCBmbGFncywgcGF0aCk7 CisKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIEF0dHJpYnV0ZSBjbG9uaW5n IGNvZGUgLSBtb3N0IG9mIHRoaXMgaXMgaGVyZSBiZWNhdXNlIGF0dHJfY29w eSBkb2VzIG5vdAorICogbGV0IHVzIHBpY2sgYW5kIGNob29zZSB3aGljaCBh dHRyaWJ1dGVzIHdlIHdhbnQgdG8gY29weS4KKyAqLworCithdHRyX211bHRp b3BfdAlhdHRyX29wc1tBVFRSX01BWF9NVUxUSU9QU107CisKKy8qCisgKiBH cmFiIGF0dHJpYnV0ZXMgc3BlY2lmaWVkIGluIGF0dHJfb3BzIGZyb20gc291 cmNlIGZpbGUgYW5kIHdyaXRlIHRoZW0KKyAqIG91dCBvbiB0aGUgZGVzdGlu YXRpb24gZmlsZS4KKyAqLworCitzdGF0aWMgaW50CithdHRyX3JlcGxpY2F0 ZSgKKwljaGFyCQkqc291cmNlLAorCWNoYXIJCSp0YXJnZXQsCisJaW50CQlj b3VudCkKK3sKKwlpbnQJCWosIGs7CisKKwlpZiAoYXR0cl9tdWx0aShzb3Vy Y2UsIGF0dHJfb3BzLCBjb3VudCwgQVRUUl9ET05URk9MTE9XKSA8IDApCisJ CXJldHVybiAtMTsKKworCWZvciAoayA9IDA7IGsgPCBjb3VudDsgaysrKSB7 CisJCWlmIChhdHRyX29wc1trXS5hbV9lcnJvcikgeworCQkJZXJyX21lc3Nh Z2UoXygiRXJyb3IgJWQgZ2V0dGluZyBhdHRyaWJ1dGUiKSwKKwkJCQkJYXR0 cl9vcHNba10uYW1fZXJyb3IpOworCQkJYnJlYWs7CisJCX0KKwkJYXR0cl9v cHNba10uYW1fb3Bjb2RlID0gQVRUUl9PUF9TRVQ7CisJfQorCWlmIChhdHRy X211bHRpKHRhcmdldCwgYXR0cl9vcHMsIGssIEFUVFJfRE9OVEZPTExPVykg PCAwKQorCQllcnJfbWVzc2FnZSgib24gYXR0cl9tdWx0aWYgc2V0Iik7CisJ Zm9yIChqID0gMDsgaiA8IGs7IGorKykgeworCQlpZiAoYXR0cl9vcHNbal0u YW1fZXJyb3IpIHsKKwkJCWVycl9tZXNzYWdlKF8oIkVycm9yICVkIHNldHRp bmcgYXR0cmlidXRlIiksCisJCQkJCWF0dHJfb3BzW2pdLmFtX2Vycm9yKTsK KwkJCXJldHVybiAtMTsKKwkJfQorCX0KKworCXJldHVybiAwOworfQorCisv KgorICogQ29weSBhbGwgdGhlIGF0dHJpYnV0ZXMgc3BlY2lmaWVkIGZyb20g c3JjIHRvIGRzdC4KKyAqLworCitzdGF0aWMgaW50CithdHRyX2Nsb25lX2Nv cHkoCisJY2hhcgkJKnNvdXJjZSwKKwljaGFyCQkqdGFyZ2V0LAorCWNoYXIJ CSpsaXN0X2J1ZiwKKwljaGFyCQkqYXR0cl9idWYsCisJaW50CQlidWZfbGVu LAorCWludAkJZmxhZ3MpCit7CisgICAgICAgIGF0dHJsaXN0X3QgCSphbGlz dDsKKyAgICAgICAgYXR0cmxpc3RfZW50X3QJKmF0dHI7CisgICAgICAgIGF0 dHJsaXN0X2N1cnNvcl90IGN1cnNvcjsKKyAgICAgICAgaW50CQlzcGFjZSwg aSwgajsKKwljaGFyCQkqcHRyOworCisgICAgICAgIGJ6ZXJvKChjaGFyICop JmN1cnNvciwgc2l6ZW9mKGN1cnNvcikpOworICAgICAgICBkbyB7CisgICAg ICAgICAgICAgICAgaWYgKGF0dHJfbGlzdChzb3VyY2UsIGxpc3RfYnVmLCBB VFRSQlVGU0laRSwKKyAgICAgICAgICAgICAgICAJCWZsYWdzIHwgQVRUUl9E T05URk9MTE9XLCAmY3Vyc29yKSA8IDApIHsKKwkJCWVycl9tZXNzYWdlKCJv biBhdHRyX2xpc3RmIik7CisgICAgICAgICAgICAgICAgICAgICAgICByZXR1 cm4gLTE7CisJCX0KKworICAgICAgICAgICAgICAgIGFsaXN0ID0gKGF0dHJs aXN0X3QgKilsaXN0X2J1ZjsKKworCQlzcGFjZSA9IGJ1Zl9sZW47CisJCXB0 ciA9IGF0dHJfYnVmOworICAgICAgICAgICAgICAgIGZvciAoaiA9IDAsIGkg PSAwOyBpIDwgYWxpc3QtPmFsX2NvdW50OyBpKyspIHsKKyAgICAgICAgICAg ICAgICAgICAgICAgIGF0dHIgPSBBVFRSX0VOVFJZKGxpc3RfYnVmLCBpKTsK KwkJCWlmIChzcGFjZSA8IGF0dHItPmFfdmFsdWVsZW4pIHsKKwkJCQlpZiAo YXR0cl9yZXBsaWNhdGUoc291cmNlLCB0YXJnZXQsIGopIDwgMCkKKwkJCQkJ cmV0dXJuIC0xOworCQkJCWogPSAwOworCQkJCXNwYWNlID0gYnVmX2xlbjsK KwkJCQlwdHIgPSBhdHRyX2J1ZjsKKwkJCX0KKwkJCWF0dHJfb3BzW2pdLmFt X29wY29kZSA9IEFUVFJfT1BfR0VUOworCQkJYXR0cl9vcHNbal0uYW1fYXR0 cm5hbWUgPSBhdHRyLT5hX25hbWU7CisJCQlhdHRyX29wc1tqXS5hbV9hdHRy dmFsdWUgPSBwdHI7CisJCQlhdHRyX29wc1tqXS5hbV9sZW5ndGggPSAoaW50 KSBhdHRyLT5hX3ZhbHVlbGVuOworCQkJYXR0cl9vcHNbal0uYW1fZmxhZ3Mg PSBmbGFnczsKKwkJCWF0dHJfb3BzW2pdLmFtX2Vycm9yID0gMDsKKwkJCWor KzsKKwkJCXB0ciArPSBhdHRyLT5hX3ZhbHVlbGVuOworCQkJc3BhY2UgLT0g YXR0ci0+YV92YWx1ZWxlbjsKKyAgICAgICAgICAgICAgICB9CisKKwkJbG9n X21lc3NhZ2UoTE9HX05JVFRZLCAiY29weWluZyBhdHRyaWJ1dGUgJWQiLCBp KTsKKworCQlpZiAoaikgeworCQkJaWYgKGF0dHJfcmVwbGljYXRlKHNvdXJj ZSwgdGFyZ2V0LCBqKSA8IDApCisJCQkJcmV0dXJuIC0xOworCQl9CisKKyAg ICAgICAgfSB3aGlsZSAoYWxpc3QtPmFsX21vcmUpOworCisgICAgICAgIHJl dHVybiAwOworfQorCitzdGF0aWMgaW50CitjbG9uZV9hdHRyaWJzKAorCWNo YXIJCSpzb3VyY2UsCisJY2hhcgkJKnRhcmdldCkKK3sKKwljaGFyCQlsaXN0 X2J1ZltBVFRSQlVGU0laRV07CisJY2hhcgkJKmF0dHJfYnVmOworCWludAkJ cnZhbDsKKworCWF0dHJfYnVmID0gbWFsbG9jKEFUVFJfTUFYX1ZBTFVFTEVO ICogMik7CisJaWYgKGF0dHJfYnVmID09IE5VTEwpIHsKKwkJZXJyX25vbWVt KCk7CisJCXJldHVybiAtMTsKKwl9CisJcnZhbCA9IGF0dHJfY2xvbmVfY29w eShzb3VyY2UsIHRhcmdldCwgbGlzdF9idWYsIGF0dHJfYnVmLAorCQkJQVRU Ul9NQVhfVkFMVUVMRU4gKiAyLCAwKTsKKwlpZiAocnZhbCA9PSAwKQorCQly dmFsID0gYXR0cl9jbG9uZV9jb3B5KHNvdXJjZSwgdGFyZ2V0LCBsaXN0X2J1 ZiwgYXR0cl9idWYsCisJCQkJQVRUUl9NQVhfVkFMVUVMRU4gKiAyLCBBVFRS X1JPT1QpOworCWlmIChydmFsID09IDApCisJCXJ2YWwgPSBhdHRyX2Nsb25l X2NvcHkoc291cmNlLCB0YXJnZXQsIGxpc3RfYnVmLCBhdHRyX2J1ZiwKKwkJ CQlBVFRSX01BWF9WQUxVRUxFTiAqIDIsIEFUVFJfU0VDVVJFKTsKKwlmcmVl KGF0dHJfYnVmKTsKKwlyZXR1cm4gcnZhbDsKK30KKworc3RhdGljIGludAor ZHVwX2F0dHJpYnV0ZXMoCisJY2hhcgkJKnNvdXJjZSwKKwlpbnQJCXNmZCwK KwljaGFyCQkqdGFyZ2V0LAorCWludAkJdGZkKQoreworCXN0cnVjdCBzdGF0 NjQJc3Q7CisJc3RydWN0IHRpbWV2YWwJdHZbMl07CisJc3RydWN0IGZzeGF0 dHIJZnN4OworCisJaWYgKGZzdGF0NjQoc2ZkLCAmc3QpIDwgMCkgeworCQll cnJfc3RhdChzb3VyY2UpOworCQlyZXR1cm4gLTE7CisJfQorCisJaWYgKHhm c19nZXR4YXR0cihzZmQsICZmc3gpIDwgMCkgeworCQllcnJfc3RhdChzb3Vy Y2UpOworCQlyZXR1cm4gLTE7CisJfQorCisJdHZbMF0udHZfc2VjID0gc3Qu c3RfYXRpbS50dl9zZWM7CisJdHZbMF0udHZfdXNlYyA9IHN0LnN0X2F0aW0u dHZfbnNlYyAvIDEwMDA7CisJdHZbMV0udHZfc2VjID0gc3Quc3RfbXRpbS50 dl9zZWM7CisJdHZbMV0udHZfdXNlYyA9IHN0LnN0X210aW0udHZfbnNlYyAv IDEwMDA7CisKKwlpZiAoZnV0aW1lcyh0ZmQsIHR2KSA8IDApCisJCWVycl9t ZXNzYWdlKF8oIiVzOiBDYW5ub3QgdXBkYXRlIHRhcmdldCB0aW1lcyIpLCB0 YXJnZXQpOworCisJaWYgKGZjaG93bih0ZmQsIHN0LnN0X3VpZCwgc3Quc3Rf Z2lkKSA8IDApIHsKKwkJZXJyX21lc3NhZ2UoXygiJXM6IENhbm5vdCBjaGFu Z2UgdGFyZ2V0IG93bmVyc2hpcCB0byAiCisJCQkJInVpZCglZCkgZ2lkKCVk KSIpLCB0YXJnZXQsCisJCQkJc3Quc3RfdWlkLCBzdC5zdF9naWQpOworCisJ CWlmIChmY2htb2QodGZkLCBzdC5zdF9tb2RlICYgfihTX0lTVUlEIHwgU19J U0dJRCkpIDwgMCkKKwkJCWVycl9tZXNzYWdlKF8oIiVzOiBDYW5ub3QgY2hh bmdlIHRhcmdldCBtb2RlICIKKwkJCQkJInRvICglbykiKSwgdGFyZ2V0LCBz dC5zdF9tb2RlKTsKKwl9IGVsc2UgaWYgKGZjaG1vZCh0ZmQsIHN0LnN0X21v ZGUpIDwgMCkKKwkJZXJyX21lc3NhZ2UoXygiJXM6IENhbm5vdCBjaGFuZ2Ug dGFyZ2V0IG1vZGUgdG8gKCVvKSIpLAorCQkJCXRhcmdldCwgc3Quc3RfbW9k ZSk7CisKKwlpZiAoeGZzX3NldHhhdHRyKHRmZCwgJmZzeCkgPCAwKQorCQll cnJfbWVzc2FnZShfKCIlczogQ2FubmV0IHNldCB0YXJnZXQgZXh0ZW5kZWQg IgorCQkJCSJhdHRyaWJ1dGVzIiksIHRhcmdldCk7CisKKwlyZXR1cm4gY2xv bmVfYXR0cmlicyhzb3VyY2UsIHRhcmdldCk7Cit9CisKK3N0YXRpYyBpbnQK K21vdmVfZGlyZW50cygKKwljaGFyCQkqc3JjcGF0aCwKKwljaGFyCQkqdGFy Z2V0cGF0aCwKKwlpbnQJCSptb3ZlX2NvdW50KQoreworCWludAkJcnZhbCA9 IDA7CisJRElSCQkqc3JjZDsKKwlzdHJ1Y3QgZGlyZW50NjQJKmRwOworCWNo YXIJCXNyY25hbWVbUEFUSF9NQVhdOworCWNoYXIJCXRhcmdldG5hbWVbUEFU SF9NQVhdOworCisJKm1vdmVfY291bnQgPSAwOworCisJc3JjZCA9IG9wZW5k aXIoc3JjcGF0aCk7CisJaWYgKHNyY2QgPT0gTlVMTCkgeworCQllcnJfb3Bl bihzcmNwYXRoKTsKKwkJcmV0dXJuIDE7CisJfQorCisJd2hpbGUgKChkcCA9 IHJlYWRkaXI2NChzcmNkKSkgIT0gTlVMTCkgeworCQlpZiAoZHAtPmRfaW5v ID09IDAgfHwgIXN0cmNtcChkcC0+ZF9uYW1lLCAiLiIpIHx8CisJCQkJIXN0 cmNtcChkcC0+ZF9uYW1lLCAiLi4iKSkKKwkJCWNvbnRpbnVlOworCisJCWlm IChzdHJsZW4oc3JjcGF0aCkgKyAxICsgc3RybGVuKGRwLT5kX25hbWUpID49 CisJCQkJc2l6ZW9mKHNyY25hbWUpIC0gMSkgeworCisJCQllcnJfbWVzc2Fn ZShfKCIlcy8lczogTmFtZSB0b28gbG9uZyIpLCBzcmNwYXRoLAorCQkJCQlk cC0+ZF9uYW1lKTsKKwkJCXJ2YWwgPSAxOworCQkJZ290byBxdWl0OworCQl9 CisKKwkJc3ByaW50ZihzcmNuYW1lLCAiJXMvJXMiLCBzcmNwYXRoLCBkcC0+ ZF9uYW1lKTsKKwkJc3ByaW50Zih0YXJnZXRuYW1lLCAiJXMvJXMiLCB0YXJn ZXRwYXRoLCBkcC0+ZF9uYW1lKTsKKworCQlydmFsID0gcmVuYW1lKHNyY25h bWUsIHRhcmdldG5hbWUpOworCQlpZiAocnZhbCAhPSAwKSB7CisJCQllcnJf bWVzc2FnZShfKCJmYWlsZWQgdG8gcmVuYW1lOiBcJyVzXCcgdG8gXCclc1wn IiksCisJCQkJCXNyY25hbWUsIHRhcmdldG5hbWUpOworCQkJZ290byBxdWl0 OworCQl9CisKKwkJbG9nX21lc3NhZ2UoTE9HX0RFQlVHLCAicmVuYW1lICVz IC0+ICVzIiwgc3JjbmFtZSwgdGFyZ2V0bmFtZSk7CisKKwkJKCptb3ZlX2Nv dW50KSsrOworCX0KKworcXVpdDoKKwljbG9zZWRpcihzcmNkKTsKKwlyZXR1 cm4gcnZhbDsKK30KKworc3RhdGljIGludAorcHJvY2Vzc19kaXIoCisJYmln bm9kZV90CSpub2RlKQoreworCWludAkJc2ZkID0gLTE7CisJaW50CQl0ZmQg PSAtMTsKKwlpbnQJCXRhcmdldGZkID0gLTE7CisJaW50CQlydmFsID0gMDsK KwlpbnQJCW1vdmVfY291bnQgPSAwOworCWNoYXIJCSpzcmNuYW1lID0gTlVM TDsKKwljaGFyCQkqcG5hbWUgPSBOVUxMOworCXN0cnVjdCBzdGF0NjQJczE7 CisJc3RydWN0IGZzeGF0dHIgIGZzeDsKKwljaGFyCQl0YXJnZXRbUEFUSF9N QVhdID0gIiI7CisKKwlTRVRfUEhBU0UoRElSX1BIQVNFKTsKKworCWR1bXBf bm9kZSgiZGlyZWN0b3J5Iiwgbm9kZSk7CisKKwljdXJfbm9kZSA9IG5vZGU7 CisJc3JjbmFtZSA9IG5vZGUtPnBhdGhzWzBdOworCisJaWYgKHN0YXQ2NChz cmNuYW1lLCAmczEpIDwgMCkgeworCQlpZiAoZXJybm8gIT0gRU5PRU5UKSB7 CisJCQllcnJfc3RhdChzcmNuYW1lKTsKKwkJCWdsb2JhbF9ydmFsIHw9IDI7 CisJCX0KKwkJZ290byBxdWl0OworCX0KKwlpZiAoczEuc3RfaW5vIDw9IFhG U19NQVhJTlVNQkVSXzMyICYmICFmb3JjZV9hbGwpIHsKKwkJLyoKKwkJICog VGhpcyBkaXJlY3RvcnkgaGFzIGFscmVhZHkgY2hhbmdlZCBpbm8ncywgcHJv YmFibHkgZHVlCisJCSAqIHRvIGJlaW5nIG1vdmVkIGR1cmluZyBwcm9jZXNz aW5nIG9mIGEgcGFyZW50IGRpcmVjdG9yeS4KKwkJICovCisJCWxvZ19tZXNz YWdlKExPR19ERUJVRywgInByb2Nlc3NfZGlyOiBza2lwcGluZyAlcyIsIHNy Y25hbWUpOworCQlnb3RvIHF1aXQ7CisJfQorCisJcnZhbCA9IDE7CisKKwlz ZmQgPSBvcGVuKHNyY25hbWUsIE9fUkRPTkxZKTsKKwlpZiAoc2ZkIDwgMCkg eworCQllcnJfb3BlbihzcmNuYW1lKTsKKwkJZ290byBxdWl0OworCX0KKwor CWlmICghcGxhdGZvcm1fdGVzdF94ZnNfZmQoc2ZkKSkgeworCQllcnJfbm90 X3hmcyhzcmNuYW1lKTsKKwkJZ290byBxdWl0OworCX0KKworCWlmICh4ZnNf Z2V0eGF0dHIoc2ZkLCAmZnN4KSA8IDApIHsKKwkJZXJyX21lc3NhZ2UoXygi ZmFpbGVkIHRvIGdldCBpbm9kZSBhdHRyczogJXMiKSwgc3JjbmFtZSk7CisJ CWdvdG8gcXVpdDsKKwl9CisJaWYgKGZzeC5mc3hfeGZsYWdzICYgKFhGU19Y RkxBR19JTU1VVEFCTEUgfCBYRlNfWEZMQUdfQVBQRU5EKSkgeworCQllcnJf bWVzc2FnZShfKCIlczogaW1tdXRhYmxlL2FwcGVuZCwgaWdub3JpbmciKSwg c3JjbmFtZSk7CisJCWdsb2JhbF9ydmFsIHw9IDI7CisJCXJ2YWwgPSAwOwor CQlnb3RvIHF1aXQ7CisJfQorCisJLyogbWtkaXIgcGFyZW50L3RhcmdldCAq LworCXBuYW1lID0gc3RyZHVwKHNyY25hbWUpOworCWlmIChwbmFtZSA9PSBO VUxMKSB7CisJCWVycl9ub21lbSgpOworCQlnb3RvIHF1aXQ7CisJfQorCWRp cm5hbWUocG5hbWUpOworCXNwcmludGYodGFyZ2V0LCAiJXMvJXNYWFhYWFgi LCBwbmFtZSwgY21kX3ByZWZpeCk7CisJaWYgKG1rZHRlbXAodGFyZ2V0KSA9 PSBOVUxMKSB7CisJCWVycl9tZXNzYWdlKF8oIlVuYWJsZSB0byBjcmVhdGUg ZGlyZWN0b3J5IGNvcHk6ICVzIiksIHNyY25hbWUpOworCQlnb3RvIHF1aXQ7 CisJfQorCVNFVF9QSEFTRShESVJfUEhBU0VfMSk7CisKKwljdXJfdGFyZ2V0 ID0gc3RyZHVwKHRhcmdldCk7CisJaWYgKCFjdXJfdGFyZ2V0KSB7CisJCWVy cl9ub21lbSgpOworCQlnb3RvIHF1aXQ7CisJfQorCisJc3ByaW50Zih0YXJn ZXQsICIlcy8lc1hYWFhYWCIsIHBuYW1lLCBjbWRfcHJlZml4KTsKKwlpZiAo bWtkdGVtcCh0YXJnZXQpID09IE5VTEwpIHsKKwkJZXJyX21lc3NhZ2UoXygi dW5hYmxlIHRvIGNyZWF0ZSB0bXAgZGlyZWN0b3J5IGNvcHkiKSk7CisJCWdv dG8gcXVpdDsKKwl9CisJU0VUX1BIQVNFKERJUl9QSEFTRV8yKTsKKworCWN1 cl90ZW1wID0gc3RyZHVwKHRhcmdldCk7CisJaWYgKCFjdXJfdGVtcCkgewor CQllcnJfbm9tZW0oKTsKKwkJZ290byBxdWl0OworCX0KKworCXRmZCA9IG9w ZW4oY3VyX3RlbXAsIE9fUkRPTkxZKTsKKwlpZiAodGZkIDwgMCkgeworCQll cnJfb3BlbihjdXJfdGVtcCk7CisJCWdvdG8gcXVpdDsKKwl9CisKKwl0YXJn ZXRmZCA9IG9wZW4oY3VyX3RhcmdldCwgT19SRE9OTFkpOworCWlmICh0ZmQg PCAwKSB7CisJCWVycl9vcGVuKGN1cl90YXJnZXQpOworCQlnb3RvIHF1aXQ7 CisJfQorCisKKwkvKiBjb3B5IHRpbWVzdGFtcHMsIGF0dHJpYnMgYW5kIEVB cywgdG8gY3VyX3RlbXAgKi8KKwlydmFsID0gZHVwX2F0dHJpYnV0ZXMoc3Jj bmFtZSwgc2ZkLCBjdXJfdGVtcCwgdGZkKTsKKwlpZiAocnZhbCAhPSAwKSB7 CisJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBkdXBsaWNhdGUgZGlyZWN0 b3J5IGF0dHJpYnV0ZXM6ICVzIiksCisJCQkgICAgc3JjbmFtZSk7CisJCWdv dG8gcXVpdF91bmxpbms7CisJfQorCisJU0VUX1BIQVNFKERJUl9QSEFTRV8z KTsKKworCS8qIG1vdmUgc3JjIGRpcmVudHMgdG8gY3VyX3RhcmdldCAodGhp cyBjaGFuZ2VzIHRpbWVzdGFtcHMgb24gc3JjKSAqLworCXJ2YWwgPSBtb3Zl X2RpcmVudHMoc3JjbmFtZSwgY3VyX3RhcmdldCwgJm1vdmVfY291bnQpOwor CWlmIChydmFsICE9IDApIHsKKwkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRv IG1vdmUgZGlyZWN0b3J5IGNvbnRlbnRzOiAlcyB0byAlcyIpLAorCQkJCXNy Y25hbWUsIGN1cl90YXJnZXQpOworCQkvKiB1aCBvaCwgbW92ZSBldmVyeXRo aW5nIGJhY2suLi4gKi8KKwkJaWYgKG1vdmVfY291bnQgPiAwKQorCQkJZ290 byBxdWl0X3VuZG87CisJfQorCisJU0VUX1BIQVNFKERJUl9QSEFTRV80KTsK KworCS8qIGNvcHkgdGltZXN0YW1wcywgYXR0cmlicyBhbmQgRUFzIGZyb20g Y3VyX3RlbXAgdG8gY3VyX3RhcmdldCAqLworCXJ2YWwgPSBkdXBfYXR0cmli dXRlcyhjdXJfdGVtcCwgdGZkLCBjdXJfdGFyZ2V0LCB0YXJnZXRmZCk7CisJ aWYgKHJ2YWwgIT0gMCkgeworCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8g ZHVwbGljYXRlIGRpcmVjdG9yeSBhdHRyaWJ1dGVzOiAlcyIpLAorCQkJCWN1 cl90ZW1wKTsKKwkJZ290byBxdWl0X3VubGluazsKKwl9CisKKwlTRVRfUEhB U0UoRElSX1BIQVNFXzUpOworCisJLyogcm1kaXIgc3JjICovCisJcnZhbCA9 IHJtZGlyKHNyY25hbWUpOworCWlmIChydmFsICE9IDApIHsKKwkJZXJyX21l c3NhZ2UoXygidW5hYmxlIHRvIHJlbW92ZSBkaXJlY3Rvcnk6ICVzIiksIHNy Y25hbWUpOworCQlnb3RvIHF1aXRfdW5kbzsKKwl9CisKKwlTRVRfUEhBU0Uo RElSX1BIQVNFXzYpOworCisJcnZhbCA9IHJtZGlyKGN1cl90ZW1wKTsKKwlp ZiAocnZhbCAhPSAwKQorCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8gcmVt b3ZlIHRtcCBkaXJlY3Rvcnk6ICVzIiksIGN1cl90ZW1wKTsKKworCVNFVF9Q SEFTRShESVJfUEhBU0VfNyk7CisKKwkvKiByZW5hbWUgY3VyX3RhcmdldCBz cmMgKi8KKwlydmFsID0gcmVuYW1lKGN1cl90YXJnZXQsIHNyY25hbWUpOwor CWlmIChydmFsICE9IDApIHsKKwkJLyoKKwkJICogd2UgY2FuJ3QgYWJvcnQg c2luY2UgdGhlIHNyYyBkaXIgaXMgbm93IGdvbmUuCisJCSAqIGxldCB0aGUg YWRtaW4gY2xlYW4gdGhpcyBvbmUgdXAKKwkJICovCisJCWVycl9tZXNzYWdl KF8oInVuYWJsZSB0byByZW5hbWUgZGlyZWN0b3J5OiAlcyB0byAlcyIpLAor CQkJCWN1cl90YXJnZXQsIHNyY25hbWUpOworCX0KKwlnb3RvIHF1aXQ7CisK KyBxdWl0X3VuZG86CisJaWYgKG1vdmVfZGlyZW50cyhjdXJfdGFyZ2V0LCBz cmNuYW1lLCAmbW92ZV9jb3VudCkgIT0gMCkgeworCQkvKiBvaCwgZGVhciBs b3JkLi4uIGxldCB0aGUgYWRtaW4gY2xlYW4gdGhpcyBvbmUgdXAgKi8KKwkJ ZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIG1vdmUgZGlyZWN0b3J5IGNvbnRl bnRzIGJhY2s6ICVzIHRvICVzIiksCisJCQkJY3VyX3RhcmdldCwgc3JjbmFt ZSk7CisJCWdvdG8gcXVpdDsKKwl9CisJU0VUX1BIQVNFKERJUl9QSEFTRV8z KTsKKworIHF1aXRfdW5saW5rOgorCXJtZGlyKGN1cl90YXJnZXQpOworCXJt ZGlyKGN1cl90ZW1wKTsKKworIHF1aXQ6CisKKwlTRVRfUEhBU0UoRElSX1BI QVNFKTsKKworCWlmIChzZmQgPj0gMCkKKwkJY2xvc2Uoc2ZkKTsKKwlpZiAo dGZkID49IDApCisJCWNsb3NlKHRmZCk7CisJaWYgKHRhcmdldGZkID49IDAp CisJCWNsb3NlKHRhcmdldGZkKTsKKworCWZyZWUocG5hbWUpOworCWZyZWUo Y3VyX3RhcmdldCk7CisJZnJlZShjdXJfdGVtcCk7CisKKwljdXJfdGFyZ2V0 ID0gTlVMTDsKKwljdXJfdGVtcCA9IE5VTEw7CisJY3VyX25vZGUgPSBOVUxM OworCW51bWRpcnNkb25lKys7CisJcmV0dXJuIHJ2YWw7Cit9CisKK3N0YXRp YyBpbnQKK3Byb2Nlc3NfZmlsZSgKKwliaWdub2RlX3QJKm5vZGUpCit7CisJ aW50CQlzZmQgPSAtMTsKKwlpbnQJCXRmZCA9IC0xOworCWludAkJaSA9IDA7 CisJaW50CQlydmFsID0gMDsKKwlzdHJ1Y3Qgc3RhdDY0CXMxOworCWNoYXIJ CSpzcmNuYW1lID0gTlVMTDsKKwljaGFyCQkqcG5hbWUgPSBOVUxMOworCXhm c19zd2FwZXh0X3QJc3g7CisJeGZzX2JzdGF0X3QJYnN0YXRidWY7CisJc3Ry dWN0IGZzeGF0dHIgIGZzeDsKKwljaGFyCQl0YXJnZXRbUEFUSF9NQVhdID0g IiI7CisKKwlTRVRfUEhBU0UoRklMRV9QSEFTRSk7CisKKwlkdW1wX25vZGUo ImZpbGUiLCBub2RlKTsKKworCWN1cl9ub2RlID0gbm9kZTsKKwlzcmNuYW1l ID0gbm9kZS0+cGF0aHNbMF07CisKKwliemVybygmczEsIHNpemVvZihzMSkp OworCWJ6ZXJvKCZic3RhdGJ1Ziwgc2l6ZW9mKGJzdGF0YnVmKSk7CisJYnpl cm8oJnN4LCBzaXplb2Yoc3gpKTsKKworCWlmIChzdGF0NjQoc3JjbmFtZSwg JnMxKSA8IDApIHsKKwkJaWYgKGVycm5vICE9IEVOT0VOVCkgeworCQkJZXJy X3N0YXQoc3JjbmFtZSk7CisJCQlnbG9iYWxfcnZhbCB8PSAyOworCQl9CisJ CWdvdG8gcXVpdDsKKwl9CisJaWYgKHMxLnN0X2lubyA8PSBYRlNfTUFYSU5V TUJFUl8zMiAmJiAhZm9yY2VfYWxsKQorCQkvKiB0aGlzIGZpbGUgaGFzIGNo YW5nZWQsIGFuZCBubyBsb25nZXIgbmVlZHMgcHJvY2Vzc2luZyAqLworCQln b3RvIHF1aXQ7CisKKwkvKiBvcGVuIGFuZCBzeW5jIHNvdXJjZSAqLworCXNm ZCA9IG9wZW4oc3JjbmFtZSwgT19SRFdSIHwgT19ESVJFQ1QpOworCWlmIChz ZmQgPCAwKSB7CisJCWVycl9vcGVuKHNyY25hbWUpOworCQlydmFsID0gMTsK KwkJZ290byBxdWl0OworCX0KKwlpZiAoIXBsYXRmb3JtX3Rlc3RfeGZzX2Zk KHNmZCkpIHsKKwkJZXJyX25vdF94ZnMoc3JjbmFtZSk7CisJCXJ2YWwgPSAx OworCQlnb3RvIHF1aXQ7CisJfQorCWlmIChmc3luYyhzZmQpIDwgMCkgewor CQllcnJfbWVzc2FnZShfKCJzeW5jIGZhaWxlZDogJXM6ICVzIiksCisJCQkJ c3JjbmFtZSwgc3RyZXJyb3IoZXJybm8pKTsKKwkJcnZhbCA9IDE7CisJCWdv dG8gcXVpdDsKKwl9CisKKworCS8qCisJICogQ2hlY2sgaWYgYSBtYW5kYXRv cnkgbG9jayBpcyBzZXQgb24gdGhlIGZpbGUgdG8gdHJ5IGFuZAorCSAqIGF2 b2lkIGJsb2NraW5nIGluZGVmaW5pdGVseSBvbiB0aGUgcmVhZHMgbGF0ZXIu IE5vdGUgdGhhdAorCSAqIHNvbWVvbmUgY291bGQgc3RpbGwgc2V0IGEgbWFu ZGF0b3J5IGxvY2sgYWZ0ZXIgdGhpcyBjaGVjaworCSAqIGJ1dCBiZWZvcmUg YWxsIHJlYWRzIGhhdmUgY29tcGxldGVkIHRvIGJsb2NrIHhmc19yZW5vIHJl YWRzLgorCSAqIFRoaXMgY2hhbmdlIGp1c3QgY2xvc2VzIHRoZSB3aW5kb3cg YSBiaXQuCisJICovCisJaWYgKChzMS5zdF9tb2RlICYgU19JU0dJRCkgJiYg IShzMS5zdF9tb2RlICYgU19JWEdSUCkpIHsKKwkJc3RydWN0IGZsb2NrIGZs OworCisJCWZsLmxfdHlwZSA9IEZfUkRMQ0s7CisJCWZsLmxfd2hlbmNlID0g U0VFS19TRVQ7CisJCWZsLmxfc3RhcnQgPSAob2ZmX3QpMDsKKwkJZmwubF9s ZW4gPSAwOworCQlpZiAoZmNudGwoc2ZkLCBGX0dFVExLLCAmZmwpIDwgMCAp IHsKKwkJCWlmIChsb2dfbGV2ZWwgPj0gTE9HX0RFQlVHKQorCQkJCWVycl9t ZXNzYWdlKCJsb2NraW5nIGNoZWNrIGZhaWxlZDogJXMiLAorCQkJCQkJc3Jj bmFtZSk7CisJCQlnbG9iYWxfcnZhbCB8PSAyOworCQkJZ290byBxdWl0Owor CQl9CisJCWlmIChmbC5sX3R5cGUgIT0gRl9VTkxDSykgeworCQkJaWYgKGxv Z19sZXZlbCA+PSBMT0dfREVCVUcpCisJCQkJZXJyX21lc3NhZ2UoIm1hbmRh dG9yeSBsb2NrOiAlczogaWdub3JpbmciLAorCQkJCQkJc3JjbmFtZSk7CisJ CQlnbG9iYWxfcnZhbCB8PSAyOworCQkJZ290byBxdWl0OworCQl9CisJfQor CisJaWYgKHhmc19nZXR4YXR0cihzZmQsICZmc3gpIDwgMCkgeworCQllcnJf bWVzc2FnZShfKCJmYWlsZWQgdG8gZ2V0IGlub2RlIGF0dHJzOiAlcyIpLCBz cmNuYW1lKTsKKwkJcnZhbCA9IDE7CisJCWdvdG8gcXVpdDsKKwl9CisJaWYg KGZzeC5mc3hfeGZsYWdzICYgKFhGU19YRkxBR19JTU1VVEFCTEUgfCBYRlNf WEZMQUdfQVBQRU5EKSkgeworCQllcnJfbWVzc2FnZShfKCIlczogaW1tdXRh YmxlL2FwcGVuZCwgaWdub3JpbmciKSwgc3JjbmFtZSk7CisJCWdsb2JhbF9y dmFsIHw9IDI7CisJCWdvdG8gcXVpdDsKKwl9CisKKwlydmFsID0gMTsKKwor CWlmIChyZWFsdWlkICE9IDAgJiYgcmVhbHVpZCAhPSBzMS5zdF91aWQpIHsK KwkJZXJybm8gPSBFQUNDRVM7CisJCWVycl9vcGVuKHNyY25hbWUpOworCQln b3RvIHF1aXQ7CisJfQorCisJLyogY3JlYXQgdGFyZ2V0ICovCisJcG5hbWUg PSBzdHJkdXAoc3JjbmFtZSk7CisJaWYgKHBuYW1lID09IE5VTEwpIHsKKwkJ ZXJyX25vbWVtKCk7CisJCWdvdG8gcXVpdDsKKwl9CisJZGlybmFtZShwbmFt ZSk7CisJc3ByaW50Zih0YXJnZXQsICIlcy8lc1hYWFhYWCIsIHBuYW1lLCBj bWRfcHJlZml4KTsKKwl0ZmQgPSBta3N0ZW1wKHRhcmdldCk7CisJaWYgKHRm ZCA8IDApIHsKKwkJZXJyX21lc3NhZ2UoInVuYWJsZSB0byBjcmVhdGUgZmls ZSBjb3B5Iik7CisJCWdvdG8gcXVpdDsKKwl9CisJY3VyX3RhcmdldCA9IHN0 cmR1cCh0YXJnZXQpOworCWlmIChjdXJfdGFyZ2V0ID09IE5VTEwpIHsKKwkJ ZXJyX25vbWVtKCk7CisJCWdvdG8gcXVpdDsKKwl9CisKKwlTRVRfUEhBU0Uo RklMRV9QSEFTRV8xKTsKKworCS8qIFNldHVwIGRpcmVjdCBJL08gKi8KKwlp ZiAoZmNudGwodGZkLCBGX1NFVEZMLCBPX0RJUkVDVCkgPCAwICkgeworCQll cnJfbWVzc2FnZShfKCJjb3VsZCBub3Qgc2V0IE9fRElSRUNUIGZvciAlcyBv biB0bXA6ICVzIiksCisJCQkJc3JjbmFtZSwgdGFyZ2V0KTsKKwkJdW5saW5r KHRhcmdldCk7CisJCWdvdG8gcXVpdDsKKwl9CisKKwkvKiBjb3B5IGF0dHJp YnMgJiBFQXMgdG8gdGFyZ2V0ICovCisJaWYgKGR1cF9hdHRyaWJ1dGVzKHNy Y25hbWUsIHNmZCwgdGFyZ2V0LCB0ZmQpICE9IDApIHsKKwkJZXJyX21lc3Nh Z2UoXygidW5hYmxlIHRvIGR1cGxpY2F0ZSBmaWxlIGF0dHJpYnV0ZXM6ICVz IiksCisJCQkJc3JjbmFtZSk7CisJCXVubGluayh0YXJnZXQpOworCQlnb3Rv IHF1aXQ7CisJfQorCisJaWYgKHhmc19idWxrc3RhdF9zaW5nbGUoc2ZkLCAm czEuc3RfaW5vLCAmYnN0YXRidWYpIDwgMCkgeworCQllcnJfbWVzc2FnZShf KCJ1bmFibGUgdG8gYnVsa3N0YXQgc291cmNlIGZpbGU6ICVzIiksCisJCQkJ c3JjbmFtZSk7CisJCXVubGluayh0YXJnZXQpOworCQlnb3RvIHF1aXQ7CisJ fQorCisJaWYgKGJzdGF0YnVmLmJzX2lubyAhPSBzMS5zdF9pbm8pIHsKKwkJ ZXJyX21lc3NhZ2UoXygiYnVsa3N0YXQgb2Ygc291cmNlIGZpbGUgcmV0dXJu ZWQgd3JvbmcgaW5vZGU6ICVzIiksCisJCQkJc3JjbmFtZSk7CisJCXVubGlu ayh0YXJnZXQpOworCQlnb3RvIHF1aXQ7CisJfQorCisJZnRydW5jYXRlNjQo dGZkLCBic3RhdGJ1Zi5ic19zaXplKTsKKworCS8qIHN3YXBleHRlbnRzIHNy YyB0YXJnZXQgKi8KKwlzeC5zeF9zdGF0ICAgICA9IGJzdGF0YnVmOyAvKiBz dHJ1Y3QgY29weSAqLworCXN4LnN4X3ZlcnNpb24gID0gWEZTX1NYX1ZFUlNJ T047CisJc3guc3hfZmR0YXJnZXQgPSBzZmQ7CisJc3guc3hfZmR0bXAgICAg PSB0ZmQ7CisJc3guc3hfb2Zmc2V0ICAgPSAwOworCXN4LnN4X2xlbmd0aCAg ID0gYnN0YXRidWYuYnNfc2l6ZTsKKworCS8qIFN3YXAgdGhlIGV4dGVudHMg Ki8KKwlydmFsID0geGZzX3N3YXBleHQoc2ZkLCAmc3gpOworCWlmIChydmFs IDwgMCkgeworCQlpZiAobG9nX2xldmVsID49IExPR19ERUJVRykgeworCQkJ c3dpdGNoIChlcnJubykgeworCQkJY2FzZSBFTk9UU1VQOgorCQkJCWVycl9t ZXNzYWdlKCIlczogZmlsZSB0eXBlIG5vdCBzdXBwb3J0ZWQiLAorCQkJCQlz cmNuYW1lKTsKKwkJCQlicmVhazsKKwkJCWNhc2UgRUZBVUxUOgorCQkJCS8q IFRoZSBmaWxlIGhhcyBjaGFuZ2VkIHNpbmNlIHdlIHN0YXJ0ZWQgdGhlIGNv cHkgKi8KKwkJCQllcnJfbWVzc2FnZSgiJXM6IGZpbGUgbW9kaWZpZWQsICIK KwkJCQkJICJpbm9kZSByZW51bWJlciBhYm9ydGVkOiAlbGQiLAorCQkJCQkg c3JjbmFtZSwgYnN0YXRidWYuYnNfc2l6ZSk7CisJCQkJYnJlYWs7CisJCQlj YXNlIEVCVVNZOgorCQkJCS8qIFRpbWVzdGFtcCBoYXMgY2hhbmdlZCBvciBt bWFwJ2VkIGZpbGUgKi8KKwkJCQllcnJfbWVzc2FnZSgiJXM6IGZpbGUgYnVz eSIsIHNyY25hbWUpOworCQkJCWJyZWFrOworCQkJZGVmYXVsdDoKKwkJCQll cnJfbWVzc2FnZShfKCJTd2FwIGV4dGVudHMgZmFpbGVkOiAlczogJXMiKSwK KwkJCQkJc3JjbmFtZSwgc3RyZXJyb3IoZXJybm8pKTsKKwkJCQlicmVhazsK KwkJCX0KKwkJfSBlbHNlCisJCQllcnJfbWVzc2FnZShfKCJTd2FwIGV4dGVu dHMgZmFpbGVkOiAlczogJXMiKSwKKwkJCQkJc3JjbmFtZSwgc3RyZXJyb3Io ZXJybm8pKTsKKwkJZ290byBxdWl0OworCX0KKworCWlmIChic3RhdGJ1Zi5i c19kbWV2bWFzayB8IGJzdGF0YnVmLmJzX2Rtc3RhdGUpIHsKKwkJc3RydWN0 IGZzZG1pZGF0YSBmc3NldGRtOworCisJCS8qIFNldCB0aGUgRE1BUEkgRmll bGRzLiAqLworCQlmc3NldGRtLmZzZF9kbWV2bWFzayA9IGJzdGF0YnVmLmJz X2RtZXZtYXNrOworCQlmc3NldGRtLmZzZF9wYWRkaW5nID0gMDsKKwkJZnNz ZXRkbS5mc2RfZG1zdGF0ZSA9IGJzdGF0YnVmLmJzX2Rtc3RhdGU7CisKKwkJ aWYgKGlvY3RsKHRmZCwgWEZTX0lPQ19GU1NFVERNLCAodm9pZCAqKSZmc3Nl dGRtICkgPCAwKQorCQkJZXJyX21lc3NhZ2UoXygiYXR0ZW1wdCB0byBzZXQg RE1JIGF0dHJpYnV0ZXMgIgorCQkJCQkib2YgJXMgZmFpbGVkIiksIHRhcmdl dCk7CisJfQorCisJU0VUX1BIQVNFKEZJTEVfUEhBU0VfMik7CisKKwkvKiB1 bmxpbmsgc3JjICovCisJcnZhbCA9IHVubGluayhzcmNuYW1lKTsKKwlpZiAo cnZhbCAhPSAwKSB7CisJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW1v dmUgZmlsZTogJXMiKSwgc3JjbmFtZSk7CisJCWdvdG8gcXVpdDsKKwl9CisK KwlTRVRfUEhBU0UoRklMRV9QSEFTRV8zKTsKKworCS8qIHJlbmFtZSB0YXJn ZXQgc3JjICovCisJcnZhbCA9IHJlbmFtZSh0YXJnZXQsIHNyY25hbWUpOwor CWlmIChydmFsICE9IDApIHsKKwkJLyoKKwkJICogd2UgY2FuJ3QgYWJvcnQg c2luY2UgdGhlIHNyYyBmaWxlIGlzIG5vdyBnb25lLgorCQkgKiBsZXQgdGhl IGFkbWluIGNsZWFuIHRoaXMgb25lIHVwCisJCSAqLworCQllcnJfbWVzc2Fn ZShfKCJ1bmFibGUgdG8gcmVuYW1lIGZpbGU6ICVzIHRvICVzIiksCisJCQkJ dGFyZ2V0LCBzcmNuYW1lKTsKKwkJZ290byBxdWl0OworCX0KKworCVNFVF9Q SEFTRShGSUxFX1BIQVNFXzQpOworCisJLyogZm9yIGVhY2ggaGFyZGxpbmss IHVubGluayBhbmQgY3JlYXQgcG9pbnRpbmcgdG8gdGFyZ2V0ICovCisJZm9y IChpID0gMTsgaSA8IG5vZGUtPm51bXBhdGhzOyBpKyspIHsKKwkJLyogdW5s aW5rIHNyYyAqLworCQlydmFsID0gdW5saW5rKG5vZGUtPnBhdGhzW2ldKTsK KwkJaWYgKHJ2YWwgIT0gMCkgeworCQkJZXJyX21lc3NhZ2UoXygidW5hYmxl IHRvIHJlbW92ZSBmaWxlOiAlcyIpLAorCQkJCSAgICAgICBub2RlLT5wYXRo c1tpXSk7CisJCQlnb3RvIHF1aXQ7CisJCX0KKworCQlydmFsID0gbGluayhz cmNuYW1lLCBub2RlLT5wYXRoc1tpXSk7CisJCWlmIChydmFsICE9IDApIHsK KwkJCWVycl9tZXNzYWdlKCJ1bmFibGUgdG8gbGluayB0byBmaWxlOiAlcyIs IHNyY25hbWUpOworCQkJZ290byBxdWl0OworCQl9CisJCW51bWZpbGVzZG9u ZSsrOworCX0KKworIHF1aXQ6CisJY3VyX25vZGUgPSBOVUxMOworCisJU0VU X1BIQVNFKEZJTEVfUEhBU0UpOworCisJaWYgKHNmZCA+PSAwKQorCQljbG9z ZShzZmQpOworCWlmICh0ZmQgPj0gMCkKKwkJY2xvc2UodGZkKTsKKworCWZy ZWUocG5hbWUpOworCWZyZWUoY3VyX3RhcmdldCk7CisKKwljdXJfdGFyZ2V0 ID0gTlVMTDsKKworCW51bWZpbGVzZG9uZSsrOworCXJldHVybiBydmFsOwor fQorCisKK3N0YXRpYyBpbnQKK3Byb2Nlc3Nfc2xpbmsoCisJYmlnbm9kZV90 CSpub2RlKQoreworCWludAkJaSA9IDA7CisJaW50CQlydmFsID0gMDsKKwlz dHJ1Y3Qgc3RhdDY0CXN0OworCWNoYXIJCSpzcmNuYW1lID0gTlVMTDsKKwlj aGFyCQkqcG5hbWUgPSBOVUxMOworCWNoYXIJCXRhcmdldFtQQVRIX01BWF0g PSAiIjsKKwljaGFyCQlsaW5rYnVmW1BBVEhfTUFYXTsKKworCVNFVF9QSEFT RShTTElOS19QSEFTRSk7CisKKwlkdW1wX25vZGUoInN5bWxpbmsiLCBub2Rl KTsKKworCWN1cl9ub2RlID0gbm9kZTsKKwlzcmNuYW1lID0gbm9kZS0+cGF0 aHNbMF07CisKKwlpZiAobHN0YXQ2NChzcmNuYW1lLCAmc3QpIDwgMCkgewor CQlpZiAoZXJybm8gIT0gRU5PRU5UKSB7CisJCQllcnJfc3RhdChzcmNuYW1l KTsKKwkJCWdsb2JhbF9ydmFsIHw9IDI7CisJCX0KKwkJZ290byBxdWl0Owor CX0KKwlpZiAoc3Quc3RfaW5vIDw9IFhGU19NQVhJTlVNQkVSXzMyICYmICFm b3JjZV9hbGwpCisJCS8qIHRoaXMgZmlsZSBoYXMgY2hhbmdlZCwgYW5kIG5v IGxvbmdlciBuZWVkcyBwcm9jZXNzaW5nICovCisJCWdvdG8gcXVpdDsKKwor CXJ2YWwgPSAxOworCisJaSA9IHJlYWRsaW5rKHNyY25hbWUsIGxpbmtidWYs IHNpemVvZihsaW5rYnVmKSAtIDEpOworCWlmIChpIDwgMCkgeworCQllcnJf bWVzc2FnZShfKCJ1bmFibGUgdG8gcmVhZCBzeW1saW5rOiAlcyIpLCBzcmNu YW1lKTsKKwkJZ290byBxdWl0OworCX0KKwlsaW5rYnVmW2ldID0gJ1wwJzsK KworCWlmIChyZWFsdWlkICE9IDAgJiYgcmVhbHVpZCAhPSBzdC5zdF91aWQp IHsKKwkJZXJybm8gPSBFQUNDRVM7CisJCWVycl9vcGVuKHNyY25hbWUpOwor CQlnb3RvIHF1aXQ7CisJfQorCisJLyogY3JlYXRlIHRhcmdldCAqLworCXBu YW1lID0gc3RyZHVwKHNyY25hbWUpOworCWlmIChwbmFtZSA9PSBOVUxMKSB7 CisJCWVycl9ub21lbSgpOworCQlnb3RvIHF1aXQ7CisJfQorCWRpcm5hbWUo cG5hbWUpOworCisJc3ByaW50Zih0YXJnZXQsICIlcy8lc1hYWFhYWCIsIHBu YW1lLCBjbWRfcHJlZml4KTsKKwlpZiAobWt0ZW1wKHRhcmdldCkgPT0gTlVM TCkgeworCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8gY3JlYXRlIHRlbXAg c3ltbGluayBuYW1lIikpOworCQlnb3RvIHF1aXQ7CisJfQorCWN1cl90YXJn ZXQgPSBzdHJkdXAodGFyZ2V0KTsKKwlpZiAoY3VyX3RhcmdldCA9PSBOVUxM KSB7CisJCWVycl9ub21lbSgpOworCQlnb3RvIHF1aXQ7CisJfQorCisJaWYg KHN5bWxpbmsobGlua2J1ZiwgdGFyZ2V0KSAhPSAwKSB7CisJCWVycl9tZXNz YWdlKF8oInVuYWJsZSB0byBjcmVhdGUgc3ltbGluazogJXMiKSwgdGFyZ2V0 KTsKKwkJZ290byBxdWl0OworCX0KKworCVNFVF9QSEFTRShTTElOS19QSEFT RV8xKTsKKworCS8qIGNvcHkgb3duZXJzaGlwICYgRUFzIHRvIHRhcmdldCAq LworCWlmIChsY2hvd24odGFyZ2V0LCBzdC5zdF91aWQsIHN0LnN0X2dpZCkg PCAwKSB7CisJCWVycl9tZXNzYWdlKF8oIiVzOiBDYW5ub3QgY2hhbmdlIHRh cmdldCBvd25lcnNoaXAgdG8gIgorCQkJCSJ1aWQoJWQpIGdpZCglZCkiKSwg dGFyZ2V0LAorCQkJCXN0LnN0X3VpZCwgc3Quc3RfZ2lkKTsKKwkJdW5saW5r KHRhcmdldCk7CisJCWdvdG8gcXVpdDsKKwl9CisKKwlpZiAoY2xvbmVfYXR0 cmlicyhzcmNuYW1lLCB0YXJnZXQpICE9IDApIHsKKwkJZXJyX21lc3NhZ2Uo XygidW5hYmxlIHRvIGR1cGxpY2F0ZSBzeW1saW5rIGF0dHJpYnV0ZXM6ICVz IiksCisJCQkJc3JjbmFtZSk7CisJCXVubGluayh0YXJnZXQpOworCQlnb3Rv IHF1aXQ7CisJfQorCisJU0VUX1BIQVNFKFNMSU5LX1BIQVNFXzIpOworCisJ LyogdW5saW5rIHNyYyAqLworCXJ2YWwgPSB1bmxpbmsoc3JjbmFtZSk7CisJ aWYgKHJ2YWwgIT0gMCkgeworCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8g cmVtb3ZlIHN5bWxpbms6ICVzIiksIHNyY25hbWUpOworCQlnb3RvIHF1aXQ7 CisJfQorCisJU0VUX1BIQVNFKFNMSU5LX1BIQVNFXzMpOworCisJLyogcmVu YW1lIHRhcmdldCBzcmMgKi8KKwlydmFsID0gcmVuYW1lKHRhcmdldCwgc3Jj bmFtZSk7CisJaWYgKHJ2YWwgIT0gMCkgeworCQkvKgorCQkgKiB3ZSBjYW4n dCBhYm9ydCBzaW5jZSB0aGUgc3JjIGZpbGUgaXMgbm93IGdvbmUuCisJCSAq IGxldCB0aGUgYWRtaW4gY2xlYW4gdGhpcyBvbmUgdXAKKwkJICovCisJCWVy cl9tZXNzYWdlKF8oInVuYWJsZSB0byByZW5hbWUgc3ltbGluazogJXMgdG8g JXMiKSwKKwkJCQl0YXJnZXQsIHNyY25hbWUpOworCQlnb3RvIHF1aXQ7CisJ fQorCisJU0VUX1BIQVNFKFNMSU5LX1BIQVNFXzQpOworCisJLyogZm9yIGVh Y2ggaGFyZGxpbmssIHVubGluayBhbmQgY3JlYXQgcG9pbnRpbmcgdG8gdGFy Z2V0ICovCisJZm9yIChpID0gMTsgaSA8IG5vZGUtPm51bXBhdGhzOyBpKysp IHsKKwkJLyogdW5saW5rIHNyYyAqLworCQlydmFsID0gdW5saW5rKG5vZGUt PnBhdGhzW2ldKTsKKwkJaWYgKHJ2YWwgIT0gMCkgeworCQkJZXJyX21lc3Nh Z2UoXygidW5hYmxlIHRvIHJlbW92ZSBzeW1saW5rOiAlcyIpLAorCQkJCSAg ICAgICBub2RlLT5wYXRoc1tpXSk7CisJCQlnb3RvIHF1aXQ7CisJCX0KKwor CQlydmFsID0gbGluayhzcmNuYW1lLCBub2RlLT5wYXRoc1tpXSk7CisJCWlm IChydmFsICE9IDApIHsKKwkJCWVycl9tZXNzYWdlKCJ1bmFibGUgdG8gbGlu ayB0byBzeW1saW5rOiAlcyIsIHNyY25hbWUpOworCQkJZ290byBxdWl0Owor CQl9CisJCW51bXNsaW5rc2RvbmUrKzsKKwl9CisKKyBxdWl0OgorCWN1cl9u b2RlID0gTlVMTDsKKworCVNFVF9QSEFTRShTTElOS19QSEFTRSk7CisKKwlm cmVlKHBuYW1lKTsKKwlmcmVlKGN1cl90YXJnZXQpOworCisJY3VyX3Rhcmdl dCA9IE5VTEw7CisKKwludW1zbGlua3Nkb25lKys7CisJcmV0dXJuIHJ2YWw7 Cit9CisKK3N0YXRpYyBpbnQKK29wZW5fcmVjb3ZlcmZpbGUodm9pZCkKK3sK KwlyZWNvdmVyX2ZkID0gb3BlbihyZWNvdmVyX2ZpbGUsIE9fUkRXUiB8IE9f U1lOQyB8IE9fQ1JFQVQgfCBPX0VYQ0wsCisJCQkwNjAwKTsKKwlpZiAocmVj b3Zlcl9mZCA8IDApIHsKKwkJaWYgKGVycm5vID09IEVFWElTVCkKKwkJCWVy cl9tZXNzYWdlKF8oIlJlY292ZXJ5IGZpbGUgYWxyZWFkeSBleGlzdHMsIGVp dGhlciAiCisJCQkJInJ1biAnJXMgLXIgJXMnIG9yIHJlbW92ZSB0aGUgZmls ZS4iKSwKKwkJCQlwcm9nbmFtZSwgcmVjb3Zlcl9maWxlKTsKKwkJZWxzZQor CQkJZXJyX29wZW4ocmVjb3Zlcl9maWxlKTsKKwkJcmV0dXJuIDE7CisJfQor CisJaWYgKCFwbGF0Zm9ybV90ZXN0X3hmc19mZChyZWNvdmVyX2ZkKSkgewor CQllcnJfbm90X3hmcyhyZWNvdmVyX2ZpbGUpOworCQljbG9zZShyZWNvdmVy X2ZkKTsKKwkJcmV0dXJuIDE7CisJfQorCisJcmV0dXJuIDA7Cit9CisKK3N0 YXRpYyB2b2lkCit1cGRhdGVfcmVjb3ZlcmZpbGUodm9pZCkKK3sKKwlzdGF0 aWMgY29uc3QgY2hhciBudWxsX2ZpbGVbXSA9ICIwXG4wXG4wXG5cbnRhcmdl dDogXG50ZW1wOiBcbmVuZFxuIjsKKwlzdGF0aWMgc2l6ZV90CWJ1Zl9zaXpl ID0gMDsKKwlzdGF0aWMgY2hhcgkqYnVmID0gTlVMTDsKKwlpbnQgCQlpLCBs ZW47CisKKwlpZiAocmVjb3Zlcl9mZCA8PSAwKQorCQlyZXR1cm47CisKKwlp ZiAoY3VyX25vZGUgPT0gTlVMTCB8fCBjdXJfcGhhc2UgPT0gMCkgeworCQkv KiBpbmJldHdlZW4gcHJvY2Vzc2luZyBvciBzdGlsbCBzY2FubmluZyAqLwor CQlsc2VlayhyZWNvdmVyX2ZkLCAwLCBTRUVLX1NFVCk7CisJCXdyaXRlKHJl Y292ZXJfZmQsIG51bGxfZmlsZSwgc2l6ZW9mKG51bGxfZmlsZSkpOworCQly ZXR1cm47CisJfQorCisJQVNTRVJUKGhpZ2hlc3RfbnVtcGF0aHMgPiAwKTsK KwlpZiAoYnVmID09IE5VTEwpIHsKKwkJYnVmX3NpemUgPSAoaGlnaGVzdF9u dW1wYXRocyArIDMpICogUEFUSF9NQVg7CisJCWJ1ZiA9IG1hbGxvYyhidWZf c2l6ZSk7CisJCWlmIChidWYgPT0gTlVMTCkgeworCQkJZXJyX25vbWVtKCk7 CisJCQlleGl0KDEpOworCQl9CisJfQorCisJbGVuID0gc3ByaW50ZihidWYs ICIlZFxuJWxsdVxuJWRcbiIsIGN1cl9waGFzZSwKKwkJCShsb25nIGxvbmcp Y3VyX25vZGUtPmlubywgY3VyX25vZGUtPmZ0d19mbGFncyk7CisKKwlmb3Ig KGkgPSAwOyBpIDwgY3VyX25vZGUtPm51bXBhdGhzOyBpKyspCisJCWxlbiAr PSBzcHJpbnRmKGJ1ZiArIGxlbiwgIiVzXG4iLCBjdXJfbm9kZS0+cGF0aHNb aV0pOworCisJbGVuICs9IHNwcmludGYoYnVmICsgbGVuLCAidGFyZ2V0OiAl c1xudGVtcDogJXNcbmVuZFxuIiwKKwkJCWN1cl90YXJnZXQsIGN1cl90ZW1w KTsKKworCUFTU0VSVChsZW4gPCBidWZfc2l6ZSk7CisKKwlsc2VlayhyZWNv dmVyX2ZkLCAwLCBTRUVLX1NFVCk7CisJZnRydW5jYXRlKHJlY292ZXJfZmQs IDApOworCXdyaXRlKHJlY292ZXJfZmQsIGJ1ZiwgbGVuKTsKK30KKworc3Rh dGljIHZvaWQKK2NsZWFudXAodm9pZCkKK3sKKwlsb2dfbWVzc2FnZShMT0df Tk9STUFMLCBfKCJJbnRlcnJ1cHRlZCAtLSBjbGVhbmluZyB1cC4uLiIpKTsK KworCWZyZWVfbm9kZWhhc2goKTsKKworCWxvZ19tZXNzYWdlKExPR19OT1JN QUwsIF8oIkRvbmUuIikpOworfQorCitzdGF0aWMgdm9pZAorc2lnaGFuZGxl cihpbnQgc2lnKQoreworCXN0YXRpYyBjaGFyCWN5Y2xlWzRdID0gIi1cXHwv IjsKKwlzdGF0aWMgdWludDY0X3QJY3VyX2N5Y2xlID0gMDsKKwlkb3VibGUJ CXBlcmNlbnQ7CisJY2hhcgkJKnR5cGVuYW1lOworCXVpbnQ2NF90CW5vZGVz LCBkb25lOworCisJYWxhcm0oMCk7CisKKwlpZiAoc2lnICE9IFNJR0FMUk0p IHsKKwkJY2xlYW51cCgpOworCQlleGl0KDEpOworCX0KKworCWlmIChjdXJf cGhhc2UgPT0gU0NBTl9QSEFTRSkgeworCQlpZiAobG9nX2xldmVsID49IExP R19JTkZPKQorCQkJZnByaW50ZihzdGRlcnIsIF8oIlxyJWxsdSBmaWxlcywg JWxsdSBkaXJzIGFuZCAlbGx1ICIKKwkJCQkic3ltbGlua3MgdG8gcmVudW1i ZXIgZm91bmQuLi4gJWMiKSwKKwkJCQkobG9uZyBsb25nKW51bWZpbGVub2Rl cywKKwkJCQkobG9uZyBsb25nKW51bWRpcm5vZGVzLAorCQkJCShsb25nIGxv bmcpbnVtc2xpbmtub2RlcywKKwkJCQljeWNsZVtjdXJfY3ljbGUgJSA0XSk7 CisJCWVsc2UKKwkJCWZwcmludGYoc3RkZXJyLCAiXHIlYyIsCisJCQkJY3lj bGVbY3VyX2N5Y2xlICUgNF0pOworCQljdXJfY3ljbGUrKzsKKwl9IGVsc2Ug eworCQlpZiAoY3VyX3BoYXNlID49IERJUl9QSEFTRSAmJiBjdXJfcGhhc2Ug PD0gRElSX1BIQVNFX01BWCkgeworCQkJbm9kZXMgPSBudW1kaXJub2RlczsK KwkJCWRvbmUgPSBudW1kaXJzZG9uZTsKKwkJCXR5cGVuYW1lID0gXygiZGly cyIpOworCSAJfSBlbHNlCisJIAlpZiAoY3VyX3BoYXNlID49IEZJTEVfUEhB U0UgJiYgY3VyX3BoYXNlIDw9IEZJTEVfUEhBU0VfTUFYKSB7CisJCQlub2Rl cyA9IG51bWZpbGVub2RlczsKKwkJCWRvbmUgPSBudW1maWxlc2RvbmU7CisJ CQl0eXBlbmFtZSA9IF8oImZpbGVzIik7CisJICAJfSBlbHNlIHsKKwkJCW5v ZGVzID0gbnVtc2xpbmtub2RlczsKKwkJCWRvbmUgPSBudW1zbGlua3Nkb25l OworCQkJdHlwZW5hbWUgPSBfKCJzeW1saW5rcyIpOworCQl9CisJCXBlcmNl bnQgPSAxMDAuMCAqIChkb3VibGUpZG9uZSAvIChkb3VibGUpbm9kZXM7CisJ CWlmIChwZXJjZW50ID4gMTAwLjApCisJCQlwZXJjZW50ID0gMTAwLjA7CisJ CWlmIChsb2dfbGV2ZWwgPj0gTE9HX0lORk8pCisJCQlmcHJpbnRmKHN0ZGVy ciwgXygiXHIlLjFmJSUsICVsbHUgb2YgJWxsdSAlcywgIgorCQkJCQkiJXUg c2Vjb25kcyBlbGFwc2VkIiksIHBlcmNlbnQsCisJCQkJCShsb25nIGxvbmcp ZG9uZSwgKGxvbmcgbG9uZylub2RlcywKKwkJCQkJdHlwZW5hbWUsIChpbnQp KHRpbWUoMCkgLSBzdGFydHRpbWUpKTsKKwkJZWxzZQorCQkJZnByaW50Zihz dGRlcnIsICJcciUuMWYlJSIsIHBlcmNlbnQpOworCX0KKwlwb2xsX291dHB1 dCA9IDE7CisJc2lnbmFsKFNJR0FMUk0sIHNpZ2hhbmRsZXIpOworCisJaWYg KHBvbGxfaW50ZXJ2YWwpCisJCWFsYXJtKHBvbGxfaW50ZXJ2YWwpOworfQor CitzdGF0aWMgaW50CityZWFkX3JlY292ZXJfZmlsZSgKKwljaGFyCQkqcmVj b3Zlcl9maWxlLAorCWJpZ25vZGVfdAkqKm5vZGUsCisJY2hhcgkJKip0YXJn ZXQsCisJY2hhcgkJKip0ZW1wLAorCWludAkJKnBoYXNlKQoreworCUZJTEUJ CSpmaWxlOworCWludAkJcnZhbCA9IDE7CisJaW5vX3QJCWlubzsKKwlpbnQJ CWZ0d19mbGFnczsKKwljaGFyCQlidWZbUEFUSF9NQVggKyAxMF07IC8qIHBh dGggKyAidGFyZ2V0OiAiICovCisJc3RydWN0IHN0YXQ2NAlzOworCWludAkJ Zmlyc3RfcGF0aDsKKworCS8qCisKKwlBIHJlY292ZXJ5IGZpbGUgc2hvdWxk IGxvb2sgbGlrZToKKworCTxwaGFzZT4KKwk8aW5vIG51bWJlcj4KKwk8ZnR3 IGZsYWdzPgorCTxmaXJzdCBwYXRoIHRvIGlub2RlPgorCTxoYXJkbGlua3Mg dG8gaW5vZGU+CisJdGFyZ2V0OiA8cGF0aCB0byB0YXJnZXQgZGlyIG9yIGZp bGU+CisJdGVtcDogPHBhdGggdG8gdGVtcCBkaXIgaWYgZGlyIHBoYXNlPgor CWVuZAorCSovCisKKwlmaWxlID0gZm9wZW4ocmVjb3Zlcl9maWxlLCAiciIp OworCWlmIChmaWxlID09IE5VTEwpIHsKKwkJZXJyX29wZW4ocmVjb3Zlcl9m aWxlKTsKKwkJcmV0dXJuIDE7CisJfQorCisJLyogcmVhZCBwaGFzZSAqLwor CSpwaGFzZSA9IDA7CisJaWYgKGZnZXRzKGJ1ZiwgUEFUSF9NQVggKyAxMCwg ZmlsZSkgPT0gTlVMTCkgeworCQllcnJfbWVzc2FnZSgiUmVjb3ZlcnkgZmFp bGVkOiB1bmFibGUgdG8gcmVhZCBwaGFzZSIpOworCQlnb3RvIHF1aXQ7CisJ fQorCWJ1ZltzdHJsZW4oYnVmKSAtIDFdID0gJ1wwJzsKKwkqcGhhc2UgPSBh dG9pKGJ1Zik7CisJaWYgKCpwaGFzZSA9PSBTQ0FOX1BIQVNFKSB7CisJCWZj bG9zZShmaWxlKTsKKwkJcmV0dXJuIDA7CisJfQorCWlmICgoKnBoYXNlIDwg RElSX1BIQVNFIHx8ICpwaGFzZSA+IERJUl9QSEFTRV9NQVgpICYmCisJCQko KnBoYXNlIDwgRklMRV9QSEFTRSB8fCAqcGhhc2UgPiBGSUxFX1BIQVNFX01B WCkpIHsKKwkJZXJyX21lc3NhZ2UoIlJlY292ZXJ5IGZhaWxlZDogZmFpbGVk IHRvIHJlYWQgdmFsaWQgcmVjb3ZlcnkgcGhhc2UiKTsKKwkJZ290byBxdWl0 OworCX0KKworCS8qIHJlYWQgaW5vZGUgbnVtYmVyICovCisJaWYgKGZnZXRz KGJ1ZiwgUEFUSF9NQVggKyAxMCwgZmlsZSkgPT0gTlVMTCkgeworCQllcnJf bWVzc2FnZSgiUmVjb3ZlcnkgZmFpbGVkOiB1bmFibGUgdG8gcmVhZCBpbm9k ZSBudW1iZXIiKTsKKwkJZ290byBxdWl0OworCX0KKwlidWZbc3RybGVuKGJ1 ZikgLSAxXSA9ICdcMCc7CisJaW5vID0gc3RydG91bGwoYnVmLCBOVUxMLCAx MCk7CisJaWYgKGlubyA9PSAwKSB7CisJCWVycl9tZXNzYWdlKCJSZWNvdmVy eSBmYWlsZWQ6IHVuYWJsZSB0byByZWFkIGlub2RlIG51bWJlciIpOworCQln b3RvIHF1aXQ7CisJfQorCisJLyogcmVhZCBmdHdfZmxhZ3MgKi8KKwlpZiAo ZmdldHMoYnVmLCBQQVRIX01BWCArIDEwLCBmaWxlKSA9PSBOVUxMKSB7CisJ CWVycl9tZXNzYWdlKCJSZWNvdmVyeSBmYWlsZWQ6IHVuYWJsZSB0byByZWFk IGZsYWdzIik7CisJCWdvdG8gcXVpdDsKKwl9CisJYnVmW3N0cmxlbihidWYp IC0gMV0gPSAnXDAnOworCWlmIChidWZbMV0gIT0gJ1wwJyB8fCAoYnVmWzBd ICE9ICcwJyAmJiBidWZbMF0gIT0gJzEnKSkgeworCQllcnJfbWVzc2FnZSgi UmVjb3ZlcnkgZmFpbGVkOiB1bmFibGUgdG8gcmVhZCBmbGFnczogJyVzJyIs IGJ1Zik7CisJCWdvdG8gcXVpdDsKKwl9CisJZnR3X2ZsYWdzID0gYXRvaShi dWYpOworCisJLyogcmVhZCBwYXRocyBhbmQgdGFyZ2V0IHBhdGggKi8KKwkq bm9kZSA9IE5VTEw7CisJKnRhcmdldCA9IE5VTEw7CisJZmlyc3RfcGF0aCA9 IDE7CisJd2hpbGUgKGZnZXRzKGJ1ZiwgUEFUSF9NQVggKyAxMCwgZmlsZSkg IT0gTlVMTCkgeworCQlidWZbc3RybGVuKGJ1ZikgLSAxXSA9ICdcMCc7CisK KwkJbG9nX21lc3NhZ2UoTE9HX0RFQlVHLCAicGF0aDogJyVzJyIsIGJ1Zik7 CisKKwkJaWYgKGJ1ZlswXSA9PSAnLycpIHsKKwkJCWlmIChzdGF0NjQoYnVm LCAmcykgPCAwKSB7CisJCQkJZXJyX21lc3NhZ2UoXygiUmVjb3ZlcnkgZmFp bGVkOiBjYW5ub3QgIgorCQkJCQkJInN0YXQgJyVzJyIpLCBidWYpOworCQkJ CWdvdG8gcXVpdDsKKwkJCX0KKwkJCWlmIChzLnN0X2lubyAhPSBpbm8pIHsK KwkJCQllcnJfbWVzc2FnZShfKCJSZWNvdmVyeSBmYWlsZWQ6IGlub2RlICIK KwkJCQkJCSJudW1iZXIgZm9yICclcycgZG9lcyBub3QgIgorCQkJCQkJIm1h dGNoIHJlY29yZGVkIG51bWJlciIpLCBidWYpOworCQkJCWdvdG8gcXVpdDsK KwkJCX0KKworCQkJaWYgKGZpcnN0X3BhdGgpIHsKKwkJCQlmaXJzdF9wYXRo ID0gMDsKKwkJCQkqbm9kZSA9IGFkZF9ub2RlX3BhdGgoaW5vLCBmdHdfZmxh Z3MsIGJ1Zik7CisJCQl9CisJCQllbHNlIHsKKwkJCQlhZGRfcGF0aCgqbm9k ZSwgYnVmKTsKKwkJCX0KKwkJfQorCQllbHNlIGlmIChzdHJuY21wKGJ1Ziwg InRhcmdldDogIiwgOCkgPT0gMCkgeworCQkJKnRhcmdldCA9IHN0cmR1cChi dWYgKyA4KTsKKwkJCWlmICgqdGFyZ2V0ID09IE5VTEwpIHsKKwkJCQllcnJf bm9tZW0oKTsKKwkJCQlnb3RvIHF1aXQ7CisJCQl9CisJCQlpZiAoc3RhdDY0 KCp0YXJnZXQsICZzKSA8IDApIHsKKwkJCQllcnJfbWVzc2FnZShfKCJSZWNv dmVyeSBmYWlsZWQ6IGNhbm5vdCAiCisJCQkJCQkic3RhdCAnJXMnIiksICp0 YXJnZXQpOworCQkJCWdvdG8gcXVpdDsKKwkJCX0KKwkJfQorCQllbHNlIGlm IChzdHJuY21wKGJ1ZiwgInRlbXA6ICIsIDYpID09IDApIHsKKwkJCSp0ZW1w ID0gc3RyZHVwKGJ1ZiArIDYpOworCQkJaWYgKCp0ZW1wID09IE5VTEwpIHsK KwkJCQllcnJfbm9tZW0oKTsKKwkJCQlnb3RvIHF1aXQ7CisJCQl9CisJCX0K KwkJZWxzZSBpZiAoc3RyY21wKGJ1ZiwgImVuZCIpID09IDApIHsKKwkJCXJ2 YWwgPSAwOworCQkJZ290byBxdWl0OworCSAJfQorCSAJZWxzZSB7CisJCQll cnJfbWVzc2FnZShfKCJSZWNvdmVyeSBmYWlsZWQ6IHVucmVjb2duaXNlZCAi CisJCQkJCSJzdHJpbmc6ICclcyciKSwgYnVmKTsKKwkJCWdvdG8gcXVpdDsK KwkJfQorCX0KKworCWVycl9tZXNzYWdlKF8oIlJlY292ZXJ5IGZhaWxlZDog ZW5kIG9mIHJlY292ZXJ5IGZpbGUgbm90IGZvdW5kIikpOworCisgcXVpdDoK KwlpZiAoKm5vZGUgPT0gTlVMTCkgeworCQllcnJfbWVzc2FnZShfKCJSZWNv dmVyeSBmYWlsZWQ6IG5vIHZhbGlkIGlub2RlIG9yIHBhdGhzICIKKwkJCQki c3BlY2lmaWVkIikpOworCQlydmFsID0gMTsKKwl9CisKKwlpZiAoKnRhcmdl dCA9PSBOVUxMKSB7CisJCWVycl9tZXNzYWdlKF8oIlJlY292ZXJ5IGZhaWxl ZDogbm8gaW5vZGUgdGFyZ2V0IHNwZWNpZmllZCIpKTsKKwkJcnZhbCA9IDE7 CisJfQorCisJZmNsb3NlKGZpbGUpOworCisJcmV0dXJuIHJ2YWw7Cit9CisK K2ludAorcmVjb3ZlcigKKwliaWdub2RlX3QJKm5vZGUsCisJY2hhcgkJKnRh cmdldCwKKwljaGFyCQkqdG5hbWUsCisJaW50CQlwaGFzZSkKK3sKKwlpbnQJ CXRmZCA9IC0xOworCWludAkJdGFyZ2V0ZmQgPSAtMTsKKwljaGFyCQkqc3Jj bmFtZSA9IE5VTEw7CisJaW50CQlydmFsID0gMDsKKwlpbnQJCWk7CisJaW50 CQltb3ZlX2NvdW50ID0gMDsKKworCWR1bXBfbm9kZSgicmVjb3ZlciIsIG5v ZGUpOworCWxvZ19tZXNzYWdlKExPR19ERUJVRywgInRhcmdldDogJXMsIHBo YXNlOiAleCIsIHRhcmdldCwgcGhhc2UpOworCisJaWYgKG5vZGUpCisJCXNy Y25hbWUgPSBub2RlLT5wYXRoc1swXTsKKworCXN3aXRjaCAocGhhc2UpIHsK KworCWNhc2UgRElSX1BIQVNFXzI6CitybXRlbXBzOgorCQlsb2dfbWVzc2Fn ZShMT0dfTk9STUFMLCBfKCJSZW1vdmluZyB0ZW1wb3JhcnkgZGlyZWN0b3J5 OiAnJXMnIiksCisJCQkJdG5hbWUpOworCQlpZiAocm1kaXIodG5hbWUpIDwg MCAmJiBlcnJubyAhPSBFTk9FTlQpIHsKKwkJCWVycl9tZXNzYWdlKF8oInVu YWJsZSB0byByZW1vdmUgZGlyZWN0b3J5OiAlcyIpLCB0bmFtZSk7CisJCQly dmFsID0gMTsKKwkJfQorCQkvKiBGQUxMIFRIUlUgKi8KKwljYXNlIERJUl9Q SEFTRV8xOgorCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCBfKCJSZW1vdmlu ZyB0YXJnZXQgZGlyZWN0b3J5OiAnJXMnIiksCisJCQkJdGFyZ2V0KTsKKwkJ aWYgKHJtZGlyKHRhcmdldCkgPCAwICYmIGVycm5vICE9IEVOT0VOVCkgewor CQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIHJlbW92ZSBkaXJlY3Rvcnk6 ICVzIiksCisJCQkJCXRhcmdldCk7CisJCQlydmFsID0gMTsKKwkJfQorCQli cmVhazsKKworCWNhc2UgRElSX1BIQVNFXzM6CisJCWxvZ19tZXNzYWdlKExP R19OT1JNQUwsIF8oIkNvbXBsZXRpbmcgbW92aW5nIGRpcmVjdG9yeSAiCisJ CQkJImNvbnRlbnRzOiAnJXMnIHRvICclcyciKSwgc3JjbmFtZSwgdGFyZ2V0 KTsKKwkJaWYgKG1vdmVfZGlyZW50cyhzcmNuYW1lLCB0YXJnZXQsICZtb3Zl X2NvdW50KSAhPSAwKSB7CisJCQllcnJfbWVzc2FnZShfKCJ1bmFibGUgdG8g bW92ZSBkaXJlY3RvcnkgY29udGVudHM6ICIKKwkJCQkJIiVzIHRvICVzIiks IHNyY25hbWUsIHRhcmdldCk7CisJCQkvKiB1aCBvaCwgbW92ZSBldmVyeXRo aW5nIGJhY2suLi4gKi8KKwkJCWlmIChtb3ZlX2NvdW50ID4gMCkgeworCQkJ CWlmIChtb3ZlX2RpcmVudHModGFyZ2V0LCBzcmNuYW1lLAorCQkJCQkJJm1v dmVfY291bnQpICE9IDApIHsKKwkJCQkJLyogb2gsIGRlYXIgbG9yZC4uLiBs ZXQgdGhlIGFkbWluCisJCQkJCSAqIGNsZWFuIHRoaXMgb25lIHVwICovCisJ CQkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBtb3ZlIGRpcmVjdG9yeSAi CisJCQkJCQkiY29udGVudHMgYmFjazogJXMgdG8gJXMiKSwKKwkJCQkJCXRh cmdldCwgc3JjbmFtZSk7CisJCQkJCWV4aXQoMSk7CisJCQkJfQorCQkJfQor CQkJZ290byBybXRlbXBzOworCQl9CisJCS8qIEZBTEwgVEhSVSAqLworCWNh c2UgRElSX1BIQVNFXzQ6CisJCWxvZ19tZXNzYWdlKExPR19OT1JNQUwsIF8o IlNldHRpbmcgYXR0cmlidXRlcyBmb3IgdGFyZ2V0ICIKKwkJCQkiZGlyZWN0 b3J5OiBcJyVzXCciKSwgdGFyZ2V0KTsKKwkJdGZkID0gb3Blbih0bmFtZSwg T19SRE9OTFkpOworCQlpZiAodGZkIDwgMCkgeworCQkJZXJyX29wZW4odG5h bWUpOworCQkJcnZhbCA9IDE7CisJCQlicmVhazsKKwkJfQorCQl0YXJnZXRm ZCA9IG9wZW4odGFyZ2V0LCBPX1JET05MWSk7CisJCWlmICh0YXJnZXRmZCA8 IDApIHsKKwkJCWVycl9vcGVuKHRhcmdldCk7CisJCQlydmFsID0gMTsKKwkJ CWJyZWFrOworCQl9CisJCXJ2YWwgPSBkdXBfYXR0cmlidXRlcyh0bmFtZSwg dGZkLCB0YXJnZXQsIHRhcmdldGZkKTsKKwkJaWYgKHJ2YWwgIT0gMCkgewor CQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIGR1cGxpY2F0ZSBkaXJlY3Rv cnkgIgorCQkJCQkiYXR0cmlidXRlczogJXMiKSwgdG5hbWUpOworCQkJYnJl YWs7CisJCX0KKwkJY2xvc2UodGZkKTsKKwkJY2xvc2UodGFyZ2V0ZmQpOwor CQkvKiBGQUxMIFRIUlUgKi8KKwljYXNlIERJUl9QSEFTRV82OgorCQlsb2df bWVzc2FnZShMT0dfTk9STUFMLCBfKCJSZW1vdmluZyB0ZW1wb3JhcnkgZGly ZWN0b3J5OiBcJyVzXCciKSwKKwkJCQl0bmFtZSk7CisJCWlmIChybWRpcih0 bmFtZSkgPCAwICYmIGVycm5vICE9IEVOT0VOVCkgeworCQkJZXJyX21lc3Nh Z2UoXygidW5hYmxlIHRvIHJlbW92ZSBkaXJlY3Rvcnk6ICVzIiksCisJCQkJ CXRuYW1lKTsKKwkJCXJ2YWwgPSAxOworCQkJYnJlYWs7CisJCX0KKwkJLyog RkFMTCBUSFJVICovCisJY2FzZSBESVJfUEhBU0VfNToKKwkJbG9nX21lc3Nh Z2UoTE9HX05PUk1BTCwgXygiUmVtb3Zpbmcgb2xkIGRpcmVjdG9yeTogXCcl c1wnIiksCisJCQkJc3JjbmFtZSk7CisJCWlmIChybWRpcihzcmNuYW1lKSA8 IDAgJiYgZXJybm8gIT0gRU5PRU5UKSB7CisJCQllcnJfbWVzc2FnZShfKCJ1 bmFibGUgdG8gcmVtb3ZlIGRpcmVjdG9yeTogJXMiKSwKKwkJCQkJc3JjbmFt ZSk7CisJCQlydmFsID0gMTsKKwkJCWJyZWFrOworCQl9CisJCS8qIEZBTEwg VEhSVSAqLworCWNhc2UgRElSX1BIQVNFXzc6CisJCWxvZ19tZXNzYWdlKExP R19OT1JNQUwsIF8oIlJlbmFtaW5nIG5ldyBkaXJlY3RvcnkgdG8gb2xkICIK KwkJCSJkaXJlY3Rvcnk6IFwnJXNcJyAtPiBcJyVzXCciKSwgdGFyZ2V0LCBz cmNuYW1lKTsKKwkJcnZhbCA9IHJlbmFtZSh0YXJnZXQsIHNyY25hbWUpOwor CQlpZiAocnZhbCAhPSAwKSB7CisJCQkvKiB3ZSBjYW4ndCBhYm9ydCBzaW5j ZSB0aGUgc3JjIGRpciBpcyBub3cgZ29uZS4KKwkJCSAqIGxldCB0aGUgYWRt aW4gY2xlYW4gdGhpcyBvbmUgdXAKKwkJCSAqLworCQkJZXJyX21lc3NhZ2Uo XygidW5hYmxlIHRvIHJlbmFtZSBkaXJlY3Rvcnk6ICVzIHRvICVzIiksCisJ CQkJCXRhcmdldCwgc3JjbmFtZSk7CisJCQlicmVhazsKKwkJfQorCQlicmVh azsKKworCisJY2FzZSBGSUxFX1BIQVNFXzE6CisJY2FzZSBTTElOS19QSEFT RV8xOgorCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCBfKCJVbmxpbmtpbmcg dGVtcG9yYXJ5IGZpbGU6IFwnJXNcJyIpLAorCQkJCXRhcmdldCk7CisJCXVu bGluayh0YXJnZXQpOworCQlicmVhazsKKworCWNhc2UgRklMRV9QSEFTRV8y OgorCWNhc2UgU0xJTktfUEhBU0VfMjoKKwkJbG9nX21lc3NhZ2UoTE9HX05P Uk1BTCwgXygiVW5saW5raW5nIG9sZCBmaWxlOiBcJyVzXCciKSwKKwkJCQlz cmNuYW1lKTsKKwkJcnZhbCA9IHVubGluayhzcmNuYW1lKTsKKwkJaWYgKHJ2 YWwgIT0gMCkgeworCQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIHJlbW92 ZSBmaWxlOiAlcyIpLCBzcmNuYW1lKTsKKwkJCWJyZWFrOworCQl9CisJCS8q IEZBTEwgVEhSVSAqLworCWNhc2UgRklMRV9QSEFTRV8zOgorCWNhc2UgU0xJ TktfUEhBU0VfMzoKKwkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgXygiUmVu YW1pbmcgbmV3IGZpbGUgdG8gb2xkIGZpbGU6ICIKKwkJCQkiXCclc1wnIC0+ IFwnJXNcJyIpLCB0YXJnZXQsIHNyY25hbWUpOworCQlydmFsID0gcmVuYW1l KHRhcmdldCwgc3JjbmFtZSk7CisJCWlmIChydmFsICE9IDApIHsKKwkJCS8q IHdlIGNhbid0IGFib3J0IHNpbmNlIHRoZSBzcmMgZmlsZSBpcyBub3cgZ29u ZS4KKwkJCSAqIGxldCB0aGUgYWRtaW4gY2xlYW4gdGhpcyBvbmUgdXAKKwkJ CSAqLworCQkJZXJyX21lc3NhZ2UoXygidW5hYmxlIHRvIHJlbmFtZSBmaWxl OiAlcyB0byAlcyIpLAorCQkJCQl0YXJnZXQsIHNyY25hbWUpOworCQkJYnJl YWs7CisJCX0KKwkJLyogRkFMTCBUSFJVICovCisJY2FzZSBGSUxFX1BIQVNF XzQ6CisJY2FzZSBTTElOS19QSEFTRV80OgorCQkvKiBmb3IgZWFjaCBoYXJk bGluaywgdW5saW5rIGFuZCBjcmVhdCBwb2ludGluZyB0byB0YXJnZXQgKi8K KwkJZm9yIChpID0gMTsgaSA8IG5vZGUtPm51bXBhdGhzOyBpKyspIHsKKwkJ CWlmIChpID09IDEpCisJCQkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgXygi UmVzZXR0aW5nIGhhcmRsaW5rcyAiCisJCQkJCQkidG8gbmV3IGZpbGUiKSk7 CisKKwkJCXJ2YWwgPSB1bmxpbmsobm9kZS0+cGF0aHNbaV0pOworCQkJaWYg KHJ2YWwgIT0gMCkgeworCQkJCWVycl9tZXNzYWdlKF8oInVuYWJsZSB0byBy ZW1vdmUgZmlsZTogJXMiKSwKKwkJCQkJCW5vZGUtPnBhdGhzW2ldKTsKKwkJ CQlicmVhazsKKwkJCX0KKwkJCXJ2YWwgPSBsaW5rKHNyY25hbWUsIG5vZGUt PnBhdGhzW2ldKTsKKwkJCWlmIChydmFsICE9IDApIHsKKwkJCQllcnJfbWVz c2FnZShfKCJ1bmFibGUgdG8gbGluayB0byBmaWxlOiAlcyIpLAorCQkJCQkJ c3JjbmFtZSk7CisJCQkJYnJlYWs7CisJCQl9CisJCX0KKwkJYnJlYWs7CisJ fQorCisJaWYgKHJ2YWwgPT0gMCkgeworCQlsb2dfbWVzc2FnZShMT0dfTk9S TUFMLCBfKCJSZW1vdmluZyByZWNvdmVyIGZpbGU6IFwnJXNcJyIpLAorCQkJ CXJlY292ZXJfZmlsZSk7CisJCXVubGluayhyZWNvdmVyX2ZpbGUpOworCQls b2dfbWVzc2FnZShMT0dfTk9STUFMLCBfKCJSZWNvdmVyeSBkb25lLiIpKTsK Kwl9CisJZWxzZSB7CisJCWxvZ19tZXNzYWdlKExPR19OT1JNQUwsIF8oIkxl YXZpbmcgcmVjb3ZlciBmaWxlOiBcJyVzXCciKSwKKwkJCQlyZWNvdmVyX2Zp bGUpOworCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCBfKCJSZWNvdmVyeSBm YWlsZWQuIikpOworCX0KKworCXJldHVybiBydmFsOworfQorCitpbnQKK21h aW4oCisJaW50CQlhcmdjLAorCWNoYXIJCSphcmd2W10pCit7CisJaW50CQlj ID0gMDsKKwlpbnQJCXJ2YWwgPSAwOworCWludAkJcV9vcHQgPSAwOworCWlu dAkJdl9vcHQgPSAwOworCWludAkJcF9vcHQgPSAwOworCWludAkJbl9vcHQg PSAwOworCWNoYXIJCXBhdGhuYW1lW1BBVEhfTUFYXTsKKwlzdHJ1Y3Qgc3Rh dDY0CXN0OworCisJcHJvZ25hbWUgPSBiYXNlbmFtZShhcmd2WzBdKTsKKwor CXNldGxvY2FsZShMQ19BTEwsICIiKTsKKwliaW5kdGV4dGRvbWFpbihQQUNL QUdFLCBMT0NBTEVESVIpOworCXRleHRkb21haW4oUEFDS0FHRSk7CisKKwl3 aGlsZSAoKGMgPSBnZXRvcHQoYXJnYywgYXJndiwgImZucHF2UDpyOiIpKSAh PSAtMSkgeworCQlzd2l0Y2ggKGMpIHsKKwkJY2FzZSAnZic6CisJCQlmb3Jj ZV9hbGwgPSAxOworCQkJYnJlYWs7CisJCWNhc2UgJ24nOgorCQkJbl9vcHQr KzsKKwkJCWJyZWFrOworCQljYXNlICdwJzoKKwkJCXBfb3B0Kys7CisJCQli cmVhazsKKwkJY2FzZSAncSc6CisJCQlpZiAodl9vcHQpCisJCQkJZXJyX21l c3NhZ2UoXygiJ3EnIG9wdGlvbiBpbmNvbXBhdGlibGUgIgorCQkJCQkJIndp dGggJ3YnIG9wdGlvbiIpKTsKKwkJCXFfb3B0Kys7CisJCQlsb2dfbGV2ZWw9 MDsKKwkJCWJyZWFrOworCQljYXNlICd2JzoKKwkJCWlmIChxX29wdCkKKwkJ CQllcnJfbWVzc2FnZShfKCIndicgb3B0aW9uIGluY29tcGF0aWJsZSAiCisJ CQkJCQkid2l0aCAncScgb3B0aW9uIikpOworCQkJdl9vcHQrKzsKKwkJCWxv Z19sZXZlbCsrOworCQkJYnJlYWs7CisJCWNhc2UgJ1AnOgorCQkJcG9sbF9p bnRlcnZhbCA9IGF0b2kob3B0YXJnKTsKKwkJCWJyZWFrOworCQljYXNlICdy JzoKKwkJCXJlY292ZXJfZmlsZSA9IG9wdGFyZzsKKwkJCWJyZWFrOworCQlk ZWZhdWx0OgorCQkJZXJyX21lc3NhZ2UoXygiJXM6IGlsbGVnYWwgb3B0aW9u IC0tICVjXG4iKSwgYyk7CisJCQl1c2FnZSgpOworCQkJLyogTk9UUkVBQ0hF RCAqLworCQkJYnJlYWs7CisJCX0KKwl9CisKKwlpZiAob3B0aW5kICE9IGFy Z2MgLSAxICYmIHJlY292ZXJfZmlsZSA9PSBOVUxMKSB7CisJCXVzYWdlKCk7 CisJCWV4aXQoMSk7CisJfQorCisJcmVhbHVpZCA9IGdldHVpZCgpOworCXN0 YXJ0dGltZSA9IHRpbWUoMCk7CisKKwlpbml0X25vZGVoYXNoKCk7CisKKwlz aWduYWwoU0lHQUxSTSwgc2lnaGFuZGxlcik7CisJc2lnbmFsKFNJR0FCUlQs IHNpZ2hhbmRsZXIpOworCXNpZ25hbChTSUdIVVAsIHNpZ2hhbmRsZXIpOwor CXNpZ25hbChTSUdJTlQsIHNpZ2hhbmRsZXIpOworCXNpZ25hbChTSUdRVUlU LCBzaWdoYW5kbGVyKTsKKwlzaWduYWwoU0lHVEVSTSwgc2lnaGFuZGxlcik7 CisKKwlpZiAocF9vcHQgJiYgcG9sbF9pbnRlcnZhbCA9PSAwKSB7CisJCXBv bGxfaW50ZXJ2YWwgPSAxOworCX0KKwlpZiAocG9sbF9pbnRlcnZhbCkKKwkJ YWxhcm0ocG9sbF9pbnRlcnZhbCk7CisKKwlpZiAocmVjb3Zlcl9maWxlKSB7 CisJCWJpZ25vZGVfdAkqbm9kZSA9IE5VTEw7CisJCWNoYXIJCSp0YXJnZXQg PSBOVUxMOworCQljaGFyCQkqdG5hbWUgPSBOVUxMOworCQlpbnQJCXBoYXNl ID0gMDsKKworCQlpZiAobl9vcHQpCisJCQlnb3RvIHF1aXQ7CisKKwkJLyog cmVhZCBub2RlIGluZm8gZnJvbSByZWNvdmVyeSBmaWxlICovCisJCWlmIChy ZWFkX3JlY292ZXJfZmlsZShyZWNvdmVyX2ZpbGUsICZub2RlLCAmdGFyZ2V0 LAorCQkJCSZ0bmFtZSwgJnBoYXNlKSAhPSAwKQorCQkJZXhpdCgxKTsKKwor CQlydmFsID0gcmVjb3Zlcihub2RlLCB0YXJnZXQsIHRuYW1lLCBwaGFzZSk7 CisKKwkJZnJlZSh0YXJnZXQpOworCQlmcmVlKHRuYW1lKTsKKworCQlyZXR1 cm4gcnZhbDsKKwl9CisKKwlyZWNvdmVyX2ZpbGUgPSBtYWxsb2MoUEFUSF9N QVgpOworCWlmIChyZWNvdmVyX2ZpbGUgPT0gTlVMTCkgeworCQllcnJfbm9t ZW0oKTsKKwkJZXhpdCgxKTsKKwl9CisJcmVjb3Zlcl9maWxlWzBdID0gJ1ww JzsKKworCXN0cmNweShwYXRobmFtZSwgYXJndltvcHRpbmRdKTsKKwlpZiAo cGF0aG5hbWVbMF0gIT0gJy8nKSB7CisJCWVycl9tZXNzYWdlKF8oInBhdGhu YW1lIG11c3QgYmVnaW4gd2l0aCBhIHNsYXNoICgnLycpIikpOworCQlleGl0 KDEpOworCX0KKworCWlmIChzdGF0NjQocGF0aG5hbWUsICZzdCkgPCAwKSB7 CisJCWVycl9zdGF0KHBhdGhuYW1lKTsKKwkJZXhpdCgxKTsKKwl9CisJaWYg KFNfSVNSRUcoc3Quc3RfbW9kZSkpIHsKKwkJLyogc2luZ2xlIGZpbGUgc3Bl Y2lmaWVkICovCisJCWlmIChzdC5zdF9ubGluayA+IDEpIHsKKwkJCWVycl9t ZXNzYWdlKF8oImNhbm5vdCBwcm9jZXNzIHNpbmdsZSBmaWxlIHdpdGggYSAi CisJCQkJCSJsaW5rIGNvdW50IGdyZWF0ZXIgdGhhbiAxIikpOworCQkJZXhp dCgxKTsKKwkJfQorCisJCXN0cmNweShyZWNvdmVyX2ZpbGUsIHBhdGhuYW1l KTsKKwkJZGlybmFtZShyZWNvdmVyX2ZpbGUpOworCisJCXN0cmNweShyZWNv dmVyX2ZpbGUgKyBzdHJsZW4ocmVjb3Zlcl9maWxlKSwgIi94ZnNfcmVuby5y ZWNvdmVyIik7CisJCWlmICghbl9vcHQpIHsKKwkJCWlmIChvcGVuX3JlY292 ZXJmaWxlKCkgIT0gMCkKKwkJCQlleGl0KDEpOworCQl9CisJCWFkZF9ub2Rl X3BhdGgoc3Quc3RfaW5vLCBGVFdfRiwgcGF0aG5hbWUpOworCX0KKwllbHNl IGlmIChTX0lTRElSKHN0LnN0X21vZGUpKSB7CisJCS8qIGRpcmVjdG9yeSB0 cmVlIHNwZWNpZmllZCAqLworCQlzdHJjcHkocmVjb3Zlcl9maWxlLCBwYXRo bmFtZSk7CisKKwkJc3RyY3B5KHJlY292ZXJfZmlsZSArIHN0cmxlbihyZWNv dmVyX2ZpbGUpLCAiL3hmc19yZW5vLnJlY292ZXIiKTsKKwkJaWYgKCFuX29w dCkgeworCQkJaWYgKG9wZW5fcmVjb3ZlcmZpbGUoKSAhPSAwKQorCQkJCWV4 aXQoMSk7CisJCX0KKworCQkvKiBkaXJlY3Rvcnkgc2NhbiAqLworCQlsb2df bWVzc2FnZShMT0dfSU5GTywgXygiXHJTY2FubmluZyBkaXJlY3RvcnkgdHJl ZS4uLiIpKTsKKwkJU0VUX1BIQVNFKFNDQU5fUEhBU0UpOworCQluZnR3NjQo cGF0aG5hbWUsIG5mdHdfYWRkbm9kZXMsIDEwMCwgRlRXX1BIWVMgfCBGVFdf TU9VTlQpOworCX0KKwllbHNlIHsKKwkJZXJyX21lc3NhZ2UoXygicGF0aG5h bWUgbXVzdCBiZSBlaXRoZXIgYSByZWd1bGFyIGZpbGUgIgorCQkJCSJvciBk aXJlY3RvcnkiKSk7CisJCWV4aXQoMSk7CisJfQorCisJZHVtcF9ub2RlaGFz aCgpOworCisJaWYgKG5fb3B0KSB7CisJCS8qIG4gZmxhZyBzZXQsIGRvbid0 IGRvIGFueXRoaW5nICovCisJCWlmIChudW1kaXJub2RlcykKKwkJCWxvZ19t ZXNzYWdlKExPR19OT1JNQUwsICJccldvdWxkIHByb2Nlc3MgJWQgJXMiLAor CQkJCQludW1kaXJub2RlcywgbnVtZGlybm9kZXMgPT0gMSA/CisJCQkJCQki ZGlyZWN0b3J5IiA6ICJkaXJlY3RvcmllcyIpOworCQllbHNlCisJCQlsb2df bWVzc2FnZShMT0dfTk9STUFMLCAiXHJObyBkaXJlY3RvcmllcyB0byBwcm9j ZXNzIik7CisKKwkJaWYgKG51bWZpbGVub2RlcykKKwkJCS8qIHByb2Nlc3Mg ZmlsZXMgKi8KKwkJCWxvZ19tZXNzYWdlKExPR19OT1JNQUwsICJccldvdWxk IHByb2Nlc3MgJWQgJXMiLAorCQkJCQludW1maWxlbm9kZXMsIG51bWZpbGVu b2RlcyA9PSAxID8KKwkJCQkJCSJmaWxlIiA6ICJmaWxlcyIpOworCQllbHNl CisJCQlsb2dfbWVzc2FnZShMT0dfTk9STUFMLCAiXHJObyBmaWxlcyB0byBw cm9jZXNzIik7CisJCWlmIChudW1zbGlua25vZGVzKQorCQkJLyogcHJvY2Vz cyBmaWxlcyAqLworCQkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgIlxyV291 bGQgcHJvY2VzcyAlZCAlcyIsCisJCQkJCW51bXNsaW5rbm9kZXMsIG51bXNs aW5rbm9kZXMgPT0gMSA/CisJCQkJCQkic3ltbGlueCIgOiAic3ltbGlua3Mi KTsKKwkJZWxzZQorCQkJbG9nX21lc3NhZ2UoTE9HX05PUk1BTCwgIlxyTm8g c3ltbGlua3MgdG8gcHJvY2VzcyIpOworCX0gZWxzZSB7CisJCS8qIHByb2Nl c3MgZGlyZWN0b3JpZXMgKi8KKwkJaWYgKG51bWRpcm5vZGVzKSB7CisJCQls b2dfbWVzc2FnZShMT0dfSU5GTywgXygiXHJQcm9jZXNzaW5nICVkICVzLi4u IiksCisJCQkJCW51bWRpcm5vZGVzLCBudW1kaXJub2RlcyA9PSAxID8KKwkJ CQkJICAgIF8oImRpcmVjdG9yeSIpIDogXygiZGlyZWN0b3JpZXMiKSk7CisJ CQljdXJfcGhhc2UgPSBESVJfUEhBU0U7CisJCQlydmFsID0gZm9yX2FsbF9u b2Rlcyhwcm9jZXNzX2RpciwgRlRXX0QsIDEpOworCQkJaWYgKHJ2YWwgIT0g MCkKKwkJCQlnb3RvIHF1aXQ7CisJCX0KKwkJZWxzZQorCQkJbG9nX21lc3Nh Z2UoTE9HX0lORk8sIF8oIlxyTm8gZGlyZWN0b3JpZXMgdG8gcHJvY2Vzcy4u LiIpKTsKKworCQlpZiAobnVtZmlsZW5vZGVzKSB7CisJCQkvKiBwcm9jZXNz IGZpbGVzICovCisJCQlsb2dfbWVzc2FnZShMT0dfSU5GTywgXygiXHJQcm9j ZXNzaW5nICVkICVzLi4uIiksCisJCQkJCW51bWZpbGVub2RlcywgbnVtZmls ZW5vZGVzID09IDEgPworCQkJCQkJXygiZmlsZSIpIDogXygiZmlsZXMiKSk7 CisJCQljdXJfcGhhc2UgPSBGSUxFX1BIQVNFOworCQkJZm9yX2FsbF9ub2Rl cyhwcm9jZXNzX2ZpbGUsIEZUV19GLCAwKTsKKwkJfQorCQllbHNlCisJCQls b2dfbWVzc2FnZShMT0dfSU5GTywgXygiXHJObyBmaWxlcyB0byBwcm9jZXNz Li4uIikpOworCisJCWlmIChudW1zbGlua25vZGVzKSB7CisJCQkvKiBwcm9j ZXNzIHN5bWxpbmtzICovCisJCQlsb2dfbWVzc2FnZShMT0dfSU5GTywgXygi XHJQcm9jZXNzaW5nICVkICVzLi4uIiksCisJCQkJCW51bXNsaW5rbm9kZXMs IG51bXNsaW5rbm9kZXMgPT0gMSA/CisJCQkJCQlfKCJzeW1saW5rIikgOiBf KCJzeW1saW5rcyIpKTsKKwkJCWN1cl9waGFzZSA9IFNMSU5LX1BIQVNFOwor CQkJZm9yX2FsbF9ub2Rlcyhwcm9jZXNzX3NsaW5rLCBGVFdfU0wsIDApOwor CQl9CisJCWVsc2UKKwkJCWxvZ19tZXNzYWdlKExPR19JTkZPLCBfKCJcck5v IHN5bWxpbmtzIHRvIHByb2Nlc3MuLi4iKSk7CisKKwl9CitxdWl0OgorCWZy ZWVfbm9kZWhhc2goKTsKKworCWNsb3NlKHJlY292ZXJfZmQpOworCisJaWYg KHJ2YWwgPT0gMCkKKwkJdW5saW5rKHJlY292ZXJfZmlsZSk7CisKKwlsb2df bWVzc2FnZShMT0dfREVCVUcsICJcciV1IHNlY29uZHMgZWxhcHNlZCIsIHRp bWUoMCkgLSBzdGFydHRpbWUpOworCWxvZ19tZXNzYWdlKExPR19JTkZPLCBf KCJcckRvbmUuICAgICAiKSk7CisKKwlyZXR1cm4gcnZhbCB8IGdsb2JhbF9y dmFsOworfQo= ------------MAhJ3q66PgIP4VwapyTDNq-- From owner-xfs@oss.sgi.com Wed Oct 3 22:16:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 22:16:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l945G0Kk015585 for ; Wed, 3 Oct 2007 22:16:03 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23316; Thu, 4 Oct 2007 15:15:57 +1000 Message-ID: <4704780C.2020100@sgi.com> Date: Thu, 04 Oct 2007 15:20:12 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: review: fix infinite loop in bulkstat Content-Type: multipart/mixed; boundary="------------030308020602070609060809" X-Virus-Scanned: ClamAV 0.91.2/4463/Wed Oct 3 21:27:04 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13245 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------030308020602070609060809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This fix prevents bulkstat from spinning in an infinite loop. Here 'agino' increments through the inodes in an allocation group. At the end of the innermost 'for' loop it will hold the value of the next inode to look at (ie the first inode in the next cluster/chunk). Assigning 'lastino' to 'agino' resets it to the last inode in the last inode cluster we just looked at. This causes us to look up the very same cluster and examine all the inodes all over again, and again, and again... We also want to set 'lastino' for the cases when we're not interested in the inode so that the next call to bulkstat wont re-examine the same uninteresting inodes. --------------030308020602070609060809 Content-Type: text/x-patch; name="bulkstat.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bulkstat.diff" --- fs/xfs/xfs_itable.c_1.155 2007-10-03 13:05:22.000000000 +1000 +++ fs/xfs/xfs_itable.c 2007-10-04 12:16:46.000000000 +1000 @@ -622,8 +622,10 @@ xfs_bulkstat( /* * Skip if this inode is free. */ - if (XFS_INOBT_MASK(chunkidx) & irbp->ir_free) + if (XFS_INOBT_MASK(chunkidx) & irbp->ir_free) { + lastino = ino; continue; + } /* * Count used inodes as free so we can tell * when the chunk is used up. @@ -632,8 +634,10 @@ xfs_bulkstat( ino = XFS_AGINO_TO_INO(mp, agno, agino); bno = XFS_AGB_TO_DADDR(mp, agno, agbno); if (!xfs_bulkstat_use_dinode(mp, flags, bp, - clustidx, &dip)) + clustidx, &dip)) { + lastino = ino; continue; + } /* * If we need to do an iget, cannot hold bp. * Drop it, until starting the next cluster. @@ -694,8 +698,7 @@ xfs_bulkstat( if (end_of_ag) { agno++; agino = 0; - } else - agino = XFS_INO_TO_AGINO(mp, lastino); + } } else break; } --------------030308020602070609060809-- From owner-xfs@oss.sgi.com Wed Oct 3 23:22:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 23:22:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l946M8tl021452 for ; Wed, 3 Oct 2007 23:22:11 -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 QAA25020; Thu, 4 Oct 2007 16:22:02 +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 l946M1dD43690191; Thu, 4 Oct 2007 16:22:02 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l946LxEM50206151; Thu, 4 Oct 2007 16:21:59 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 4 Oct 2007 16:21:59 +1000 From: David Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss Subject: Re: review: fix infinite loop in bulkstat Message-ID: <20071004062159.GN995458@sgi.com> References: <4704780C.2020100@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4704780C.2020100@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4463/Wed Oct 3 21:27:04 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13246 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 On Thu, Oct 04, 2007 at 03:20:12PM +1000, Lachlan McIlroy wrote: > This fix prevents bulkstat from spinning in an infinite loop. > > Here 'agino' increments through the inodes in an allocation group. > At the end of the innermost 'for' loop it will hold the value of the > next inode to look at (ie the first inode in the next cluster/chunk). > Assigning 'lastino' to 'agino' resets it to the last inode in the > last inode cluster we just looked at. This causes us to look up > the very same cluster and examine all the inodes all over again, > and again, and again... > > We also want to set 'lastino' for the cases when we're not interested > in the inode so that the next call to bulkstat wont re-examine the > same uninteresting inodes. Looks OK. I think you shoul dalso add a comment to the effect that lastino needs to be set before continuing to process the next inode in the loop so it doesn't get forgotten next time someone modifies the code inside the loop.. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 3 23:27:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 03 Oct 2007 23:27:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l946QvWJ022238 for ; Wed, 3 Oct 2007 23:27:00 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA25076; Thu, 4 Oct 2007 16:26:52 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 557B2307DB15; Thu, 4 Oct 2007 16:26:52 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - Refactor xfs_mountfs Message-Id: <20071004062652.557B2307DB15@linuxbuild.melbourne.sgi.com> Date: Thu, 4 Oct 2007 16:26:52 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4463/Wed Oct 3 21:27:04 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13247 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Refactor xfs_mountfs Refactoring xfs_mountfs() to call sub-functions for logical chunks can help save a bit of stack, and can make it easier to read this long function. The mount path is one of the longest common callchains, easily getting to within a few bytes of the end of a 4k stack when over lvm, quotas are enabled, and quotacheck must be done. With this change on top of the other stack-related changes I've sent, I can get xfs to survive a normal xfsqa run on 4k stacks over lvm. Signed-off-by: Eric Sandeen Date: Thu Oct 4 16:26:05 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29834a fs/xfs/xfs_mount.c - 1.415 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.415&r2=text&tr2=1.414&f=h - Refactor xfs_mountfs From owner-xfs@oss.sgi.com Thu Oct 4 00:00:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 00:01:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9470YgV029871 for ; Thu, 4 Oct 2007 00:00:38 -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 RAA25788; Thu, 4 Oct 2007 17:00:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id A810158C38F1; Thu, 4 Oct 2007 17:00:30 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 907752 - Fix minor errors and some clarification of man pages Message-Id: <20071004070030.A810158C38F1@chook.melbourne.sgi.com> Date: Thu, 4 Oct 2007 17:00:30 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/4468/Wed Oct 3 22:56:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13248 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Date: Thu Oct 4 17:00:02 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: u-kusaka@wm.jp.nec.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29836a xfsprogs/doc/CHANGES - 1.247 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.247&r2=text&tr2=1.246&f=h xfsprogs/man/man8/xfs_logprint.8 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_logprint.8.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/man/man8/xfs_db.8 - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_db.8.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/man/man8/mkfs.xfs.8 - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/mkfs.xfs.8.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfsprogs/man/man8/xfs_repair.8 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_repair.8.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/man/man8/xfs_freeze.8 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_freeze.8.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsprogs/man/man8/xfs_metadump.8 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_metadump.8.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Fix minor errors and some clarifications in man pages From owner-xfs@oss.sgi.com Thu Oct 4 00:02:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 00:02:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9472S0p030384 for ; Thu, 4 Oct 2007 00:02:30 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l944h1m2010328 for ; Thu, 4 Oct 2007 13:43:16 +0900 (JST) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l944dvdE025122 for ; Thu, 4 Oct 2007 13:39:57 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l944duJ28955 for xfs@oss.sgi.com; Thu, 4 Oct 2007 13:39:56 +0900 (JST) Received: from kaishu.jp.nec.com (kaishu.jp.nec.com [10.26.220.5]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l944duY15042 for ; Thu, 4 Oct 2007 13:39:56 +0900 (JST) Received: from TNESG9305.wm.jp.nec.com ([10.64.168.199] [10.64.168.199]) by mail.jp.nec.com with ESMTP; Thu, 4 Oct 2007 13:39:55 +0900 Message-Id: <200710040439.AA06067@TNESG9305.wm.jp.nec.com> From: Utako Kusaka Date: Thu, 04 Oct 2007 13:39:54 +0900 To: xfs@oss.sgi.com Subject: [PATCH] Fix errors in xfsprogs man page. MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/4468/Wed Oct 3 22:56:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13249 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: u-kusaka@wm.jp.nec.com Precedence: bulk X-list: xfs Hi, This patch includes following fix in xfsprogs man page. 1. Fix 3 errors in mkfs.xfs. 2. Fix one error in xfs_freeze. 3. Fix one error in xfs_logprint. 4. Fix one error in xfs_repair. 5. Fix 3 errors in xfs_db. And add comma for readability. 6. Change description of obfuscation in xfs_metadump. Man page of xfs_metadump says about obfuscation of only directory and extended attribute name. But xfs_metadump obfuscates regular file and symbolic link name too. Utako Signed-off-by: Utako Kusaka --- diff -uprN xfsprogs-2.9.4.orig/man/man8/mkfs.xfs.8 xfsprogs-2.9.4/man/man8/mkfs.xfs.8 --- xfsprogs-2.9.4.orig/man/man8/mkfs.xfs.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/mkfs.xfs.8 2007-10-03 10:00:53.000000000 +0900 @@ -567,7 +567,7 @@ syntax on line 7. This syntax directs th command to terminate the branch of the filesystem it is currently on and then continue from the directory specified by -the next line,in this case line 8 +the next line, in this case line 8. It must be the last character on a line. The colon @@ -610,13 +610,13 @@ The third character of the mode string i used to specify the setgroupID mode, in which case it is .BR g . -If setgroupID mode is not specified, the second character is +If setgroupID mode is not specified, the third character is .BR \- . The remaining characters of the mode string are a three digit octal number. This octal number defines the owner, group, and other read, write, and execute permissions for the file, respectively. -Form more information on file permissions, see the +For more information on file permissions, see the .BR chmod (1) command. .IP diff -uprN xfsprogs-2.9.4.orig/man/man8/xfs_db.8 xfsprogs-2.9.4/man/man8/xfs_db.8 --- xfsprogs-2.9.4.orig/man/man8/xfs_db.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/xfs_db.8 2007-10-03 10:53:56.000000000 +0900 @@ -153,30 +153,30 @@ See the command. .TP .BI ablock " filoff" -Set current address to the offset . -I filoff +Set current address to the offset +.I filoff (a filesystem block number) in the attribute area of the current inode. .TP .BI "addr [" field-expression ] Set current address to the value of the .IR field-expression . This is used to "follow" a reference in one structure to the object -being referred to. If no argument is given the current address is printed. +being referred to. If no argument is given, the current address is printed. .TP .BI "agf [" agno ] Set current address to the AGF block for allocation group .IR agno . -If no argument is given use the current allocation group. +If no argument is given, use the current allocation group. .TP .BI "agfl [" agno ] Set current address to the AGFL block for allocation group .IR agno . -If no argument is given use the current allocation group. +If no argument is given, use the current allocation group. .TP .BI "agi [" agno ] Set current address to the AGI block for allocation group .IR agno . -If no argument is given use the current allocation group. +If no argument is given, use the current allocation group. .TP .B b See the @@ -413,8 +413,8 @@ Set current address to the daddr (512 by .IR d . If no value for .I d -is given the current address is printed, expressed as a daddr. -The type is set to . +is given, the current address is printed, expressed as a daddr. +The type is set to .B data (uninterpreted). .TP @@ -641,7 +641,7 @@ Set current address to SB header in allo .IR agno . If no .I agno -is given use the current allocation group number. +is given, use the current allocation group number. .TP .BI "source " source-file Process commands from @@ -789,7 +789,7 @@ number of blocks held in the AGF Btrees. .PD .RE .TP -.B agf +.B agfl The AGFL block contains block numbers for use of the block allocator; it is in the fourth 512-byte block of each allocation group. Each entry in the active list is a block number within the allocation group diff -uprN xfsprogs-2.9.4.orig/man/man8/xfs_freeze.8 xfsprogs-2.9.4/man/man8/xfs_freeze.8 --- xfsprogs-2.9.4.orig/man/man8/xfs_freeze.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/xfs_freeze.8 2007-10-02 17:15:42.000000000 +0900 @@ -43,7 +43,7 @@ or a clean mount of the snapshot is comp .PP The .B \-u -flagq is used to un-freeze the filesystem and allow +flag is used to un-freeze the filesystem and allow operations to continue. Any filesystem modifications that were blocked by the freeze are unblocked and allowed to complete. diff -uprN xfsprogs-2.9.4.orig/man/man8/xfs_logprint.8 xfsprogs-2.9.4/man/man8/xfs_logprint.8 --- xfsprogs-2.9.4.orig/man/man8/xfs_logprint.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/xfs_logprint.8 2007-10-02 16:36:45.000000000 +0900 @@ -76,7 +76,7 @@ This might happen if an image copy of a an ordinary file with .BR xfs_copy (8). .TP -.B \-l +.BI \-l " logdev" External log device. Only for those filesystems which use an external log. .TP .B \-i diff -uprN xfsprogs-2.9.4.orig/man/man8/xfs_metadump.8 xfsprogs-2.9.4/man/man8/xfs_metadump.8 --- xfsprogs-2.9.4.orig/man/man8/xfs_metadump.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/xfs_metadump.8 2007-10-04 11:16:44.000000000 +0900 @@ -39,11 +39,12 @@ filesystem's metadata and indexes to whe .PP By default, .B xfs_metadump -obfuscates most directory names and extended attribute names to allow the dumps -to be sent without revealing confidential information. Extended attribute -values are zeroed and no data is copied. The only exceptions are directory -or attribute names that are 4 or less characters in length. Also directory -names that span extents (this can only occur with the +obfuscates most file (regular file, directory and symbolic link) names +and extended attribute names to allow the dumps to be sent without +revealing confidential information. Extended attribute values are zeroed +and no data is copied. The only exceptions are file or attribute names +that are 4 or less characters in length. Also file names that span extents +(this can only occur with the .BR mkfs.xfs (8) options where .B \-n @@ -128,4 +129,4 @@ command. .BR xfs (5) .SH BUGS Email bug reports to -.BR xfs@oss.sgi.com . \ No newline at end of file +.BR xfs@oss.sgi.com . diff -uprN xfsprogs-2.9.4.orig/man/man8/xfs_repair.8 xfsprogs-2.9.4/man/man8/xfs_repair.8 --- xfsprogs-2.9.4.orig/man/man8/xfs_repair.8 2007-09-11 11:01:19.000000000 +0900 +++ xfsprogs-2.9.4/man/man8/xfs_repair.8 2007-10-02 17:24:56.000000000 +0900 @@ -110,8 +110,7 @@ is 1024 (for a total of 8192 entries). overrides the default buffer cache hash size. The total number of buffer cache entries are limited to 8 times this amount. The default size is set to use up the remainder of 75% of the system's physical -RAM. -size +RAM size. .TP .BI ag_stride= ags_per_concat_unit This creates additional processing threads to parallel process From owner-xfs@oss.sgi.com Thu Oct 4 01:16:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 01:16:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l948GFrW012998 for ; Thu, 4 Oct 2007 01:16:18 -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 6024622D91; Thu, 4 Oct 2007 10:16:15 +0200 (CEST) From: Andi Kleen To: nscott@aconex.com Subject: Re: [PATCH] XFS bitops to Linux again Date: Thu, 4 Oct 2007 10:14:22 +0200 User-Agent: KMail/1.9.1 Cc: xfs@oss.sgi.com References: <200710040027.16926.ak@suse.de> <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> In-Reply-To: <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710041014.22936.ak@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4468/Wed Oct 3 22:56:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13250 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 > Several of these call sites are also compiled in userspace in libxfs. It > would > be a good idea from that POV also to keep some level of abstraction so that > these calls can be mapped to userspace routines as well. Again the same argument applies -- there is no difference if you map xfs_(high|low)bit or fls64/fls/find_find_bit() to something else. > > The resulting xfs.ko is about 500 bytes smaller on x86-64 > > Thats it? It's probably a little faster too (admittedly unlikely to be really measurable in a macro benchmark) and the source code is smaller. > What testing was done? Changes to some of these routines has introuced > subtle log recovery bugs in the past - has recovery been tested at all? > The QA > suite has some log recovery tests, it'd be a good idea to verify with > those.. I had a simple separate unit test to verify the 32bit space gave the same result. The only difference was the 0 case, but I checked all inputs manually. Usually they had != 0 tests already or zero was impossible; in the few cases were not I added ASSERTs -- so if i got it wrong it should bomb out quickly. I did also some simple tests using the QA suite -- i believe a few logs were recovered -- but not the full tests. > To be honest, this sounds like just code churn and risk > introduction. Ok I got the message. I retract the patch. Sorry for bothering you with lowly cleanups. -Andi From owner-xfs@oss.sgi.com Thu Oct 4 01:42:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 01:42:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l948gbpV016409 for ; Thu, 4 Oct 2007 01:42:40 -0700 Received: by fk-out-0910.google.com with SMTP id 18so87669fks for ; Thu, 04 Oct 2007 01:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=TvESSFlLDNYg6gUF7xhgFw1AJGnWN6qsLSookqeT76s=; b=I9uqI0el746TOm5hwGYdl+vDGC582Pg4hO7JS87pWH4N6LSGj35FAdvh1dBOrFrgV9KZxjxE+lhGCQ0S2YJRI7fS6giYtCGqk5SqUUllR0AgyTwZybpdWySz073Nkqj76zjauEew1TPFwjJ+HzMPfuqUbtCT+bgtoV1fgAovkfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=NIvMMfXUWPuP75QFwHzZpB2Rbzv5uyQjY54LvgB/8Yn5ND/oUbQ+fYmN6TVaeydt5VVf+lV8PA8zeFx1eJw7xjDsofomkGbWrAc8TL8lJ1Qed0EJ+jFEOQzXIhA0NwoDRHOoMTeRUQEloeLpppYL72zZZZMaueRCvESkfp/3u8o= Received: by 10.82.126.5 with SMTP id y5mr1089791buc.1191483569550; Thu, 04 Oct 2007 00:39:29 -0700 (PDT) Received: from nb58.mainapanettoni.com ( [213.82.85.147]) by mx.google.com with ESMTPS id g12sm1831377nfb.2007.10.04.00.39.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2007 00:39:28 -0700 (PDT) From: Alessandro Bono To: David Chinner Subject: Re: 2.6.23-rc9-git1 hang with XFS Date: Thu, 4 Oct 2007 09:39:25 +0200 User-Agent: KMail/1.9.7 Cc: linux-xfs@oss.sgi.com References: <20071004003935.GC23367404@sgi.com> In-Reply-To: <20071004003935.GC23367404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710040939.26139.alessandro.bono@gmail.com> X-Virus-Scanned: ClamAV 0.91.2/4468/Wed Oct 3 22:56:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13251 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alessandro.bono@gmail.com Precedence: bulk X-list: xfs On Thursday 04 October 2007, David Chinner wrote: > On Wed, Oct 03, 2007 at 11:03:29PM +0200, Alessandro Bono wrote: > > Hi all > > > > I'm testing 2.6.23-rc9-git1 on my old home server > > Trying to reorganizer my xfs filesystem with xfs_fsr cause a sort of > > system hang > > xfs_fsr is waiting for a direct I/O to complete. > Other processes are waiting for the superblock I/O to compete > (which is why writes are hanging), an dothers are waiting > for iclog space to be freed up. I think something is holding > > off I/O completion, and this: > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > indicates someone trying a DOS on your box. Perhaps it's > succeeding by denying interrupt service to you disks? it's really difficult, my internet line is a normal adsl2 and this machine is really rock solid with ubuntu dapper kernel (uptime of several months and mldonkey, mlnet process, is always on) also after reboot raid5 start resyncronizing disk and after 2 hours system ends this operation without any problem (mldonkey on) > > If you pull the network cable, does the system start to respond > properly again? I'll try this evening Thanks > > Cheers, > > Dave. -- Cordiali saluti Alessandro Bono From owner-xfs@oss.sgi.com Thu Oct 4 03:48:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 03:48:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.3.0-r574664 Received: from smtp-out3.libero.it (smtp-out3.libero.it [212.52.84.43]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94AmQwe000681 for ; Thu, 4 Oct 2007 03:48:30 -0700 Received: from outrelay08.libero.it (192.168.32.103) by smtp-out3.libero.it (7.3.120) id 4688F31B0A2E0AF3 for linux-xfs@oss.sgi.com; Thu, 4 Oct 2007 12:48:27 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIJhBEfAqBEC/2dsb2JhbAAM Received: from unknown (HELO libero.it) ([192.168.17.2]) by outrelay08.libero.it with ESMTP; 04 Oct 2007 12:48:23 +0200 Date: Thu, 4 Oct 2007 12:48:23 +0200 Message-Id: Subject: selected. MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "romandajason" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 82.171.29.182 To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l94AmVwe000686 X-archive-position: 13252 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: romandajason@libero.it Precedence: bulk X-list: xfs We are pleased to inform you of the announcement today 4th october, 2007 of winners of the Staats Loterij Sweepstakes International Promo held on 1st October 2007. please contact claims release officer;Name: Mr.Jude Fabian Tel: +31-643-663-271 Email:fiduciaryclm@aim.com Cheers ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind http://i-mode.wind.it/ From owner-xfs@oss.sgi.com Thu Oct 4 03:59:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 04:00:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94AxuAr002500 for ; Thu, 4 Oct 2007 03:59:59 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 23CF61C0A4B72; Thu, 4 Oct 2007 06:59:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 1F9A2400FCB4; Thu, 4 Oct 2007 06:59:57 -0400 (EDT) Date: Thu, 4 Oct 2007 06:59:57 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: David Chinner cc: Timothy Shimmin , Lachlan McIlroy , Eric Sandeen , xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit In-Reply-To: <20071004002611.GB23367404@sgi.com> Message-ID: References: <20071001072350.DF61C58C4C0A@chook.melbourne.sgi.com> <4700EE2A.1020304@sandeen.net> <4701A1D0.5010709@sgi.com> <4701ED51.8050706@sgi.com> <4702F517.3040502@sgi.com> <20071004002611.GB23367404@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13253 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 On Thu, 4 Oct 2007, David Chinner wrote: > On Wed, Oct 03, 2007 at 04:11:50AM -0400, Justin Piszcz wrote: >> If one with was running 2.6.23-rc8 with XFS, does that mean we should run >> xfs_repair on our filesystems after upgrading to -rc9? > > Only if you had unclean shutdowns while running 2.6.23-rc8. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > K, thanks. Justin. From owner-xfs@oss.sgi.com Thu Oct 4 04:00:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 04:00:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.3.0-r574664 Received: from smtp-out1.libero.it (smtp-out1.libero.it [212.52.84.41]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94B0L42002635; Thu, 4 Oct 2007 04:00:23 -0700 Received: from mailrelay07.libero.it (192.168.32.94) by smtp-out1.libero.it (7.3.120) id 4688F3170A191C52; Thu, 4 Oct 2007 12:35:53 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANBeBEfAqBEL/2dsb2JhbAAM Received: from unknown (HELO libero.it) ([192.168.17.11]) by outrelay07.libero.it with ESMTP; 04 Oct 2007 12:35:53 +0200 Date: Thu, 4 Oct 2007 12:35:53 +0200 Message-Id: Subject: selected. MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "romandajason" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 82.171.29.182 To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l94B0N42002646 X-archive-position: 13254 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: romandajason@libero.it Precedence: bulk X-list: xfs We are pleased to inform you of the announcement today 4th october, 2007 of winners of the Staats Loterij Sweepstakes International Promo held on 1st October 2007. please contact claims release officer;Name: Mr.Jude Fabian Tel: +31-643-663-271 Email:fiduciaryclm@aim.com Cheers ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind http://i-mode.wind.it/ From owner-xfs@oss.sgi.com Thu Oct 4 06:11:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 06:11:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94DBEgt024255 for ; Thu, 4 Oct 2007 06:11:17 -0700 Received: from Liberator.local (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 AF41018194494; Thu, 4 Oct 2007 08:11:13 -0500 (CDT) Message-ID: <4704E671.40105@sandeen.net> Date: Thu, 04 Oct 2007 08:11:13 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andi Kleen CC: nscott@aconex.com, xfs@oss.sgi.com Subject: Re: [PATCH] XFS bitops to Linux again References: <200710040027.16926.ak@suse.de> <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> <200710041014.22936.ak@suse.de> In-Reply-To: <200710041014.22936.ak@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13255 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 Andi Kleen wrote: >> To be honest, this sounds like just code churn and risk >> introduction. > > Ok I got the message. I retract the patch. Sorry for bothering you > with lowly cleanups. > > -Andi Hrmph. I liked it. Every change has risk but why bother duplicating existing kernel infrastructure? Compared to everything else going on lately this hardly seems worth NAKing. (though I'm sure the same complaint/warning/caution could be leveled at the other boatload of changes in the past month). -Eric From owner-xfs@oss.sgi.com Thu Oct 4 06:50:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 06:50:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_23, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94Do2pk029591 for ; Thu, 4 Oct 2007 06:50:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 60368303773A for ; Thu, 4 Oct 2007 15:33:03 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPdNBRtTcwWE for ; Thu, 4 Oct 2007 15:33:03 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 2CA333000314 for ; Thu, 4 Oct 2007 15:33:03 +0200 (CEST) Received: by zenon.apartia.fr (Postfix, from userid 1000) id 8B4A1F0A25382; Thu, 4 Oct 2007 15:33:02 +0200 (CEST) Date: Thu, 4 Oct 2007 15:33:02 +0200 From: vindex+lists-xfs@apartia.org To: xfs@oss.sgi.com Subject: Crash on 2.6.21.7 Vanilla + DRBD 0.7 Message-ID: <20071004133302.GA5058@apartia.fr> Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13256 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Hi, I did compile a fresh 2.6.21.7 kernel from kernel.org (no distro patch, ....), and latest svn (3062) 0.7.X drbd. After just 2 days of uptime, I did experience another crash. I wonder if it is an XFS related bug, a DRBD one, or related to XFS on top of DRBD. This bug seems to occur with intensive IO operations. What do you think about it ? Thanks Oct 3 18:55:23 kernel: Oops: 0002 [#1] Oct 3 18:55:23 kernel: SMP Oct 3 18:55:23 kernel: CPU: 7 Oct 3 18:55:23 kernel: EIP: 0060:[] Not tainted VLI Oct 3 18:55:23 kernel: EFLAGS: 00010046 (2.6.21-dl380-g5-20071001 #1) Oct 3 18:55:23 kernel: EIP is at cache_alloc_refill+0x11c/0x4f0 Oct 3 18:55:23 kernel: eax: f79c2940 ebx: 00000015 ecx: 00000005 edx: 65b567b0 Oct 3 18:55:23 kernel: esi: 0000000a edi: d5d26000 ebp: f79d03c0 esp: d2531c98 Oct 3 18:55:23 kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Oct 3 18:55:23 kernel: Process rsync (pid: 22409, ti=d2530000 task=da1e8070 task.ti=d2530000) Oct 3 18:55:23 kernel: Stack: 00000010 000002d0 ce9ca0b8 000002d0 f79cfe00 f79d1c00 f79c2940 00000000 Oct 3 18:55:23 kernel: 00000001 d2531cd4 ce9ca088 c022aade d5d2601c 00000282 f79cfe00 000002d0 Oct 3 18:55:23 kernel: f79cfe00 c01652e6 00000000 00000001 c0265a4e 00000011 d2531d60 d7acfb40 Oct 3 18:55:23 kernel: Call Trace: Oct 3 18:55:23 kernel: [] xfs_da_brelse+0x6e/0xb0 Oct 3 18:55:23 kernel: [] kmem_cache_alloc+0x46/0x50 Oct 3 18:55:23 kernel: [] kmem_zone_alloc+0x4e/0xc0 Oct 3 18:55:23 kernel: [] xfs_fs_alloc_inode+0xf/0x20 Oct 3 18:55:23 kernel: [] alloc_inode+0x16/0x170 Oct 3 18:55:23 kernel: [] iget_locked+0x59/0x130 Oct 3 18:55:23 kernel: [] xfs_iget+0x78/0x160 Oct 3 18:55:23 kernel: [] xfs_acl_vget+0x6c/0x160 Oct 3 18:55:23 kernel: [] xfs_dir_lookup_int+0x93/0xf0 Oct 3 18:55:23 kernel: [] xfs_lookup+0x75/0xa0 Oct 3 18:55:23 kernel: [] xfs_vn_lookup+0x52/0x90 Oct 3 18:55:23 kernel: [] do_lookup+0x148/0x190 Oct 3 18:55:23 kernel: [] __link_path_walk+0x814/0xe40 Oct 3 18:55:23 kernel: [] link_path_walk+0x45/0xc0 Oct 3 18:55:23 kernel: [] do_path_lookup+0x81/0x1c0 Oct 3 18:55:23 kernel: [] getname+0xb3/0xe0 Oct 3 18:55:23 kernel: [] __user_walk_fd+0x3b/0x60 Oct 3 18:55:23 kernel: [] vfs_lstat_fd+0x1f/0x50 Oct 3 18:55:23 kernel: [] sys_lstat64+0xf/0x30 Oct 3 18:55:23 kernel: [] sysenter_past_esp+0x5d/0x81 Oct 3 18:55:23 kernel: ======================= Oct 3 18:55:23 kernel: Code: 10 8b 77 14 01 c2 8b 44 24 30 8b 34 b0 89 77 14 89 54 8d 14 8d 51 01 89 55 00 8b 44 24 10 8b 77 10 3b 70 5c 72 c0 8b 17 8b 47 04 <89> 42 04 89 10 83 7f 14 ff c7 07 00 01 10 00 c7 47 04 00 02 20 Oct 3 18:55:23 kernel: EIP: [] cache_alloc_refill+0x11c/0x4f0 SS:ESP 0068:d2531c98 Oct 3 18:55:26 kernel: Oops: 0002 [#2] Oct 3 18:55:26 kernel: SMP Oct 3 18:55:26 kernel: CPU: 7 Oct 3 18:55:26 kernel: EIP: 0060:[] Not tainted VLI Oct 3 18:55:26 kernel: EFLAGS: 00210282 (2.6.21-dl380-g5-20071001 #1) Oct 3 18:55:26 kernel: EIP is at alloc_inode+0x20/0x170 Oct 3 18:55:26 kernel: eax: b4fd89ba ebx: b4fd89ba ecx: b4fd89ba edx: b4fd89ba Oct 3 18:55:26 kernel: esi: f29bb000 edi: f29bb000 ebp: ca743575 esp: d6747c64 Oct 3 18:55:26 kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Oct 3 18:55:26 kernel: Process imapd (pid: 20054, ti=d6746000 task=e04a20b0 task.ti=d6746000) Oct 3 18:55:26 kernel: Stack: 00000000 c76fe0dc f29bb000 c017bd89 ffffffff ffffffff c04abda0 ca743575 Oct 3 18:55:26 kernel: ca743575 f53b5800 c023fa38 cb2b4524 1b2595f3 00000020 f0dd7400 ded8b7a8 Oct 3 18:55:26 kernel: 00000000 f53b5800 c04abda0 cb2b4524 cb2b4524 ca743575 00000000 00000004 Oct 3 18:55:26 kernel: Call Trace: Oct 3 18:55:26 kernel: [] iget_locked+0x59/0x130 Oct 3 18:55:26 kernel: [] xfs_iget+0x78/0x160 Oct 3 18:55:26 kernel: [] xfs_trans_iget+0x117/0x190 Oct 3 18:55:26 kernel: [] xfs_ialloc+0xc7/0x570 Oct 3 18:55:26 kernel: [] xlog_grant_push_ail+0x3c/0x150 Oct 3 18:55:26 kernel: [] xfs_dir_ialloc+0x81/0x2d0 Oct 3 18:55:26 kernel: [] xfs_trans_reserve+0xab/0x230 Oct 3 18:55:26 kernel: [] xfs_create+0x395/0x6a0 Oct 3 18:55:26 kernel: [] xfs_iunlock+0x85/0xa0 Oct 3 18:55:26 kernel: [] xfs_vn_mknod+0x235/0x360 Oct 3 18:55:26 kernel: [] vfs_create+0xdd/0x140 Oct 3 18:55:26 kernel: [] open_namei+0x58e/0x5f0 Oct 3 18:55:26 kernel: [] do_filp_open+0x2e/0x60 Oct 3 18:55:26 kernel: [] get_unused_fd+0x4f/0xb0 Oct 3 18:55:26 kernel: [] do_sys_open+0x4a/0xe0 Oct 3 18:55:26 kernel: [] sys_open+0x1c/0x20 Oct 3 18:55:26 kernel: [] sysenter_past_esp+0x5d/0x81 Oct 3 18:55:26 kernel: ======================= Oct 3 18:55:26 kernel: Code: 90 90 90 90 90 90 90 90 90 90 90 57 56 89 c6 53 8b 40 20 8b 10 85 d2 0f 84 1e 01 00 00 89 f0 ff d2 89 c3 85 db 0f 84 ee 00 00 00 <89> b3 98 00 00 00 b9 02 00 00 00 0f b6 46 10 8d bb f8 00 00 00 Oct 3 18:55:26 kernel: EIP: [] alloc_inode+0x20/0x170 SS:ESP 0068:d6747c64 From owner-xfs@oss.sgi.com Thu Oct 4 07:27:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 07:27:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94ERKZh003653 for ; Thu, 4 Oct 2007 07:27:22 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IdRfb-0001f6-Vb for xfs@oss.sgi.com; Thu, 04 Oct 2007 07:27:19 -0700 Message-ID: <13040897.post@talk.nabble.com> Date: Thu, 4 Oct 2007 07:27:19 -0700 (PDT) From: cyjoyp To: xfs@oss.sgi.com Subject: Reading directory entries from BMAP MIME-Version: 1.0 X-Nabble-From: cyjoyp@gmail.com X-Virus-Scanned: ClamAV 0.91.2/4470/Thu Oct 4 03:09:08 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1467 X-archive-position: 13257 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cyjoyp@gmail.com Precedence: bulk X-list: xfs Hi there, I am a beginner in learning XFS file system.. I have a doubt, dont know whether is silly..If you could help me with this...Thank you.. An extent is 128 bit in size and uses the following struct, typedef struct xfs_bmbt_irec { xfs_fileoff_t br_startoff; xfs_fsblock_t br_startblock; xfs_filblks_t br_blockcount; xfs_exntst_t br_state; } I have got in to the BMAP position after traversing the BTREE.. The BMAP has a leaf and no other siblings.. I have the extents for directory entries stored in the BMAP.. This is where is struck badly.. Now I have a 16 byte value from which I can calculate the block count ,AG number ,etc... 00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02 In this case I lan up some where else instead going to the block of directory entries.. This br_startoff (logical offset) is causing a difference...I am going wrong somwhere in this case.. Could you please tell me br_startoff does really mean??? -- View this message in context: http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13040897 Sent from the Xfs - General mailing list archive at Nabble.com. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Oct 4 08:04:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 08:04:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_50,RCVD_ILLEGAL_IP autolearn=no version=3.3.0-r574664 Received: from mailout1.imos.net (mailout1.imos.net [212.87.132.33]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94F41sE009154 for ; Thu, 4 Oct 2007 08:04:03 -0700 Received: from homer.imos.net (homer.imos.net [212.87.132.35]) by mailout1.imos.net (8.14.1/8.14.1) with ESMTP id l94ERuCJ029567 for ; Thu, 4 Oct 2007 16:27:56 +0200 Received: from lstyd.imos.net (lstyd.imos.net [212.87.130.122]) by homer.imos.net (8.14.1/8.14.1) with ESMTP id l94ERtPs013453 for ; Thu, 4 Oct 2007 16:27:56 +0200 Received: from [5.15.153.128] ([5.15.153.128]) by lstyd.imos.net (8.14.0/8.13.7) with ESMTP id l94HGY1a014325 for ; Thu, 4 Oct 2007 19:16:35 +0200 Message-ID: <4704F86F.9030508@theendofthetunnel.de> Date: Thu, 04 Oct 2007 16:27:59 +0200 From: Hannes Dorbath User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 References: <20071004133302.GA5058@apartia.fr> In-Reply-To: <20071004133302.GA5058@apartia.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 06:22:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13258 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: light@theendofthetunnel.de Precedence: bulk X-list: xfs On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: > What do you think about it ? Is that by any chance a kernel with 4k stack size? -- Regards, Hannes Dorbath From owner-xfs@oss.sgi.com Thu Oct 4 08:04:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 08:04:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_50,RCVD_ILLEGAL_IP autolearn=no version=3.3.0-r574664 Received: from mailout1.imos.net (mailout1.imos.net [212.87.132.33]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94F41sG009154 for ; Thu, 4 Oct 2007 08:04:04 -0700 Received: from homer.imos.net (homer.imos.net [212.87.132.35]) by mailout1.imos.net (8.14.1/8.14.1) with ESMTP id l94EZ2Ya030875 for ; Thu, 4 Oct 2007 16:35:02 +0200 Received: from lstyd.imos.net (lstyd.imos.net [212.87.130.122]) by homer.imos.net (8.14.1/8.14.1) with ESMTP id l94EZ1G1021671 for ; Thu, 4 Oct 2007 16:35:01 +0200 Received: from [5.15.153.128] ([5.15.153.128]) by lstyd.imos.net (8.14.0/8.13.7) with ESMTP id l94HNfUe014409 for ; Thu, 4 Oct 2007 19:23:41 +0200 Message-ID: <4704FA19.2080101@theendofthetunnel.de> Date: Thu, 04 Oct 2007 16:35:05 +0200 From: Hannes Dorbath User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 References: <20071004133302.GA5058@apartia.fr> In-Reply-To: <20071004133302.GA5058@apartia.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4471/Thu Oct 4 06:22:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13259 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: light@theendofthetunnel.de Precedence: bulk X-list: xfs On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: > What do you think about it ? Another thing, is there a special reason why you use DRBD 0.7.x branch? AFAIK it will still deadlock with kernel 2.6.22. You are not running .22, but if you upgrade you might have serious problems. You should really go with DRBD 8.0.6 if you can. -- Regards, Hannes Dorbath From owner-xfs@oss.sgi.com Thu Oct 4 09:52:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 09:52:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94GqqDr031750 for ; Thu, 4 Oct 2007 09:52:55 -0700 Received: by wa-out-1112.google.com with SMTP id k22so297554waf for ; Thu, 04 Oct 2007 09:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=CNCJag1HXM0wZ0dZD0Q959Zh0SK1fUm+qyQiQyn8OWk=; b=C6Z58XdX7bzaK7kioCqfpCicwY7TpXFLOcGmLg7BpeNUH+GQE2x2EkqEFjsQ8+CqkNGJYh5gngASjcQhbfiafdftuFoaPiSao1CnZWnrn6vUYHX9xrdgwYTQn8WCY+cfucWk0NkgG7r/6E3kv/q0E9FktcS1V04qbtGFTBwWKl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qFNVM7fDs5rBe0uE2kBcibtFfx3GNo7XKtz1THrKRHvSliCKIIPowPI51Qge7O0SOkZ07Gc95HfUmb2xrlcdt9nt9QcW4LVisKVVfoOoOzcgC7WKCQU9rgwRdkxpEXDH4OVFXLDf3Ic0Q3H7elR92/42v/SJdHeRQjz1DVfmAwQ= Received: by 10.114.110.1 with SMTP id i1mr7401015wac.1191516772291; Thu, 04 Oct 2007 09:52:52 -0700 (PDT) Received: by 10.114.123.20 with HTTP; Thu, 4 Oct 2007 09:52:52 -0700 (PDT) Message-ID: Date: Thu, 4 Oct 2007 09:52:52 -0700 From: "Bhagi rathi" To: cyjoyp Subject: Re: Reading directory entries from BMAP Cc: xfs@oss.sgi.com In-Reply-To: <13040897.post@talk.nabble.com> MIME-Version: 1.0 References: <13040897.post@talk.nabble.com> X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2263 X-archive-position: 13260 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs br_startoff is starting offset of a file. The problem you are facing is not clear to me. XFS uses 16 bytes to represet start offset, length of the extent and then start bloock offset. If you are interested with directories of XFS, the blocks that start from 0 offset and with in the file address space of 32GB is the name space. After name space, you have lookup space and then free space manager for directories. Typically, reading of directory entries is reading of the total blocks reported by stat command. A directory can be in single block format, embedded in the inode itself, etc. You are talking about bmbt_irec and then going towards directory entries. This was not clear to me. -Saradhi. On 10/4/07, cyjoyp wrote: > > > Hi there, > I am a beginner in learning XFS file system.. I have a doubt, > dont > know whether is silly..If you could help me with this...Thank you.. > > An extent is 128 bit in size and uses the following struct, > > typedef struct xfs_bmbt_irec { > xfs_fileoff_t br_startoff; > xfs_fsblock_t br_startblock; > xfs_filblks_t br_blockcount; > xfs_exntst_t br_state; > } > > I have got in to the BMAP position after traversing the BTREE.. > The BMAP has a leaf and no other siblings.. > I have the extents for directory entries stored in the BMAP.. > This is where is struck badly.. > > Now I have a 16 byte value from which I can calculate the block count > ,AG number ,etc... > 00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02 > In this case I lan up some where else instead going to the block of > directory entries.. > This br_startoff (logical offset) is causing a difference...I am going > wrong somwhere in this case.. > > > Could you please tell me br_startoff does really mean??? > > > > > > > > > > > > -- > View this message in context: > http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13040897 > Sent from the Xfs - General mailing list archive at Nabble.com. > > > [[HTML alternate version deleted]] > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Oct 4 10:00:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 10:00:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94H025q000769 for ; Thu, 4 Oct 2007 10:00:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 32E9130ED315; Thu, 4 Oct 2007 18:42:48 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWDUAgU7eF7L; Thu, 4 Oct 2007 18:42:48 +0200 (CEST) Received: from [192.168.0.31] (donald.lncsa.com [192.168.0.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id 121313065123; Thu, 4 Oct 2007 18:42:47 +0200 (CEST) Message-ID: <47051807.5020607@lncsa.com> Date: Thu, 04 Oct 2007 18:42:47 +0200 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: Hannes Dorbath CC: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 References: <20071004133302.GA5058@apartia.fr> <4704F86F.9030508@theendofthetunnel.de> In-Reply-To: <4704F86F.9030508@theendofthetunnel.de> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: Clean X-archive-position: 13262 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs Hannes Dorbath wrote: > On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: >> What do you think about it ? > > Is that by any chance a kernel with 4k stack size? > > We're using a 8kb stack size (default value). Laurent From owner-xfs@oss.sgi.com Thu Oct 4 10:00:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 10:00:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94H02LB000768 for ; Thu, 4 Oct 2007 10:00:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id E2BC8307E032; Thu, 4 Oct 2007 18:33:44 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMD7pjUfXsep; Thu, 4 Oct 2007 18:33:44 +0200 (CEST) Received: from [192.168.0.31] (donald.lncsa.com [192.168.0.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id CAE833065123; Thu, 4 Oct 2007 18:33:44 +0200 (CEST) Message-ID: <470515E8.4020807@lncsa.com> Date: Thu, 04 Oct 2007 18:33:44 +0200 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Hannes Dorbath Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 References: <20071004133302.GA5058@apartia.fr> <4704FA19.2080101@theendofthetunnel.de> In-Reply-To: <4704FA19.2080101@theendofthetunnel.de> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: Clean X-archive-position: 13261 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs Hannes Dorbath wrote: > On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: >> What do you think about it ? > > Another thing, is there a special reason why you use DRBD 0.7.x branch? > AFAIK it will still deadlock with kernel 2.6.22. You are not running > .22, but if you upgrade you might have serious problems. You should > really go with DRBD 8.0.6 if you can. > > Hi, We use 0.7.X since we had a major problem with 8.0.x. The initial sync did never complete. I tried to solve this problem with Lars Ellenberg to no avail, and decided to go back to 0.7 which is a well tested version. From owner-xfs@oss.sgi.com Thu Oct 4 13:06:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 13:06:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94K6U8k031571 for ; Thu, 4 Oct 2007 13:06:32 -0700 Received: by ug-out-1314.google.com with SMTP id m3so470515ugc for ; Thu, 04 Oct 2007 13:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=2WSijEpSHHFkNqr2zrK6PzQhAL4jIaLvOavy5K2gzUk=; b=mIfpR/Ti3LwSLM8NGybKevV+FKyKVX7jT7ujgkc5kVCD54g9ilgfy0NVOLRGLmonj3X1s8SpT9F4Yragf8PRYPphlgdlD1uOWKa9e7AVa11+keXgNSx9u+oTmdWzMrJT9wuXrayN0tEfP/YK5ejCDE35EbKq7PRIAKE/cCmTI0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=APm8D1gnhwJoS2gs/DpuQajFBnntmaG/c5cIQTfgd/zewU9UVbSlsyFbIY85TETfCDJSHEUZQMNj2f+f8Je+bSNPhcEjLSAb03A9ULKCrWgaNJmU46OSVXNmLeo/MI/Dr8OHlSx/uJBOtN/DRUiU0B3a39rHm6rNQmAzWtiDb2A= Received: by 10.66.242.5 with SMTP id p5mr2394160ugh.1191526720182; Thu, 04 Oct 2007 12:38:40 -0700 (PDT) Received: from prosecco.cantina ( [84.220.161.31]) by mx.google.com with ESMTPS id 29sm2631128uga.2007.10.04.12.38.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2007 12:38:39 -0700 (PDT) From: Alessandro Bono To: David Chinner Subject: Re: 2.6.23-rc9-git1 hang with XFS Date: Thu, 4 Oct 2007 21:38:36 +0200 User-Agent: KMail/1.9.7 Cc: linux-xfs@oss.sgi.com References: <20071004003935.GC23367404@sgi.com> In-Reply-To: <20071004003935.GC23367404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710042138.36920.alessandro.bono@gmail.com> X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13263 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alessandro.bono@gmail.com Precedence: bulk X-list: xfs On Thursday 04 October 2007, David Chinner wrote: > On Wed, Oct 03, 2007 at 11:03:29PM +0200, Alessandro Bono wrote: > > Hi all > > > > I'm testing 2.6.23-rc9-git1 on my old home server > > Trying to reorganizer my xfs filesystem with xfs_fsr cause a sort of > > system hang > > xfs_fsr is waiting for a direct I/O to complete. > Other processes are waiting for the superblock I/O to compete > (which is why writes are hanging), an dothers are waiting > for iclog space to be freed up. I think something is holding > > off I/O completion, and this: > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > possible SYN flooding on port 4664. Sending cookies. > > indicates someone trying a DOS on your box. Perhaps it's > succeeding by denying interrupt service to you disks? > > If you pull the network cable, does the system start to respond > properly again? There is no difference with and without network cable plugged in Other partitions on the same lvm2 volume with ext3 works without any problem so disks and sw raid seems to work how can I debug this problem? If needed I can recompile kernel to collect other info > > Cheers, > > Dave. -- Cordiali saluti Alessandro Bono From owner-xfs@oss.sgi.com Thu Oct 4 13:44:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 13:44:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94KiNbA004107 for ; Thu, 4 Oct 2007 13:44:24 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id 7458E92C3BC; Fri, 5 Oct 2007 06:42:10 +1000 (EST) Received: from 192.168.3.1 (proxying for 211.28.181.43) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Fri, 5 Oct 2007 06:42:31 +1000 (EST) Message-ID: <34787.192.168.3.1.1191530551.squirrel@mail.aconex.com> In-Reply-To: <200710041014.22936.ak@suse.de> References: <200710040027.16926.ak@suse.de> <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> <200710041014.22936.ak@suse.de> Date: Fri, 5 Oct 2007 06:42:31 +1000 (EST) Subject: Re: [PATCH] XFS bitops to Linux again From: nscott@aconex.com To: "Andi Kleen" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13264 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Hi Andi, >> Several of these call sites are also compiled in userspace in libxfs. >> It >> would >> be a good idea from that POV also to keep some level of abstraction so >> that >> these calls can be mapped to userspace routines as well. > > Again the same argument applies -- there is no difference if you > map xfs_(high|low)bit or fls64/fls/find_find_bit() to something else. Yep, indeed. I guess what I'm saying is "just make sure userspace is fixed up too". So, when you say "if you map...", instead say "when I did that mapping it wasn't a problem... patch is included" so that other people (i.e. Barry here) get less work to do to on the merge (and don't have to cleanup your cleanup). > >> What testing was done? Changes to some of these routines has introuced >> subtle log recovery bugs in the past - has recovery been tested at all? >> The QA >> suite has some log recovery tests, it'd be a good idea to verify with >> those.. > > I had a simple separate unit test to verify the 32bit space gave the same > result. The only difference was the 0 case, but I checked all inputs > manually. Usually they had != 0 tests already or zero was impossible; > in the few cases were not I added ASSERTs -- so if i got it wrong it > should > bomb out quickly. Great. You're light years ahead of the rest of the cleanup brigade. :) > I did also some simple tests using the QA suite -- i believe a few logs > were recovered -- but not the full tests. From a quick look, tests 085, 086 and 087 are the ones I was thinking of yesterday. >> To be honest, this sounds like just code churn and risk >> introduction. > > Ok I got the message. I retract the patch. Sorry for bothering you > with lowly cleanups. Hey, I like cleanup as much as the next guy (as long as the next guy isn't Eric, he just lives to clean ;) - also always ignores userspace despite knowing better) - I just don't like seeing more work introduced for the people really fixing stuff. I'm sure the patch could be merged (given its been tested) if either userspace is updated too, or the same xfs_* naming convention was kept so that userspace needs no changes. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Oct 4 14:10:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 14:10:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94LAoJa008193 for ; Thu, 4 Oct 2007 14:10:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id l94LAm17002814; Thu, 4 Oct 2007 17:10:48 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l94LAm0X032414; Thu, 4 Oct 2007 17:10:48 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l94LAkwC013020; Thu, 4 Oct 2007 17:10:47 -0400 Message-ID: <470556D6.3090703@sandeen.net> Date: Thu, 04 Oct 2007 16:10:46 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: nscott@aconex.com CC: Andi Kleen , xfs@oss.sgi.com Subject: Re: [PATCH] XFS bitops to Linux again References: <200710040027.16926.ak@suse.de> <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> <200710041014.22936.ak@suse.de> <34787.192.168.3.1.1191530551.squirrel@mail.aconex.com> In-Reply-To: <34787.192.168.3.1.1191530551.squirrel@mail.aconex.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13265 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 nscott@aconex.com wrote: > Great. You're light years ahead of the rest of the cleanup brigade. :) Hey, I resemble that remark! :) (FWIW, I too first ran through xfsqa with both calculations in place, and caused it to complain loudly if there was a mismatch. Not 100% coverage, but I'm not trying to do this half-assed either...) >> I did also some simple tests using the QA suite -- i believe a few logs >> were recovered -- but not the full tests. > > From a quick look, tests 085, 086 and 087 are the ones I was thinking of > yesterday. > >>> To be honest, this sounds like just code churn and risk >>> introduction. >> Ok I got the message. I retract the patch. Sorry for bothering you >> with lowly cleanups. > > Hey, I like cleanup as much as the next guy (as long as the next guy isn't > Eric, > he just lives to clean ;) If I do any real work I might lose my job ;-) > - also always ignores userspace despite knowing > better) Nah, I just forget. -Eric From owner-xfs@oss.sgi.com Thu Oct 4 15:38:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 15:38:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l94McWQW022309 for ; Thu, 4 Oct 2007 15:38:36 -0700 Received: by wr-out-0506.google.com with SMTP id c48so277022wra for ; Thu, 04 Oct 2007 15:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=e8HR7Wl69aNAyM9aNfDZFR5V7U1iwueDW+0NYbzmNKE=; b=kDSElOiC6OtomARiwCcOL6wzkFZgxg1BKnXftJwLXUGn7no41yrjJVTFszgcJ6axqxQp8m3SsDTaKYSEv8lvQbUzrkpMBW4cbokqjLf6COf+rsdtzaJwUyn/ffGRwG0itQeKExUprg9VJ6tS3zKsIh3w0nbCXdBiYVKvKjKScCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=km+X6OfaNFjNrm7rIJ4pk0B+8QvKvFzbF086z+ZvQf0M/X+eqGY+iHJrTeP3g3o0qP9rH36AwwnnXHAgJe8hZbcpz0IWXc3A6L/3EArlYQsDYUXLhcSDjfaJz4pKEVPe7h6SEEYFpYRymeKvFFY40gHwwHe19FX7O9pashBulJE= Received: by 10.142.154.20 with SMTP id b20mr1195033wfe.1191535849232; Thu, 04 Oct 2007 15:10:49 -0700 (PDT) Received: by 10.143.30.18 with HTTP; Thu, 4 Oct 2007 15:10:49 -0700 (PDT) Message-ID: Date: Fri, 5 Oct 2007 00:10:49 +0200 From: "Peter Gervai" To: xfs@oss.sgi.com Subject: xfs_repair phase6 repeatedly dies : name create failed in lost+found (117), filesystem may be out of space MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13266 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: grinapo@gmail.com Precedence: bulk X-list: xfs Hello, xfs_repair in Debian sid (v2.9.0) repeatedly dies on a poor filesystem with that message: fatal error -- name create failed in lost+found (117), filesystem may be out of space The filesystem is not out of space: Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg0-backup 419379200 144029144 275350056 35% /var/lib/backuppc I tried to find error 117 but it seems to be well hidden. :-) I try newer xfs_repair but I doubt it'll help. Any idea? Thanks, Peter From owner-xfs@oss.sgi.com Thu Oct 4 16:09:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 16:09:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l94N93KZ026749 for ; Thu, 4 Oct 2007 16:09:06 -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 JAA18159; Fri, 5 Oct 2007 09:08:55 +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 l94N8rdD51421502; Fri, 5 Oct 2007 09:08:54 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l94N8o4A51358406; Fri, 5 Oct 2007 09:08:50 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 5 Oct 2007 09:08:50 +1000 From: David Chinner To: Andi Kleen Cc: nscott@aconex.com, xfs@oss.sgi.com Subject: Re: [PATCH] XFS bitops to Linux again Message-ID: <20071004230850.GI23367404@sgi.com> References: <200710040027.16926.ak@suse.de> <60338.192.168.3.1.1191452291.squirrel@mail.aconex.com> <200710041014.22936.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710041014.22936.ak@suse.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13267 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 On Thu, Oct 04, 2007 at 10:14:22AM +0200, Andi Kleen wrote: > Ok I got the message. I retract the patch. Sorry for bothering you > with lowly cleanups. Andi, please don't walk away with that attitude. I like the fact your patch makes use of generic code, I just didn't like the way it changed the core XFS code. I've said exactly the same thing in the past about the removal of the min/max wrapper macros in XFS. we still have the wrapper macros because they help make the code readable, consistent and more maintainable from an _XFS perspective_. What I'm saying here is consistent with that view - leave the wrappers, replace the implementation. (untested patch that does that below.) Sorry if I didn't make that clear, but your patches and ideas are appreciated and sometimes we all fall down into being nasty coding style cops. :( Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_bit.c | 103 --------------------------------------------------- fs/xfs/xfs_bit.h | 27 ++++++++++--- fs/xfs/xfs_rtalloc.c | 20 +++------ 3 files changed, 30 insertions(+), 120 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.c 2007-06-20 15:54:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.c 2007-10-05 08:48:48.107390247 +1000 @@ -25,109 +25,6 @@ * XFS bit manipulation routines, used in non-realtime code. */ -#ifndef HAVE_ARCH_HIGHBIT -/* - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. - */ -static const char xfs_highbit[256] = { - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ -}; -#endif - -/* - * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. - */ -inline int -xfs_highbit32( - __uint32_t v) -{ -#ifdef HAVE_ARCH_HIGHBIT - return highbit32(v); -#else - int i; - - if (v & 0xffff0000) - if (v & 0xff000000) - i = 24; - else - i = 16; - else if (v & 0x0000ffff) - if (v & 0x0000ff00) - i = 8; - else - i = 0; - else - return -1; - return i + xfs_highbit[(v >> i) & 0xff]; -#endif -} - -/* - * xfs_lowbit64: get low bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_lowbit64( - __uint64_t v) -{ - __uint32_t w = (__uint32_t)v; - int n = 0; - - if (w) { /* lower bits */ - n = ffs(w); - } else { /* upper bits */ - w = (__uint32_t)(v >> 32); - if (w && (n = ffs(w))) - n += 32; - } - return n - 1; -} - -/* - * xfs_highbit64: get high bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_highbit64( - __uint64_t v) -{ - __uint32_t h = (__uint32_t)(v >> 32); - - if (h) - return xfs_highbit32(h) + 32; - return xfs_highbit32((__uint32_t)v); -} - - /* * Return whether bitmap is empty. * Size is number of words in the bitmap, which is padded to word boundary Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-06-20 15:54:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-10-05 08:56:53.180459657 +1000 @@ -47,13 +47,30 @@ static inline __uint64_t xfs_mask64lo(in } /* Get high bit set out of 32-bit argument, -1 if none set */ -extern int xfs_highbit32(__uint32_t v); - -/* Get low bit set out of 64-bit argument, -1 if none set */ -extern int xfs_lowbit64(__uint64_t v); +static inline int xfs_highbit32(__uint32_t v) +{ + return fls(v) - 1; +} /* Get high bit set out of 64-bit argument, -1 if none set */ -extern int xfs_highbit64(__uint64_t); +static inline int xfs_highbit64(__uint64_t v) +{ + return fls64(v) - 1; +} + +/* Get low bit set out of 32-bit argument, -1 if none set */ +static inline int xfs_lowbit32(__uint32_t v) +{ + unsigned long t = v; + return (v) ? find_first_bit(&t, 32) : -1; +} + +/* Get low bit set out of 64-bit argument, -1 if none set */ +static inline int xfs_lowbit64(__uint64_t v) +{ + unsigned long t = v; + return (v) ? find_first_bit(&t, 64) : -1; +} /* Return whether bitmap is empty (1 == empty) */ extern int xfs_bitmap_empty(uint *map, uint size); Index: 2.6.x-xfs-new/fs/xfs/xfs_rtalloc.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_rtalloc.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_rtalloc.c 2007-10-05 09:02:27.376952907 +1000 @@ -73,18 +73,6 @@ STATIC int xfs_rtmodify_summary(xfs_moun */ /* - * xfs_lowbit32: get low bit set out of 32-bit argument, -1 if none set. - */ -STATIC int -xfs_lowbit32( - __uint32_t v) -{ - if (v) - return ffs(v) - 1; - return -1; -} - -/* * Allocate space to the bitmap or summary file, and zero it, for growfs. */ STATIC int /* error */ @@ -444,6 +433,7 @@ xfs_rtallocate_extent_near( } bbno = XFS_BITTOBLOCK(mp, bno); i = 0; + ASSERT(minlen != 0); log2len = xfs_highbit32(minlen); /* * Loop over all bitmap blocks (bbno + i is current block). @@ -612,6 +602,8 @@ xfs_rtallocate_extent_size( xfs_suminfo_t sum; /* summary information for extents */ ASSERT(minlen % prod == 0 && maxlen % prod == 0); + ASSERT(maxlen != 0); + /* * Loop over all the levels starting with maxlen. * At each level, look at all the bitmap blocks, to see if there @@ -669,6 +661,9 @@ xfs_rtallocate_extent_size( *rtblock = NULLRTBLOCK; return 0; } + ASSERT(minlen != 0); + ASSERT(maxlen != 0); + /* * Loop over sizes, from maxlen down to minlen. * This time, when we do the allocations, allow smaller ones @@ -1954,6 +1949,7 @@ xfs_growfs_rt( nsbp->sb_blocksize * nsbp->sb_rextsize); nsbp->sb_rextents = nsbp->sb_rblocks; do_div(nsbp->sb_rextents, nsbp->sb_rextsize); + ASSERT(nsbp->sb_rextents != 0); nsbp->sb_rextslog = xfs_highbit32(nsbp->sb_rextents); nrsumlevels = nmp->m_rsumlevels = nsbp->sb_rextslog + 1; nrsumsize = From owner-xfs@oss.sgi.com Thu Oct 4 16:10:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 16:10:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l94NAd8O027210 for ; Thu, 4 Oct 2007 16:10:44 -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 JAA18191 for ; Fri, 5 Oct 2007 09:10: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 l94NAcdD51135921 for ; Fri, 5 Oct 2007 09:10:39 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l94NAbLd51176060 for xfs@oss.sgi.com; Fri, 5 Oct 2007 09:10:37 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 5 Oct 2007 09:10:37 +1000 From: David Chinner To: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 Message-ID: <20071004231037.GJ23367404@sgi.com> References: <20071004133302.GA5058@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071004133302.GA5058@apartia.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13268 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 On Thu, Oct 04, 2007 at 03:33:02PM +0200, vindex+lists-xfs@apartia.org wrote: > > Hi, > > I did compile a fresh 2.6.21.7 kernel from kernel.org (no distro patch, > ....), and latest svn (3062) 0.7.X drbd. > > After just 2 days of uptime, I did experience another crash. > > I wonder if it is an XFS related bug, a DRBD one, or related to XFS on > top of DRBD. > > This bug seems to occur with intensive IO operations. > > What do you think about it ? > > Thanks > > > Oct 3 18:55:23 kernel: Oops: 0002 [#1] > Oct 3 18:55:23 kernel: SMP > Oct 3 18:55:23 kernel: CPU: 7 > Oct 3 18:55:23 kernel: EIP: 0060:[] Not tainted VLI > Oct 3 18:55:23 kernel: EFLAGS: 00010046 (2.6.21-dl380-g5-20071001 #1) > Oct 3 18:55:23 kernel: EIP is at cache_alloc_refill+0x11c/0x4f0 Use after free somewhere, i'd say. Turn on slab/slub poisoning and other memory debugging options and see where it panics next time. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 4 16:26:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 16:27:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l94NQrVM000910 for ; Thu, 4 Oct 2007 16:26:55 -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 JAA18601; Fri, 5 Oct 2007 09:26:47 +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 l94NQkdD51386141; Fri, 5 Oct 2007 09:26:47 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l94NQiNL51377059; Fri, 5 Oct 2007 09:26:44 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 5 Oct 2007 09:26:44 +1000 From: David Chinner To: cyjoyp Cc: xfs@oss.sgi.com Subject: Re: Reading directory entries from BMAP Message-ID: <20071004232644.GK23367404@sgi.com> References: <13040897.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13040897.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13269 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 On Thu, Oct 04, 2007 at 07:27:19AM -0700, cyjoyp wrote: > > Hi there, > I am a beginner in learning XFS file system.. I have a doubt, dont > know whether is silly..If you could help me with this...Thank you.. > > An extent is 128 bit in size and uses the following struct, > > typedef struct xfs_bmbt_irec { > xfs_fileoff_t br_startoff; > xfs_fsblock_t br_startblock; > xfs_filblks_t br_blockcount; > xfs_exntst_t br_state; > } That's the unpacked, in-memory format. The on disk format for extents is converted by xfs_bmbt_set_allf/xfs_bmbt_disk_set_allf(). > > I have got in to the BMAP position after traversing the BTREE.. > The BMAP has a leaf and no other siblings.. > I have the extents for directory entries stored in the BMAP.. > This is where is struck badly.. > > Now I have a 16 byte value from which I can calculate the block count > ,AG number ,etc... > 00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02 If that is the start of the block, theres a block header first, right? i.e.: /* * * Bmap root header, on-disk form only. * */ typedef struct xfs_bmdr_block { __be16 bb_level; /* 0 is a leaf */ __be16 bb_numrecs; /* current # of data records */ } xfs_bmdr_block_t; So the above woul dbe telling me that this is a level zero block (a leaf), with one record. Then there's the first record in packed format.... > In this case I lan up some where else instead going to the block of > directory entries.. > This br_startoff (logical offset) is causing a difference...I am going > wrong somwhere in this case.. unpack the extent record first before decoding it. Perhaps you should be using xfs_db to look at your disk structures rather than trying to manually decode it from hex dumps. i.e.: # xfs_db -r -c "inode 128" -c "p core.size core.nblocks core.format u.bmx" -c "dblock 0" -c "type dir2" -c p /dev/sdb8 core.size = 4096 core.nblocks = 1 core.format = 2 (extents) u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,132,1,0] bhdr.magic = 0x58443242 bhdr.bestfree[0].offset = 0x618 bhdr.bestfree[0].length = 0x770 bhdr.bestfree[1].offset = 0x370 bhdr.bestfree[1].length = 0x128 bhdr.bestfree[2].offset = 0x88 bhdr.bestfree[2].length = 0x58 bu[0].inumber = 128 bu[0].namelen = 1 bu[0].name = "." bu[0].tag = 0x10 bu[1].inumber = 128 bu[1].namelen = 2 bu[1].name = ".." bu[1].tag = 0x20 bu[2].inumber = 131 bu[2].namelen = 3 bu[2].name = "tmp" bu[2].tag = 0x30 bu[3].inumber = 132 bu[3].namelen = 11 bu[3].name = "syscalltest" bu[3].tag = 0x40 ...... Note that this will print the entire block, including unused space with it's stale contents. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 4 17:14:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 17:14:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=BAYES_99,RCVD_IN_SORBS_DUL, RDNS_NONE,STOX_REPLY_TYPE autolearn=no version=3.3.0-r574664 Received: from sfzo ([211.44.69.8]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l950E519008470 for ; Thu, 4 Oct 2007 17:14:07 -0700 Received: from hrflt ([168.189.150.214]) by sfzo with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Oct 2007 09:14:06 +0900 Message-ID: <001201c806e4$a47a7ca0$d696bda8@hrflt> From: To: Subject: Huge return on FRLE today Date: Fri, 5 Oct 2007 09:14:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13270 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: patrickfrederick@yrhyg.helmetdiet.com Precedence: bulk X-list: xfs Giant leaps for Fearless today as trading forces price up nearly 32% Fearless International (FRLE) $0.25 UP 31.26 % Huge prices increases backed by week long trading is the order of the day for Fearless International. Friday will be pushed now as market makers see the trend going into place. Don't loose out on the opportunity tomorrow will bring to savvy investors, act first thing in the AM. From owner-xfs@oss.sgi.com Thu Oct 4 17:37:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 17:37:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l950bCr9012289 for ; Thu, 4 Oct 2007 17:37:14 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA20051; Fri, 5 Oct 2007 10:37:08 +1000 Date: Fri, 05 Oct 2007 10:41:08 +1000 To: "Peter Gervai" Subject: Re: xfs_repair phase6 repeatedly dies : name create failed in lost+found (117), filesystem may be out of space From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13271 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Fri, 05 Oct 2007 08:10:49 +1000, Peter Gervai wrote: > Hello, > > xfs_repair in Debian sid (v2.9.0) repeatedly dies on a poor filesystem > with that message: > > fatal error -- name create failed in lost+found (117), filesystem may > be out of space > > The filesystem is not out of space: > > Filesystem 1K-blocks Used Available > Use% Mounted on > /dev/mapper/vg0-backup 419379200 144029144 275350056 35% > /var/lib/backuppc > > I tried to find error 117 but it seems to be well hidden. :-) I try > newer xfs_repair but I doubt it'll help. Any idea? Can you do a "df -i" as well? The other option is to run xfs_metadump from xfsprogs 2.9.4 so I can perform some analysis as to why it's failing. Regards, Barry. From owner-xfs@oss.sgi.com Thu Oct 4 18:53:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 18:53:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_14, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l951rN8K022433 for ; Thu, 4 Oct 2007 18:53:25 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 LAA21900 for ; Fri, 5 Oct 2007 11:53:23 +1000 Date: Fri, 05 Oct 2007 11:57:54 +1000 To: "xfs@oss.sgi.com" Subject: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13272 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On it's own, linux only provides case conversion for old-style character sets - 8 bit sequences only. A lot of distos are now defaulting to UTF-8 and Linux NLS stuff does not support case conversion for any unicode sets. Various filesystems do support case-insensitive lookup in Linux: - CIFS (Samba) - NTFS - HFS+ (MacOSX) - ISOFS (DVD/Joliet) - JFS (IBM's?) - VFAT - HPFS - AFFS ? It seems all but HFS+ do case-conversion either on the currently set charset (CIFS) or only do English ASCII conversion. If the charset is UTF-8, this fails. HFS+ does have a full and fixed unicode charset table as defined by: http://developer.apple.com/technotes/tn/tn1150.html#StringComparisonAlgorithm This is implemented by fs/hfsplus/unicode.c and fs/hfsplus/tables.c. Linux's dentry cache allows these filesystems to hook into the dentry lookup operations by allowing a custom hash and compare functions defined by the dentry_operations struct. XFS currently does not define its own dentry_operations. NTFS in Linux also implements it's own dcache and NTFS also stores its unicode case table on disk. This allows the filesystem to migrate to newer forms of Unicode at the time of formatting the filesystem. Eg. Windows Vista now supports Unicode 5.0 while older version would support an earlier version of Unicode. Linux's version of NTFS case table is implemented in fs/ntfs/upcase.c defined as default_upcase. IRIX case-insensitive XFS only supported ASCII, no code-pages or anything. With the widespread distribution of Linux in various countries/languages, this should be a deprecated mode and supported for backwards compatibility. It will be proposed that in the future, XFS may default to UTF-8 on disk and to go for the old format, explicitily use a mkfs.xfs option. Two superbits will be used: one for case-insensitive (which generates lowercase hashes on disk) and that already exists on IRIX filesystems and a new one for UTF-8 filenames. Any combination of the two bits can be used and the dentry_operations will be adjusted accordingly. Another interesting resource is "ICU" - "International Components for Unicode" a BSD licensed API maintained by IBM: http://icu-project.org/ It has code in there supporting the latest Unicode sets including true character folding specifically for case-insensitive searches: http://icu-project.org/userguide/caseMappings.html#case_folding So, in regards to the UTF-8 case-conversion/folding table, we have several options to choose from: - Use the HFS+ method as-is. - Use an NTFS scheme with an on-disk table. - Pick a current table and stick with it (similar to HFS+). - How much of Unicode to we support? Just the the "Basic Multilingual Plane" (U+0000 - U+FFFF) or the entire set? (anything above U+FFFF won't have case-conversion requirements). Seems that all the other filesystems just support the "BMP". - UTF-8, UTF-16 or UCS-2. With the last point, UTF-8 has several advantages IMO: - xfs_repair can easily detect UTF-8 sequences in filenames and also validate UTF-8 sequences. - char based structures don't change - "nulls" in filenames. - no endian conversions required. Internally, the names will probably be converted to "u16"s for efficient processing. Conversion between UTF-8 and UTF-16/UCS-2 is very straight forward. From owner-xfs@oss.sgi.com Thu Oct 4 20:28:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 20:28:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l953SRCe005452 for ; Thu, 4 Oct 2007 20:28:31 -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 NAA23569; Fri, 5 Oct 2007 13:28:23 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id C70A758C38F1; Fri, 5 Oct 2007 13:28:23 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 971064 - fix infinite loop in bulkstat Message-Id: <20071005032823.C70A758C38F1@chook.melbourne.sgi.com> Date: Fri, 5 Oct 2007 13:28:23 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13273 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This fix prevents bulkstat from spinning in an infinite loop. Here 'agino' increments through the inodes in an allocation group. At the end of the innermost 'for' loop it will hold the value of the next inode to look at (ie the first inode in the next cluster/chunk). Assigning 'lastino' to 'agino' resets it to the last inode in the last inode cluster we just looked at. This causes us to look up the very same cluster and examine all the inodes all over again, and again, and again... We also want to set 'lastino' for the cases when we're not interested in the inode so that the next call to bulkstat wont re-examine the same uninteresting inodes. Date: Fri Oct 5 13:25:32 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29840a fs/xfs/xfs_itable.c - 1.156 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.156&r2=text&tr2=1.155&f=h - fix infinite loop in bulkstat From owner-xfs@oss.sgi.com Thu Oct 4 22:16:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 04 Oct 2007 22:16:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l955G7RF019839 for ; Thu, 4 Oct 2007 22:16:10 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IdfXj-0000vE-SO for xfs@oss.sgi.com; Thu, 04 Oct 2007 22:16:07 -0700 Message-ID: <13053632.post@talk.nabble.com> Date: Thu, 4 Oct 2007 22:16:07 -0700 (PDT) From: cyjoyp To: xfs@oss.sgi.com Subject: Re: Reading directory entries from BMAP In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: cyjoyp@gmail.com References: <13040897.post@talk.nabble.com> X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13274 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cyjoyp@gmail.com Precedence: bulk X-list: xfs Thanks for your reply.... I ll make it clear for you.... Manipulating this 16 bytes 00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02 *21 bits out of A0 00 02 would form the block count : 2 *19 bits out of 00 00 A0 would form the absolute block numbe :15h *The remaining bits out 52 (52-19 =33 bits) would form the AG number : 0 *The rest forms the logical offset. This means that I have to read 2 contiguos blocks from the location 15h*8=168. I really dont understand how the logial offset works. More I have the root folder with 1000 empty directoris created in the root. So when I go to the position 168,I should be able to see only two contigous blocks of directory entries, but I am not getting .. Instead I get values sector number: 168 00 80 00 03 00 80 00 02 d2 ff 00 00 01 2e 00 00 b8 16 e9 8d 00 00 06 ed b8 16 e9 8e 00 00 06 e8 b8 16 e9 8f 00 00 06 e3 be 95 a0 c2 00 00 0e 6b be 95 a0 c3 00 00 0e 66 be 95 a0 c8 00 00 0e 4d be 95 a0 c9 00 00 0e 48 be 95 a0 ca 00 00 0e 43 There is no magic number at the start ... Are you able to understand?? thnks Bhagi rathi wrote: > >>br_startoff is starting offset of a file. The problem you are facing is not >>clear to me. >>XFS uses 16 bytes to represet start offset, length of the extent and then >>start bloock > offset. > >>If you are interested with directories of XFS, the blocks that start from 0 > offset and with >>in the file address space of 32GB is the name space. After name space, you > have >>lookup space and then free space manager for directories. Typically, reading > of > >directory entries is reading of the total blocks reported by stat > command. A >>directory >> can be in single block format, embedded in the inode itself, etc. > >>You are talking about bmbt_irec and then going towards directory entries. >>This was >> not clear to me. > > -Saradhi. > > On 10/4/07, cyjoyp wrote: >> >> >> Hi there, >> I am a beginner in learning XFS file system.. I have a doubt, >> dont >> know whether is silly..If you could help me with this...Thank you.. >> >> An extent is 128 bit in size and uses the following struct, >> >> typedef struct xfs_bmbt_irec { >> xfs_fileoff_t br_startoff; >> xfs_fsblock_t br_startblock; >> xfs_filblks_t br_blockcount; >> xfs_exntst_t br_state; >> } >> >> I have got in to the BMAP position after traversing the BTREE.. >> The BMAP has a leaf and no other siblings.. >> I have the extents for directory entries stored in the BMAP.. >> This is where is struck badly.. >> >> Now I have a 16 byte value from which I can calculate the block count >> ,AG number ,etc... >> 00 00 00 01 00 00 02 00 00 00 00 00 02 A0 00 02 >> In this case I lan up some where else instead going to the block of >> directory entries.. >> This br_startoff (logical offset) is causing a difference...I am going >> wrong somwhere in this case.. >> >> >> Could you please tell me br_startoff does really mean??? >> >> >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13040897 >> Sent from the Xfs - General mailing list archive at Nabble.com. >> >> >> [[HTML alternate version deleted]] >> >> >> > > > [[HTML alternate version deleted]] > > > > -- View this message in context: http://www.nabble.com/Reading-directory-entries-from-BMAP-tf4569129.html#a13053632 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Oct 5 00:44:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 05 Oct 2007 00:44:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l957ijPC012167 for ; Fri, 5 Oct 2007 00:44:47 -0700 Received: by py-out-1112.google.com with SMTP id u77so885928pyb for ; Fri, 05 Oct 2007 00:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Q6MKj2aBGEMuSFMrZqG1Uo4fTeNHBs6CZzqfA/WavOQ=; b=YhA6ORB9BJG67F1OaQZ8XzX38KE0j8KQtEOvl0klgARVuEEASjfTwkhnziV62cKcq3+E2cpKfVv7RHiHzgX1iV/hBKxLgxZdNUfMYxZeHmHLNFG0GBt909dluYJid92BQenNWiDmF6CuhNVHUwEXe3KCVMKcCDp/FXkxlCk2q2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kp+cosJvUHE0Tvnun6RPeVI9tpEFtZMSl3xEzF5aYTS16AvfQRZRIsZEFCeM6JZ2wNCnTM2srvInZS3dSYJHfQYVHlY0OofrjOxwFTeTsIv3Lut5q1CMXt73+3mrN9ROBMzmsof8WcVlqLIsmQsBJTs3/MVgNZiZk2ZWzDKbBn4= Received: by 10.142.221.19 with SMTP id t19mr1497031wfg.1191566685357; Thu, 04 Oct 2007 23:44:45 -0700 (PDT) Received: by 10.143.30.18 with HTTP; Thu, 4 Oct 2007 23:44:45 -0700 (PDT) Message-ID: Date: Fri, 5 Oct 2007 08:44:45 +0200 From: "Peter Gervai" To: "Barry Naujok" Subject: Re: xfs_repair phase6 repeatedly dies : name create failed in lost+found (117), filesystem may be out of space Cc: "xfs@oss.sgi.com" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: ClamAV 0.91.2/4472/Thu Oct 4 07:45:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13275 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: grinapo@gmail.com Precedence: bulk X-list: xfs On 10/5/07, Barry Naujok wrote: > On Fri, 05 Oct 2007 08:10:49 +1000, Peter Gervai wrote: > > > Hello, > > > > xfs_repair in Debian sid (v2.9.0) repeatedly dies on a poor filesystem > > with that message: > > > > fatal error -- name create failed in lost+found (117), filesystem may > > be out of space > > > > The filesystem is not out of space: > > > > Filesystem 1K-blocks Used Available > > Use% Mounted on > > /dev/mapper/vg0-backup 419379200 144029144 275350056 35% > > /var/lib/backuppc > > > > I tried to find error 117 but it seems to be well hidden. :-) I try > > newer xfs_repair but I doubt it'll help. Any idea? > > Can you do a "df -i" as well? Yes: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vg0-backup 419430400 3475741 415954659 1% /var/lib/backuppc > The other option is to run xfs_metadump from xfsprogs 2.9.4 so I can > perform some analysis as to why it's failing. Errrmm... # xfs_metadump -wg /dev/vg0/backup vg0.backup.metadump Copied 158208 of 3719360 inodes (0 of 1 AGs) /usr/sbin/xfs_metadump: line 31: 1778 Segmentation fault (core dumped) xfs_db$DBOPTS -i -p xfs_metadump -c "metadump$OPTS $2" $1 Do you want the partial dump, or should I try something tricky? -- byte-byte, grin From owner-xfs@oss.sgi.com Fri Oct 5 09:12:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 05 Oct 2007 09:12:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_14, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l95GC85q005528 for ; Fri, 5 Oct 2007 09:12:09 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IdpM2-0001yp-Lv; Fri, 05 Oct 2007 16:44:42 +0100 Date: Fri, 5 Oct 2007 16:44:42 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Subject: Re: RFC: Case-insensitive support for XFS Message-ID: <20071005154442.GA6432@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4479/Fri Oct 5 07:14:20 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13276 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 [Adding -fsdevel because some of the things touched here might be of broader interest and Urban because his name is on nls_utf8.c] On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: > > On it's own, linux only provides case conversion for old-style > character sets - 8 bit sequences only. A lot of distos are > now defaulting to UTF-8 and Linux NLS stuff does not support > case conversion for any unicode sets. The lack of case tables in nls_utf8.c defintively seems odd to me. Urban, is there a reason for that? The only thing that comes to mind is that these tables might be quite large. > NTFS in Linux also implements it's own dcache and NTFS also ^^^^^^^ dentry operations? > stores its unicode case table on disk. This allows the filesystem > to migrate to newer forms of Unicode at the time of formatting > the filesystem. Eg. Windows Vista now supports Unicode 5.0 > while older version would support an earlier version of > Unicode. Linux's version of NTFS case table is implemented > in fs/ntfs/upcase.c defined as default_upcase. Because ntfs uses 16bit wide chars it prefers to use it's own tables. I'm not sure it's a that good idea. JFS also has wide-char names on disk but at least partially uses the generic nls support, so there must be some trade-offs. > It will be proposed that in the future, XFS may default to > UTF-8 on disk and to go for the old format, explicitily > use a mkfs.xfs option. Two superbits will be used: one for > case-insensitive (which generates lowercase hashes on disk) > and that already exists on IRIX filesystems and a new one > for UTF-8 filenames. Any combination of the two bits can be > used and the dentry_operations will be adjusted accordingly. I don't think arbitrary combinations make sense. Without case insensitive support a unix filesystem couldn't care less what charset the filenames are in, except for the terminating 0 and '/', '.', '..' it's an entirely opaqueue stream of bytes. So chosing a charset only makes sense with the case insensitive filename option. > So, in regards to the UTF-8 case-conversion/folding table, we > have several options to choose from: > - Use the HFS+ method as-is. > - Use an NTFS scheme with an on-disk table. > - Pick a current table and stick with it (similar to HFS+). > - How much of Unicode to we support? Just the the "Basic > Multilingual Plane" (U+0000 - U+FFFF) or the entire set? > (anything above U+FFFF won't have case-conversion > requirements). Seems that all the other filesystems > just support the "BMP". > - UTF-8, UTF-16 or UCS-2. > > With the last point, UTF-8 has several advantages IMO: > - xfs_repair can easily detect UTF-8 sequences in filenames > and also validate UTF-8 sequences. > - char based structures don't change > - "nulls" in filenames. > - no endian conversions required. I think the right approach is to use the fs/nls/ code and allow the user to select any table with a mount option as at least in russia and eastern europe some non-utf8 charsets still seem to be prefered. The default should of course be utf8 and support for utf8 case conversion should be added to fs/nls/ > Internally, the names will probably be converted to "u16"s for > efficient processing. Conversion between UTF-8 and UTF-16/UCS-2 > is very straight forward. Do we really need that? And if so please make sure this only happens for filesystems created with the case insensitivity option so normal filesystems don't have to pay for these bloated strings. From owner-xfs@oss.sgi.com Fri Oct 5 12:02:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 05 Oct 2007 12:02:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [206.18.177.54]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l95J2jAA027623 for ; Fri, 5 Oct 2007 12:02:47 -0700 Received: from [192.168.1.10] (c-67-183-84-122.hsd1.wa.comcast.net[67.183.84.122]) by comcast.net (alnrmhc14) with SMTP id <20071005185219b1400parl4e>; Fri, 5 Oct 2007 18:52:40 +0000 Subject: Re: RFC: Case-insensitive support for XFS From: Nicholas Miell To: Christoph Hellwig Cc: Barry Naujok , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se In-Reply-To: <20071005154442.GA6432@infradead.org> References: <20071005154442.GA6432@infradead.org> Content-Type: text/plain Date: Fri, 05 Oct 2007 11:52:18 -0700 Message-Id: <1191610338.2695.8.camel@entropy> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-2.fc7.0.njm.1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4480/Fri Oct 5 07:51:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13277 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nmiell@comcast.net Precedence: bulk X-list: xfs On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote: > [Adding -fsdevel because some of the things touched here might be of > broader interest and Urban because his name is on nls_utf8.c] > > On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: > > > > On it's own, linux only provides case conversion for old-style > > character sets - 8 bit sequences only. A lot of distos are > > now defaulting to UTF-8 and Linux NLS stuff does not support > > case conversion for any unicode sets. > > The lack of case tables in nls_utf8.c defintively seems odd to me. > Urban, is there a reason for that? The only thing that comes to > mind is that these tables might be quite large. > Case conversion in Unicode is locale dependent. The legacy 8-bit character encodings don't code for enough characters to run into the ambiguities, so they can get away with fixed case conversion tables. Unicode can't. I'd point you to the Unicode technical report which explains how to do it, but unicode.org seems to be offline right now. > > NTFS in Linux also implements it's own dcache and NTFS also > > ^^^^^^^ dentry operations? > > > stores its unicode case table on disk. This allows the filesystem > > to migrate to newer forms of Unicode at the time of formatting > > the filesystem. Eg. Windows Vista now supports Unicode 5.0 > > while older version would support an earlier version of > > Unicode. Linux's version of NTFS case table is implemented > > in fs/ntfs/upcase.c defined as default_upcase. > > Because ntfs uses 16bit wide chars it prefers to use it's own tables. > I'm not sure it's a that good idea. Well, Windows uses those on-disk tables, so the Linux driver has to also. I don't see how that's a bad idea or any way to not do it and remain compatible. -- Nicholas Miell From owner-xfs@oss.sgi.com Fri Oct 5 12:34:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 05 Oct 2007 12:34:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_14, J_CHICKENPOX_43,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l95JYUkB003726 for ; Fri, 5 Oct 2007 12:34:33 -0700 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from altaparmakov.plus.com ([212.159.79.82]:58992 helo=[192.168.1.69]) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:587) with esmtpsa (PLAIN:aia21) (TLSv1:AES128-SHA:128) id 1IdsZ5-0001lj-9X (Exim 4.63) (return-path ); Fri, 05 Oct 2007 20:10:24 +0100 In-Reply-To: <20071005154442.GA6432@infradead.org> References: <20071005154442.GA6432@infradead.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> Cc: Barry Naujok , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Transfer-Encoding: 7bit From: Anton Altaparmakov Subject: Re: RFC: Case-insensitive support for XFS Date: Fri, 5 Oct 2007 20:10:23 +0100 To: Christoph Hellwig X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4480/Fri Oct 5 07:51:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13278 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aia21@cam.ac.uk Precedence: bulk X-list: xfs Hi, On 5 Oct 2007, at 16:44, Christoph Hellwig wrote: > [Adding -fsdevel because some of the things touched here might be of > broader interest and Urban because his name is on nls_utf8.c] > > On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >> On it's own, linux only provides case conversion for old-style >> character sets - 8 bit sequences only. A lot of distos are >> now defaulting to UTF-8 and Linux NLS stuff does not support >> case conversion for any unicode sets. > > The lack of case tables in nls_utf8.c defintively seems odd to me. > Urban, is there a reason for that? The only thing that comes to > mind is that these tables might be quite large. > >> NTFS in Linux also implements it's own dcache and NTFS also > > ^^^^^^^ dentry operations? Where did that come from? NTFS does not have its own dcache! It doesn't have its own dentry operations either... NTFS uses the default ones... All the case insensitivity handling "cleverness" is done inside ntfs_lookup(), i.e. the NTFS directory inode operation ->lookup. >> stores its unicode case table on disk. This allows the filesystem >> to migrate to newer forms of Unicode at the time of formatting >> the filesystem. Eg. Windows Vista now supports Unicode 5.0 >> while older version would support an earlier version of >> Unicode. Linux's version of NTFS case table is implemented >> in fs/ntfs/upcase.c defined as default_upcase. The one in the current kernel is the Windows NT4/2000/XP one. Windows Vista uses a different table (the content is actually significantly different). My not yet allowed to be released NTFS driver uses the Vista table by default. But the default does not matter for NTFS. At mount time, the upcase table stored on the volume is read into memory and compared to the default one. If they match perfectly the default one is used (it is reference counted and discarded when not in use) and if they do not match the one from the volume is used. So we support both NT4/2k/XP and Vista style volumes fine no matter what default table we use... The only thing is that for each non-default table we waste 128kiB of vmalloc()ed kernel memory thus if you mount 10 NTFS volumes with non- default table we are wasting 1MiB of data... > Because ntfs uses 16bit wide chars it prefers to use it's own tables. > I'm not sure it's a that good idea. The upcase table is used during the case insensitive ->lookup and if you have the wrong table it will make the traversal in the directory b-tree go wrong and so you may not find files that actually exist when doing a ->lookup! So yes it is not only a good idea but an absolutely essential idea! You have to use the same upcase table for a volume as the upcase table with which the names on the volume were created otherwise your b-trees are screwed if they use any characters where the upper casing between the upcase table used when writing and the upcase table used when doing the lookup are not matched. > JFS also has wide-char names on > disk but at least partially uses the generic nls support, so there > must > be some trade-offs. > >> It will be proposed that in the future, XFS may default to >> UTF-8 on disk and to go for the old format, explicitily >> use a mkfs.xfs option. Two superbits will be used: one for >> case-insensitive (which generates lowercase hashes on disk) >> and that already exists on IRIX filesystems and a new one >> for UTF-8 filenames. Any combination of the two bits can be >> used and the dentry_operations will be adjusted accordingly. > > I don't think arbitrary combinations make sense. Without case > insensitive > support a unix filesystem couldn't care less what charset the > filenames > are in, except for the terminating 0 and '/', '.', '..' it's an > entirely > opaqueue stream of bytes. So chosing a charset only makes sense > with the case insensitive filename option. > >> So, in regards to the UTF-8 case-conversion/folding table, we >> have several options to choose from: >> - Use the HFS+ method as-is. >> - Use an NTFS scheme with an on-disk table. >> - Pick a current table and stick with it (similar to HFS+). >> - How much of Unicode to we support? Just the the "Basic >> Multilingual Plane" (U+0000 - U+FFFF) or the entire set? >> (anything above U+FFFF won't have case-conversion >> requirements). Seems that all the other filesystems >> just support the "BMP". >> - UTF-8, UTF-16 or UCS-2. >> >> With the last point, UTF-8 has several advantages IMO: >> - xfs_repair can easily detect UTF-8 sequences in filenames >> and also validate UTF-8 sequences. >> - char based structures don't change >> - "nulls" in filenames. >> - no endian conversions required. > > I think the right approach is to use the fs/nls/ code and allow the > user to select any table with a mount option as at least in russia > and eastern europe some non-utf8 charsets still seem to be prefered. > The default should of course be utf8 and support for utf8 case > conversion should be added to fs/nls/ > >> Internally, the names will probably be converted to "u16"s for >> efficient processing. Conversion between UTF-8 and UTF-16/UCS-2 >> is very straight forward. > > Do we really need that? And if so please make sure this only happens > for filesystems created with the case insensitivity option so normal > filesystems don't have to pay for these bloated strings. There is nothing efficient about using u16 in memory AFAIK. In fact for majority of the time it just means you use twice the memory per string... FWIW Mac OS X uses utf8 in the kernel and so does HFS(+) and I can't see anything wrong with that. And Windows uses u16 (little endian) and so does NTFS. So there is precedent for doing both internally... What are the reasons for suggesting that it would be more efficient to use u16 internally? Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ From owner-xfs@oss.sgi.com Sat Oct 6 01:10:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 06 Oct 2007 01:10:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 Received: from cynthia.pants.nu (adsl-76-245-85-235.dsl.pltn13.sbcglobal.net [76.245.85.235]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l968AKQb019459 for ; Sat, 6 Oct 2007 01:10:23 -0700 Received: from flar by cynthia.pants.nu with local (Exim 4.50) id 1Ie3IK-0007ir-RM; Fri, 05 Oct 2007 23:37:48 -0700 Date: Fri, 5 Oct 2007 23:37:48 -0700 From: Brad Boyer To: Anton Altaparmakov Cc: Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Subject: Re: RFC: Case-insensitive support for XFS Message-ID: <20071006063748.GA29396@cynthia.pants.nu> References: <20071005154442.GA6432@infradead.org> <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.91.2/4482/Fri Oct 5 15:43:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13279 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: flar@allandria.com Precedence: bulk X-list: xfs On Fri, Oct 05, 2007 at 08:10:23PM +0100, Anton Altaparmakov wrote: > But the default does not matter for NTFS. At mount time, the upcase > table stored on the volume is read into memory and compared to the > default one. If they match perfectly the default one is used (it is > reference counted and discarded when not in use) and if they do not > match the one from the volume is used. So we support both NT4/2k/XP > and Vista style volumes fine no matter what default table we use... > The only thing is that for each non-default table we waste 128kiB of > vmalloc()ed kernel memory thus if you mount 10 NTFS volumes with non- > default table we are wasting 1MiB of data... For HFS+, there is a single case conversion table that is defined in the on-disk format. It's in fs/hfsplus/tables.c with the data taken directly from Apple's documentation. > The upcase table is used during the case insensitive ->lookup and if > you have the wrong table it will make the traversal in the directory > b-tree go wrong and so you may not find files that actually exist > when doing a ->lookup! I had the same issue in HFS+. If the case conversion isn't handled right, the key matching doesn't work and the code wanders off into nowhere in the catalog btree on any catalog lookup. Since everything in HFS+ goes through the catalog in one way or another, losing this would make most of the filesystem inaccessible. Even a lookup by inode number to satisfy iget() goes through the same search code. > So yes it is not only a good idea but an absolutely essential idea! > You have to use the same upcase table for a volume as the upcase > table with which the names on the volume were created otherwise your > b-trees are screwed if they use any characters where the upper casing > between the upcase table used when writing and the upcase table used > when doing the lookup are not matched. The HFS+ unicode handling is a hard-coded mess of tables and offsets for this exact reason. It handles manual decomposition and case folding in exactly the method from the official documentation. Any other way wouldn't properly support a filesystem with non-ASCII file names. > FWIW Mac OS X uses utf8 in the kernel and so does HFS(+) and I can't > see anything wrong with that. And Windows uses u16 (little endian) > and so does NTFS. So there is precedent for doing both internally... Apple may use utf8 internally in OSX, but HFS+ uses UTF16 on disk. Just look at the definition of struct hfsplus_unistr in hfsplus_raw.h. The utf8 <=> utf16 conversion is the one place the hfsplus module uses the nls code directly. If you want to talk about original HFS, Apple never supported the use of unicode and converts in the driver to the encoding used on the individual HFS volume. The Linux implementation of HFS uses the nls code in a pretty traditional way to do this. > What are the reasons for suggesting that it would be more efficient > to use u16 internally? At least for HFS+, it's easiest to use a u16 to track the characters because that is what is on disk. That's not a very generic reason, obviously. Brad Boyer flar@allandria.com From owner-xfs@oss.sgi.com Sat Oct 6 01:30:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 06 Oct 2007 01:30:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_50, RCVD_IN_DNSWL_MED,RDNS_NONE autolearn=ham version=3.3.0-r574664 Received: from ahmler9.mail.eds.com ([192.85.154.119]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l968TxDM022869 for ; Sat, 6 Oct 2007 01:30:00 -0700 Received: from ahmler9.mail.eds.com (localhost.localdomain [127.0.0.1]) by ahmler9.mail.eds.com (8.13.8/8.13.8) with ESMTP id l967ZfKm022269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 6 Oct 2007 03:35:41 -0400 Received: from localhost (localhost) by ahmler9.mail.eds.com (8.13.8/8.13.8) id l967ZfSZ022246; Sat, 6 Oct 2007 03:35:41 -0400 Date: Sat, 6 Oct 2007 03:35:41 -0400 From: Mail Delivery Subsystem Message-Id: <200710060735.l967ZfSZ022246@ahmler9.mail.eds.com> X-EDS-Source-Ip: 151.38.143.88 X-EDS-Source-Name: adsl-88-143.38-151.net24.it X-EDS-Reported-Name: localhost To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l967ZfSZ022246.1191656141/ahmler9.mail.eds.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Virus-Scanned: ClamAV 0.91.2/4482/Fri Oct 5 15:43:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13280 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@ahmler9.mail.eds.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l967ZfSZ022246.1191656141/ahmler9.mail.eds.com The original message was received at Sat, 6 Oct 2007 03:35:39 -0400 from adsl-88-143.38-151.net24.it [151.38.143.88] ----- The following addresses had permanent fatal errors ----- (reason: 553 5.3.0 ... Invalid Rcpt - Sender is ) ----- Transcript of session follows ----- ... while talking to localhost: >>> DATA <<< 553 5.3.0 ... Invalid Rcpt - Sender is 550 5.1.1 ... User unknown <<< 503 Need RCPT (recipient) --l967ZfSZ022246.1191656141/ahmler9.mail.eds.com Content-Type: message/delivery-status Reporting-MTA: dns; ahmler9.mail.eds.com Received-From-MTA: DNS; adsl-88-143.38-151.net24.it Arrival-Date: Sat, 6 Oct 2007 03:35:39 -0400 Final-Recipient: RFC822; timothy.werth@eds.com Action: failed Status: 5.3.0 Remote-MTA: DNS; localhost Diagnostic-Code: SMTP; 553 5.3.0 ... Invalid Rcpt - Sender is Last-Attempt-Date: Sat, 6 Oct 2007 03:35:41 -0400 --l967ZfSZ022246.1191656141/ahmler9.mail.eds.com Content-Type: text/rfc822-headers Content-Transfer-Encoding: 8bit Return-Path: Received: from oss.sgi.com (adsl-88-143.38-151.net24.it [151.38.143.88]) by ahmler9.mail.eds.com (8.13.8/8.13.8) with ESMTP id l967ZXSZ021239 for ; Sat, 6 Oct 2007 03:35:39 -0400 Message-Id: <200710060735.l967ZXSZ021239@ahmler9.mail.eds.com> X-EDS-Source-Ip: 151.38.143.88 X-EDS-Source-Name: adsl-88-143.38-151.net24.it X-EDS-Reported-Name: oss.sgi.com From: linux-xfs@oss.sgi.com To: timothy.werth@eds.com Subject: Returned mail: see transcript for details Date: Sat, 6 Oct 2007 09:35:34 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_3A6D2CEA.D4E57891" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 --l967ZfSZ022246.1191656141/ahmler9.mail.eds.com-- From owner-xfs@oss.sgi.com Sat Oct 6 06:01:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 06 Oct 2007 06:01:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l96D1BfJ010129 for ; Sat, 6 Oct 2007 06:01:14 -0700 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from altaparmakov.plus.com ([212.159.79.82]:59862 helo=[192.168.1.69]) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:587) with esmtpsa (PLAIN:aia21) (TLSv1:AES128-SHA:128) id 1Ie9H8-0006uy-FE (Exim 4.63) (return-path ); Sat, 06 Oct 2007 14:00:58 +0100 In-Reply-To: <20071006063748.GA29396@cynthia.pants.nu> References: <20071005154442.GA6432@infradead.org> <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> <20071006063748.GA29396@cynthia.pants.nu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F357001-E248-4A19-9C06-518CC23B5496@cam.ac.uk> Cc: Christoph Hellwig , Barry Naujok , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Transfer-Encoding: 7bit From: Anton Altaparmakov Subject: Re: RFC: Case-insensitive support for XFS Date: Sat, 6 Oct 2007 14:00:55 +0100 To: Brad Boyer X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4482/Fri Oct 5 15:43:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13281 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aia21@cam.ac.uk Precedence: bulk X-list: xfs Hi, On 6 Oct 2007, at 07:37, Brad Boyer wrote: > On Fri, Oct 05, 2007 at 08:10:23PM +0100, Anton Altaparmakov wrote: >> But the default does not matter for NTFS. At mount time, the upcase >> table stored on the volume is read into memory and compared to the >> default one. If they match perfectly the default one is used (it is >> reference counted and discarded when not in use) and if they do not >> match the one from the volume is used. So we support both NT4/2k/XP >> and Vista style volumes fine no matter what default table we use... >> The only thing is that for each non-default table we waste 128kiB of >> vmalloc()ed kernel memory thus if you mount 10 NTFS volumes with non- >> default table we are wasting 1MiB of data... > > For HFS+, there is a single case conversion table that is defined in > the on-disk format. It's in fs/hfsplus/tables.c with the data taken > directly from Apple's documentation. > >> The upcase table is used during the case insensitive ->lookup and if >> you have the wrong table it will make the traversal in the directory >> b-tree go wrong and so you may not find files that actually exist >> when doing a ->lookup! > > I had the same issue in HFS+. If the case conversion isn't handled > right, the key matching doesn't work and the code wanders off into > nowhere in the catalog btree on any catalog lookup. Since everything > in HFS+ goes through the catalog in one way or another, losing this > would make most of the filesystem inaccessible. Even a lookup by > inode number to satisfy iget() goes through the same search code. > >> So yes it is not only a good idea but an absolutely essential idea! >> You have to use the same upcase table for a volume as the upcase >> table with which the names on the volume were created otherwise your >> b-trees are screwed if they use any characters where the upper casing >> between the upcase table used when writing and the upcase table used >> when doing the lookup are not matched. > > The HFS+ unicode handling is a hard-coded mess of tables and offsets > for this exact reason. It handles manual decomposition and case > folding in exactly the method from the official documentation. Any > other way wouldn't properly support a filesystem with non-ASCII > file names. > >> FWIW Mac OS X uses utf8 in the kernel and so does HFS(+) and I can't >> see anything wrong with that. And Windows uses u16 (little endian) >> and so does NTFS. So there is precedent for doing both internally... > > Apple may use utf8 internally in OSX, but HFS+ uses UTF16 on disk. > Just Ah, oops, sorry. I had never looked at that bit of the HFS+ code. I just assumed that HFS+ must use the same on-disk as inside the VFS on OS X but you are quite right that it does not do so. > look at the definition of struct hfsplus_unistr in hfsplus_raw.h. The > utf8 <=> utf16 conversion is the one place the hfsplus module uses > the nls code directly. If you want to talk about original HFS, Apple > never supported the use of unicode and converts in the driver to the > encoding used on the individual HFS volume. The Linux implementation > of HFS uses the nls code in a pretty traditional way to do this. > >> What are the reasons for suggesting that it would be more efficient >> to use u16 internally? > > At least for HFS+, it's easiest to use a u16 to track the characters > because that is what is on disk. That's not a very generic reason, > obviously. Not a reason at all actually. It does not matter whether you use u16 or utf8 because in both cases you have to do character-by-character translation/handling for HFS+ (because of precomposed vs decomposed Unicode and thus strings having to match even when they are not byte- for-byte identical) and once you are doing that sort of parsing and conversion you might as well convert to utf8 which IMHO is more efficient in the general case not least because it uses less memory. Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ From owner-xfs@oss.sgi.com Sun Oct 7 00:15:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 00:15:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l977FMsL019401 for ; Sun, 7 Oct 2007 00:15:27 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1303363waf for ; Sun, 07 Oct 2007 00:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Zgjmk9z4IM3eoD5ZeSuIi0pTuind3MD0u+x9DyEx3R8=; b=nA3kggO+zypxp/pukeviyxXEv2In2zvn2EgKnpyE+S94MHEJB2kvOOXURUrjY/CAOX/qFLE0xFrbfFdgeZYkaZR+dMzdBPhi9+XyXGVwfXZ9EsB4ha5CD8cipLJWOvyP3ixk9B5RfGiDlv2cQOCy+rEH48Tuq9R0h94U4SClk8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pd/El83Ei9EiCCrWh3tkhpfm9bzF3cRchdr5NWc7+DReD18qKiqhPMT6vlkRy0lwaKLw5B/oaZucNqjIG4DAPg3ztEGhYtf5pXNSq5gIv7qUrKP7YnGumMZ7xYlDhPaKtsZhWIOncCbm4kDg0ydcvoFw2xKI70TXiaFFxCNlVm0= Received: by 10.114.57.1 with SMTP id f1mr8417458waa.1191741323752; Sun, 07 Oct 2007 00:15:23 -0700 (PDT) Received: by 10.114.254.18 with HTTP; Sun, 7 Oct 2007 00:15:23 -0700 (PDT) Message-ID: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> Date: Sun, 7 Oct 2007 09:15:23 +0200 From: Raz To: linux-xfs@oss.sgi.com Subject: mounting raid5 with different unit values MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.91.2/4491/Sat Oct 6 19:29:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13282 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Hello I am trying to mount xfs over raid5. I am trying to mount it with different values than the true ones. the mount fails with a general error of : mount -osunit=6144,swidth=18432 /dev/md1 /d1/ mount: wrong fs type, bad option, bad superblock on /dev/md1, or too many mounted file systems the true values are: xfs_info /d1/ meta-data=/dev/md1 isize=256 agcount=32, agsize=5687296 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=181989888, imaxpct=25 = sunit=256 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 this same command did work on 2.6.15 while it failing on 2.6.17 . why ? -- Raz From owner-xfs@oss.sgi.com Sun Oct 7 01:16:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 01:16:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l978Gbqb001979 for ; Sun, 7 Oct 2007 01:16:39 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id EBDA91C000264; Sun, 7 Oct 2007 04:16:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id E8EAF4019580; Sun, 7 Oct 2007 04:16:37 -0400 (EDT) Date: Sun, 7 Oct 2007 04:16:37 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Raz cc: linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values In-Reply-To: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> Message-ID: References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4491/Sat Oct 6 19:29:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13283 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 On Sun, 7 Oct 2007, Raz wrote: > Hello > I am trying to mount xfs over raid5. I am trying to mount it with > different values than > the true ones. the mount fails with a general error of : > mount -osunit=6144,swidth=18432 /dev/md1 /d1/ > mount: wrong fs type, bad option, bad superblock on /dev/md1, > or too many mounted file systems > > the true values are: > xfs_info /d1/ > meta-data=/dev/md1 isize=256 agcount=32, agsize=5687296 blks > = sectsz=4096 attr=0 > data = bsize=4096 blocks=181989888, imaxpct=25 > = sunit=256 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 > > > this same command did work on 2.6.15 while it failing on 2.6.17 . > why ? > -- > Raz > > Good question but also be alert that 2.6.17-2.6.17.6 will/may corrupt your XFS filesystem due to a nasty bug. Justin. From owner-xfs@oss.sgi.com Sun Oct 7 02:47:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 02:47:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l979l6Zg016236 for ; Sun, 7 Oct 2007 02:47:07 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IeSj5-0002dR-AA for linux-xfs@oss.sgi.com; Sun, 07 Oct 2007 02:47:07 -0700 Message-ID: <13081228.post@talk.nabble.com> Date: Sun, 7 Oct 2007 02:47:07 -0700 (PDT) From: qon To: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: blamaul@web.de References: X-Virus-Scanned: ClamAV 0.91.2/4491/Sat Oct 6 19:29:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13284 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: blamaul@web.de Precedence: bulk X-list: xfs I'm sorry this is quite late for you but I recently had exactly the same problem and now finally found the solution. So this might help people that will get the same error hopefully. You used a GPT Partition Table. To protect the GPT table from os that do not support is a standard mbr with msdos partition table is written to the disc in front of the GPT table that indicates the whole disc space is used by an unknown partition of 2TB (as msdos tables do not support larger partitions). Linux recognizes GPT table when booting only when this is explicitly enable in the Kernel (filesystem/partition types/efi). Though when creating a GPT table using parted for example obviously when then rereading the partition table the partition is recognized correctly. This might change after a reboot as in you case. For me it then reportet a 2TB partition on my 2,X TB harddisk and it could no longer mount my XFS filesystem. I ran xfs_check and got exactly the same error as you (unexspected XFS SB). This is because it tried to mount the partition in the fake msdos partition table of 2 tb that startet exactly where the GPT table resides, so when looking for the superblock it found the EFI Bootloader. When you ran xfs_repair it of course found a superblock (may be even the correct superblock), but all pointers are shiftet so it did not find any files. Then you partition was reportet as 2tb partition after the repair, because it used the partition size from the msdos table again. So for me updateing the kernel to directly support efi tables solved the problem. qon Gaspar Bakos wrote: > > Dear all, > > I have a 12 x 500Gb RAID-5 hardware RAID array on an ARECA 1130-ML > controller. There is one single partition on it, exported as /dev/sdc1. > This configuration used to work fine for 4 months. > Then the computer crashed a couple of times, and led to a situation where > > xfs_check /dev/sdc1 output is: > > xfs_check: unexpected XFS SB magic number 0x45464920 > xfs_check: size check failed > xfs_check: read failed: Invalid argument > xfs_check: data size check failed > xfs_check: failed to alloc 58876353264 bytes: Cannot allocate memory > > I also checked the RAID, and seemingly the controller is fine; I can > communicate with it, all 12 disks are visible, their SMART status is > OK, the RAID-5 is reported to be in 'normal' condition, etc. > > [root@localhost ~]# xfs_db -r /dev/sdc1 > xfs_db: unexpected XFS SB magic number 0x45464920 > xfs_db: size check failed > xfs_db: read failed: Invalid argument > xfs_db: data size check failed > xfs_db: failed to alloc 58876353264 bytes: Cannot allocate memory > > -------------------- > > [root@localhost ~]# xfs_repair -nv /dev/sdc1 > > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > attempting to find secondary superblock... > ................................................................................ > ... > ....................found candidate secondary superblock... > unable to verify superblock, continuing... > ... > ....................found candidate secondary superblock... > verified secondary superblock... > would write modified primary superblock > Primary superblock would have been modified. > Cannot proceed further in no_modify mode. > Exiting now. > > ---------------- > > > I would very much appreciate advice on how to proceed in such situation. > I worry that xfs_repair will repair, but may leave a mess that is hard > to recover. I am hoping there may be a safer way. > > > Best regards > Gaspar > > > > -- View this message in context: http://www.nabble.com/unexpected-XFS-SB-magic-number-tf2871877.html#a13081228 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Sun Oct 7 04:53:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 04:53:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from mk-filter-1-a-2.mail.uk.tiscali.com (mk-filter-1-a-2.mail.uk.tiscali.com [212.74.100.48]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l97BrpCY018026 for ; Sun, 7 Oct 2007 04:53:52 -0700 X-Trace: 611548627-mk-filter-1.mail.uk.tiscali.com-WEBB2C-$ALLOWED_RELAY-ALLOWED-B2C-WEBMAIL X-SBRS: -0.3 X-RemoteIP: 212.74.100.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAL9jCEfUSmSNYWdsb2JhbACOLhUHLA Received: from mail-1.uk.tiscali.com ([212.74.100.141]) by websmtp.tiscali.co.uk with ESMTP; 07 Oct 2007 12:43:45 +0100 Received: from [77.60.193.41] by mail-1.uk.tiscali.com with HTTP; Sun, 7 Oct 2007 13:43:44 +0200 Date: Sun, 7 Oct 2007 13:43:44 +0200 Message-ID: <4705015800001392@mail-1-uk.mail.tiscali.sys> From: "cole v. hans" Subject: sir madam call Reply-To: trustgroupag5@netscape.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/4491/Sat Oct 6 19:29:59 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13285 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ritawe@handbag.com Precedence: bulk X-list: xfs sir madam call This is to inform you that your email ID with your email address draw lotto dream number 104 has won US$2, 000, 000. 00 in the first category of our computer ballot email Award with the said winning numbers giving below; Ticket Number: 663 51273503 20XX,Batch No: 2/12/29/30/33/385 Ref No: MXF 77 222-656,Lucky NO: 73-90-53-ASWX CONTACT CLAIM OFFICE Mr.Cole v. Hans. E-Mail CONTACT Person: trustgroupag5@netscape.net TELE: 0031-611-146-930, Congratulations! Once more from all staff of Lotto Award INTERNATIONAL.Regards,Mrs.lrena versloot PROMOTION CO-ORDINATOR ___________________________________________________________ Tiscali Broadband from 14.99 with free setup! http://www.tiscali.co.uk/products/broadband/ From owner-xfs@oss.sgi.com Sun Oct 7 08:18:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 08:19:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l97FIt4J020223 for ; Sun, 7 Oct 2007 08:18:59 -0700 Received: (qmail 39612 invoked from network); 7 Oct 2007 14:52:15 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@76.205.249.127 with login) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 7 Oct 2007 14:52:15 -0000 X-YMail-OSG: 3.Xa.dgVM1lQJMUd7GV9yBXKTQQt0iHO9HhuGgun60w_02LUBQta8hdnWbbsP998cxH7jnM5uw-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id A3DB828397EB; Sun, 7 Oct 2007 07:52:13 -0700 (PDT) Date: Sun, 7 Oct 2007 07:52:13 -0700 From: Chris Wedgwood To: Raz Cc: linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values Message-ID: <20071007145213.GA4504@puku.stupidest.org> References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> X-Virus-Scanned: ClamAV 0.91.2/4493/Sun Oct 7 06:25:36 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13286 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 On Sun, Oct 07, 2007 at 09:15:23AM +0200, Raz wrote: > mount -osunit=6144,swidth=18432 /dev/md1 /d1/ those values are set when you make the filesystem, not mount it see the mkfs.xfs man page From owner-xfs@oss.sgi.com Sun Oct 7 08:48:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 08:48:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_55,J_CHICKENPOX_65,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l97FmD7D028733 for ; Sun, 7 Oct 2007 08:48:15 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 758FC1C000267; Sun, 7 Oct 2007 11:48:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 737504019580; Sun, 7 Oct 2007 11:48:14 -0400 (EDT) Date: Sun, 7 Oct 2007 11:48:14 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Chris Wedgwood cc: Raz , linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values In-Reply-To: <20071007145213.GA4504@puku.stupidest.org> Message-ID: References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007145213.GA4504@puku.stupidest.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4493/Sun Oct 7 06:25:36 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13287 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 On Sun, 7 Oct 2007, Chris Wedgwood wrote: > On Sun, Oct 07, 2007 at 09:15:23AM +0200, Raz wrote: > >> mount -osunit=6144,swidth=18432 /dev/md1 /d1/ > > those values are set when you make the filesystem, not mount it > > see the mkfs.xfs man page > > ? man mount :) sunit=value and swidth=value Used to specify the stripe unit and width for a RAID device or a stripe volume. value must be specified in 512-byte block units. If this option is not specified and the filesystem was made on a stripe volume or the stripe width or unit were specified for the RAID device at mkfs time, then the mount system call will restore the value from the superblock. For filesystems that are made directly on RAID devices, these options can be used to override the information in the superblock if the underlying disk layout changes after the filesystem has been created. The swidth option is required if the sunit option has been speci- fied, and must be a multiple of the sunit value. He should be able to specify those option from the command line using mount. Justin. From owner-xfs@oss.sgi.com Sun Oct 7 10:42:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 10:42:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l97HgHhZ015538 for ; Sun, 7 Oct 2007 10:42:19 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1453023waf for ; Sun, 07 Oct 2007 10:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YnmGZb1CoFObg3EI2lYblfAYVRqv3T0UKjAq/8+TeWg=; b=huPajv6HImJ3gcI/OA0r7UogFUqDAOqn4sWrZJO/+/8+H7n5eJRI3X1TNLBi/dFtOkgk18UW9p8C2p9uFT1x8Qkd/0ThAOFiSR0uI1t9wzg0pvSps2UkmPvk5vVrh6iOzzoAMygm3Fvk+HbGfOKSZziikykXF+lX082HMTP36oI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ilC8RmX06+PgAd8JDmo6z3iJwVsSWlaGRpNQKa+kXKO2l0s0wJTMlXNmKipfoQfoY7JJWJKoGJ/96mIrhEyrMNPlC5e4nG9rTsIe5Dh5+fJDcTsP+7o471oalyz8kznf7RqyT7TQIbDJB7aLl2JLzjJnZ3F9FOPOK/jZjo7EUM8= Received: by 10.114.201.1 with SMTP id y1mr3856013waf.1191778937304; Sun, 07 Oct 2007 10:42:17 -0700 (PDT) Received: by 10.114.254.18 with HTTP; Sun, 7 Oct 2007 10:42:17 -0700 (PDT) Message-ID: <5d96567b0710071042paa1f804o5914250b1e18aa13@mail.gmail.com> Date: Sun, 7 Oct 2007 19:42:17 +0200 From: Raz To: "Justin Piszcz" Subject: Re: mounting raid5 with different unit values Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> X-Virus-Scanned: ClamAV 0.91.2/4496/Sun Oct 7 07:50:36 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13288 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs On 10/7/07, Justin Piszcz wrote: > > > On Sun, 7 Oct 2007, Raz wrote: > > > Hello > > I am trying to mount xfs over raid5. I am trying to mount it with > > different values than > > the true ones. the mount fails with a general error of : > > mount -osunit=6144,swidth=18432 /dev/md1 /d1/ > > mount: wrong fs type, bad option, bad superblock on /dev/md1, > > or too many mounted file systems > > > > the true values are: > > xfs_info /d1/ > > meta-data=/dev/md1 isize=256 agcount=32, agsize=5687296 blks > > = sectsz=4096 attr=0 > > data = bsize=4096 blocks=181989888, imaxpct=25 > > = sunit=256 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 > > > > > > this same command did work on 2.6.15 while it failing on 2.6.17 . > > why ? > > -- > > Raz > > > > > > Good question but also be alert that 2.6.17-2.6.17.6 will/may corrupt your > XFS filesystem due to a nasty bug. > > Justin. > I am using patched xfs ( the patch of 2.6.17.7) -- Raz From owner-xfs@oss.sgi.com Sun Oct 7 11:13:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 11:13:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l97IDVvB020114 for ; Sun, 7 Oct 2007 11:13:34 -0700 Received: by nf-out-0910.google.com with SMTP id e27so958698nfd for ; Sun, 07 Oct 2007 11:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3UavqE1CYj821ZO/tjcxreWW2/qwc/ruI/6pL1QxUwI=; b=nZlDjGn01PpfPp3riGTU3ot2n0zlSCCcK1mI2ElWspPPQBBgyIz8qiQD9EdERLDh1xOFbEM8OMbx2A5CbaWEolBYVmFP8Xcpd7z4iLM8pQHLsOflNi/TTA33JOlB2J3itqWooBHf/6FLnvcFHSEaFDZ4gepKFDa6Ux2xTCHzCkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I1JwxlD0wv7mVbdGqND1dvNrL/ZOmridRyHqH5pQYn34MHsv2Gl9GTuvrWkW0JIHfjhUVYETaVFhAgng/d5/bl5iwVv9xGGe3njnP5OSkxYAwV9YQgwSnSPDv/xKUg35ZO4erednd8mHyObMDBtRAVxMJh9EnPYHYAswPAbavIE= Received: by 10.78.142.14 with SMTP id p14mr5917155hud.1191779141422; Sun, 07 Oct 2007 10:45:41 -0700 (PDT) Received: by 10.78.150.10 with HTTP; Sun, 7 Oct 2007 10:45:41 -0700 (PDT) Message-ID: <5d96567b0710071045q1472a3c7p39d2f707f54d496c@mail.gmail.com> Date: Sun, 7 Oct 2007 19:45:41 +0200 From: Raz To: "Chris Wedgwood" Subject: Re: mounting raid5 with different unit values Cc: linux-xfs@oss.sgi.com In-Reply-To: <20071007145213.GA4504@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007145213.GA4504@puku.stupidest.org> X-Virus-Scanned: ClamAV 0.91.2/4496/Sun Oct 7 07:50:36 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13289 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs On 10/7/07, Chris Wedgwood wrote: > On Sun, Oct 07, 2007 at 09:15:23AM +0200, Raz wrote: > > > mount -osunit=6144,swidth=18432 /dev/md1 /d1/ > > those values are set when you make the filesystem, not mount it > > see the mkfs.xfs man page > it was possible to mkfs the file system in different units in 2.6.15, but it is is not possible to mkfs it with differrent unit sizes in 2.6.17. -- Raz From owner-xfs@oss.sgi.com Sun Oct 7 15:19:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 15:19:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l97MJARQ024298 for ; Sun, 7 Oct 2007 15:19: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 IAA26026; Mon, 8 Oct 2007 08:19:06 +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 l97MJ4dD53969203; Mon, 8 Oct 2007 08:19:05 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l97MJ3tR55070720; Mon, 8 Oct 2007 08:19:03 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 8 Oct 2007 08:19:03 +1000 From: David Chinner To: Raz Cc: linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values Message-ID: <20071007221902.GO23367404@sgi.com> References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4497/Sun Oct 7 11:53:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13290 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 On Sun, Oct 07, 2007 at 09:15:23AM +0200, Raz wrote: > Hello > I am trying to mount xfs over raid5. I am trying to mount it with > different values than > the true ones. the mount fails with a general error of : > mount -osunit=6144,swidth=18432 /dev/md1 /d1/ > mount: wrong fs type, bad option, bad superblock on /dev/md1, > or too many mounted file systems Try looking in your syslog or dmesg for the error that occurred during mount. THere's the possibility that it won't give you an error because of a bug that was fixed more recently than 2.6.17 that suppressd errors incorrectly. You shoul dreally try a more recent kernel ;) Most likely, the new sunit/swidth are being rejected because of alignent reasons (e.g. the AG size is not a multiple of the new sunit you are setting). Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 7 16:00:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 16:00:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l97N0aNv031566 for ; Sun, 7 Oct 2007 16:00:38 -0700 Received: from Liberator.local (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 8D1D01800F188; Sun, 7 Oct 2007 18:00:32 -0500 (CDT) Message-ID: <4709650F.7060101@sandeen.net> Date: Sun, 07 Oct 2007 18:00:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Raz , linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007221902.GO23367404@sgi.com> In-Reply-To: <20071007221902.GO23367404@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4498/Sun Oct 7 13:42:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13291 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 David Chinner wrote: > On Sun, Oct 07, 2007 at 09:15:23AM +0200, Raz wrote: >> Hello >> I am trying to mount xfs over raid5. I am trying to mount it with >> different values than >> the true ones. the mount fails with a general error of : >> mount -osunit=6144,swidth=18432 /dev/md1 /d1/ >> mount: wrong fs type, bad option, bad superblock on /dev/md1, >> or too many mounted file systems > > Try looking in your syslog or dmesg for the error that occurred > during mount. Just a general plea to everyone. If you get that above generic mount error ("... or planets out of alignment") you *really* need to look at dmesg to get any idea what's actually gone wrong. -Eric From owner-xfs@oss.sgi.com Sun Oct 7 17:15:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 17:15:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l980F1oi015789 for ; Sun, 7 Oct 2007 17:15:03 -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 KAA27760; Mon, 8 Oct 2007 10:14: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 l980EsdD54899913; Mon, 8 Oct 2007 10:14:55 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l980EqSl55263382; Mon, 8 Oct 2007 10:14:52 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 8 Oct 2007 10:14:52 +1000 From: David Chinner To: Max Waterman Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error Message-ID: <20071008001452.GX995458@sgi.com> References: <470831E6.4030704@fastmail.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470831E6.4030704@fastmail.co.uk> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4498/Sun Oct 7 13:42:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13292 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 [please cc xfs@oss.sgi.com on XFS bug reports. thx.] On Sun, Oct 07, 2007 at 09:09:58AM +0800, Max Waterman wrote: > Hi, > > I have just had an XFS error occur while deleting some directory > hierarchy. I hope this is the correct place to report it. ..... > This is in syslog : > > > Oct 6 23:40:33 jeeves kernel: xfs_da_do_buf: bno 16777216 ^^^^^^^^^^^^^ > > Oct 6 23:40:33 jeeves kernel: dir: inode 2095141277 > > Oct 6 23:40:33 jeeves kernel: Filesystem "md2": XFS internal error xfs_da_do_buf(1) at line 1994 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff889b2de4 Did you ever run 2.6.17-2.6.17.6? If so, this implies: http://oss.sgi.com/projects/xfs/faq.html#dir2 > I am fairly sure there is nothing I can do about this, but I thought it > prudent to mention it. Searching turned up some similar issues, but they > seem related to a previous kernel version and claimed to be fixed in > subsequent versions. Yes, but those previous corruptions get left on disk as a landmine for you to trip over some time later, even on a kernel that has the bug fixed. I suggest that you run xfs_check on the filesystem and if that shows up errors, run xfs_repair onteh filesystem to correct them. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 7 17:29:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 17:29:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l980T0lP020265 for ; Sun, 7 Oct 2007 17:29:03 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA27982; Mon, 8 Oct 2007 10:28:53 +1000 Date: Mon, 08 Oct 2007 10:33:27 +1000 To: "Christoph Hellwig" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20071005154442.GA6432@infradead.org> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4498/Sun Oct 7 13:42:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13293 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sat, 06 Oct 2007 01:44:42 +1000, Christoph Hellwig wrote: > [Adding -fsdevel because some of the things touched here might be of > broader interest and Urban because his name is on nls_utf8.c] > > On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >> >> It will be proposed that in the future, XFS may default to >> UTF-8 on disk and to go for the old format, explicitily >> use a mkfs.xfs option. Two superbits will be used: one for >> case-insensitive (which generates lowercase hashes on disk) >> and that already exists on IRIX filesystems and a new one >> for UTF-8 filenames. Any combination of the two bits can be >> used and the dentry_operations will be adjusted accordingly. > > I don't think arbitrary combinations make sense. Without case > insensitive > support a unix filesystem couldn't care less what charset the filenames > are in, except for the terminating 0 and '/', '.', '..' it's an entirely > opaqueue stream of bytes. So chosing a charset only makes sense > with the case insensitive filename option. I was thinking along the lines of the isocharset mount option that specifies the 8-bit codepage should be converted to/from UTF-8. In the end, I suppose it ends up as a an "opaque stream of bytes" for a case sensitive filesytem. I've started implementing the changes to XFS and UTF8/old have no differences. >> So, in regards to the UTF-8 case-conversion/folding table, we >> have several options to choose from: >> - Use the HFS+ method as-is. >> - Use an NTFS scheme with an on-disk table. >> - Pick a current table and stick with it (similar to HFS+). >> - How much of Unicode to we support? Just the the "Basic >> Multilingual Plane" (U+0000 - U+FFFF) or the entire set? >> (anything above U+FFFF won't have case-conversion >> requirements). Seems that all the other filesystems >> just support the "BMP". >> - UTF-8, UTF-16 or UCS-2. >> >> With the last point, UTF-8 has several advantages IMO: >> - xfs_repair can easily detect UTF-8 sequences in filenames >> and also validate UTF-8 sequences. >> - char based structures don't change >> - "nulls" in filenames. >> - no endian conversions required. > > I think the right approach is to use the fs/nls/ code and allow the > user to select any table with a mount option as at least in russia > and eastern europe some non-utf8 charsets still seem to be prefered. > The default should of course be utf8 and support for utf8 case > conversion should be added to fs/nls/ > >> Internally, the names will probably be converted to "u16"s for >> efficient processing. Conversion between UTF-8 and UTF-16/UCS-2 >> is very straight forward. > > Do we really need that? And if so please make sure this only happens > for filesystems created with the case insensitivity option so normal > filesystems don't have to pay for these bloated strings. Sort of as the NLS conversions use wchar_t's. From that, I can convert straight back to utf8 anyway. Barry. From owner-xfs@oss.sgi.com Sun Oct 7 17:38:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 17:38:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l980ceo9022772 for ; Sun, 7 Oct 2007 17:38:42 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA28196; Mon, 8 Oct 2007 10:38:31 +1000 Date: Mon, 08 Oct 2007 10:43:08 +1000 To: "Anton Altaparmakov" , "Christoph Hellwig" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <9385969D-539B-4246-B44E-9759446BC088@cam.ac.uk> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4498/Sun Oct 7 13:42:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13294 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sat, 06 Oct 2007 05:10:23 +1000, Anton Altaparmakov wrote: > Hi, > > On 5 Oct 2007, at 16:44, Christoph Hellwig wrote: >> [Adding -fsdevel because some of the things touched here might be of >> broader interest and Urban because his name is on nls_utf8.c] >> >> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >>> On it's own, linux only provides case conversion for old-style >>> character sets - 8 bit sequences only. A lot of distos are >>> now defaulting to UTF-8 and Linux NLS stuff does not support >>> case conversion for any unicode sets. >> >> The lack of case tables in nls_utf8.c defintively seems odd to me. >> Urban, is there a reason for that? The only thing that comes to >> mind is that these tables might be quite large. >> >>> NTFS in Linux also implements it's own dcache and NTFS also >> >> ^^^^^^^ dentry operations? > > Where did that come from? NTFS does not have its own dcache! It > doesn't have its own dentry operations either... NTFS uses the default > ones... > > All the case insensitivity handling "cleverness" is done inside > ntfs_lookup(), i.e. the NTFS directory inode operation ->lookup. Sorry if I got this wrong. I derived my comment from fs/ntfs/namei.c: * In order to handle the case insensitivity issues of NTFS with regards to the * dcache and the dcache requiring only one dentry per directory, we deal with * dentry aliases that only differ in case in ->ntfs_lookup() while maintaining * a case sensitive dcache. Misinterpretation reading it again :) >>> Internally, the names will probably be converted to "u16"s for >>> efficient processing. Conversion between UTF-8 and UTF-16/UCS-2 >>> is very straight forward. >> >> Do we really need that? And if so please make sure this only happens >> for filesystems created with the case insensitivity option so normal >> filesystems don't have to pay for these bloated strings. > > There is nothing efficient about using u16 in memory AFAIK. In fact for > majority of the time it just means you use twice the memory per string... > > FWIW Mac OS X uses utf8 in the kernel and so does HFS(+) and I can't see > anything wrong with that. And Windows uses u16 (little endian) and so > does NTFS. So there is precedent for doing both internally... > > What are the reasons for suggesting that it would be more efficient to > use u16 internally? As I said to Christoph before, the only reason is the nls conversions use wchar_t. As I don't have any case tables yet (one of the primary points for discussion), I haven't settled on which method to use. If I do use u16, it will only be used temporarily for case comparison. Regards, barry. From owner-xfs@oss.sgi.com Sun Oct 7 17:45:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 17:45:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l980jEmV024200 for ; Sun, 7 Oct 2007 17:45:15 -0700 Received: (qmail 43441 invoked from network); 8 Oct 2007 00:45:15 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 Oct 2007 00:45:14 -0000 X-YMail-OSG: yWKvMNIVM1k6kxEbCD6pYjvck4h.2HVxj9VyX7nzw2PDdAFQ52m_IOGmzQvwWtKOfd_IzP5pgA-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 6E8FC2896A26; Sun, 7 Oct 2007 17:45:13 -0700 (PDT) Date: Sun, 7 Oct 2007 17:45:13 -0700 From: Chris Wedgwood To: Justin Piszcz Cc: Raz , linux-xfs@oss.sgi.com Subject: Re: mounting raid5 with different unit values Message-ID: <20071008004513.GA13543@puku.stupidest.org> References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007145213.GA4504@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV 0.91.2/4500/Sun Oct 7 16:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13295 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 On Sun, Oct 07, 2007 at 11:48:14AM -0400, Justin Piszcz wrote: > man mount :) Ah of course. But those will be more restrictive that what you can specify when you make the file-system (because mkfs.xfs can aligned the AGs to suit). From owner-xfs@oss.sgi.com Sun Oct 7 19:15:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 19:15:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=ANY_BOUNCE_MESSAGE,BAYES_40, FUZZY_AMBIEN,VBOUNCE_MESSAGE autolearn=no version=3.3.0-r574664 Received: from ambiente.ambiente.gov.ec (mail.ambiente.gov.ec [208.19.69.75]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l982Ewjc008214 for ; Sun, 7 Oct 2007 19:15:01 -0700 Date: Sun, 7 Oct 2007 19:15:01 -0700 Message-Id: <200710080215.l982Ewjc008214@oss.sgi.com> From: adminmae@ambiente.gov.ec To: xfs@oss.sgi.com Subject: Content violation X-Virus-Scanned: ClamAV 0.91.2/4500/Sun Oct 7 16:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13297 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adminmae@ambiente.gov.ec Precedence: bulk X-list: xfs Content violation found in email message. From: xfs@oss.sgi.com To: mcastro@ambiente.gov.ec File(s): transcript.scr Matching filename: *.scr From owner-xfs@oss.sgi.com Sun Oct 7 19:14:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 19:14:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_05,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l982E8Rr007875 for ; Sun, 7 Oct 2007 19:14:11 -0700 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id ABB1F2F9AD; Sun, 7 Oct 2007 21:54:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 07 Oct 2007 21:54:38 -0400 X-Sasl-enc: NAP64ax3TnIMtBH8YLqdqis/5faDk6oGlHPHmSEVwPO/ 1191808476 Received: from [10.0.8.117] (unknown [203.86.69.14]) by mail.messagingengine.com (Postfix) with ESMTP id B513431D4; Sun, 7 Oct 2007 21:54:34 -0400 (EDT) Message-ID: <47098DD4.4090207@fastmail.co.uk> Date: Mon, 08 Oct 2007 09:54:28 +0800 From: Max Waterman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Chinner CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> In-Reply-To: <20071008001452.GX995458@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4500/Sun Oct 7 16:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13296 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: davidmaxwaterman+kernel@fastmail.co.uk Precedence: bulk X-list: xfs David Chinner wrote: >> 1994 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff889b2de4 >> > > Did you ever run 2.6.17-2.6.17.6? I guess so, since I've been upgrading steadily since I installed FC6 some time ago. > If so, this implies: > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > Ah. I did see that, but stopped reading when I read it was fixed in later versions ... didn't get to the part where it still needed to be repaired/etc. >> I am fairly sure there is nothing I can do about this, but I thought it >> prudent to mention it. Searching turned up some similar issues, but they >> seem related to a previous kernel version and claimed to be fixed in >> subsequent versions. >> > > Yes, but those previous corruptions get left on disk as a landmine > for you to trip over some time later, even on a kernel that has the > bug fixed. > ah, ok. > I suggest that you run xfs_check on the filesystem and if that > shows up errors, run xfs_repair onteh filesystem to correct them. > It did, and I did, and another xfs_check produced no output. Do I need to do anything else to correct it? xfs_repair produced a whole bunch of stuff that I don't understand...this is the bit that looks most significant : > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > can't read freespace block 16777216 for directory inode 2095141277 > rebuilding directory inode 2095141277 > free block 16777216 for directory inode 2100841732 bad nused > rebuilding directory inode 2100841732 > free block 16777216 for directory inode 2102199514 bad nused > rebuilding directory inode 2102199514 > free block 16777216 for directory inode 2102200124 bad nused > rebuilding directory inode 2102200124 > free block 16777216 for directory inode 2102905843 bad nused > rebuilding directory inode 2102905843 > free block 16777216 for directory inode 3277510927 bad nused > rebuilding directory inode 3277510927 > free block 16777216 for directory inode 3277524487 bad nused > rebuilding directory inode 3277524487 > free block 16777216 for directory inode 3379886019 bad nused > rebuilding directory inode 3379886019 > - traversal finished ... > - moving disconnected inodes to lost+found ... That last line looks suspicious...furthermore, when I mount the filesystem, I don't see a 'lost+found' directory (which I've been used to seeing on IRIX). Ah, perhaps the '...' with *nothing* after it means it didn't do any moving. Am I right? Max. From owner-xfs@oss.sgi.com Sun Oct 7 19:32:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 19:32:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l982WXdI011121 for ; Sun, 7 Oct 2007 19:32:35 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 MAA00205; Mon, 8 Oct 2007 12:32:26 +1000 Date: Mon, 08 Oct 2007 12:32:30 +1000 To: "Max Waterman" , "David Chinner" Subject: Re: XFS internal error From: "Barry Naujok" Organization: SGI Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <47098DD4.4090207@fastmail.co.uk> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <47098DD4.4090207@fastmail.co.uk> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4500/Sun Oct 7 16:52:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13298 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 08 Oct 2007 11:54:28 +1000, Max Waterman wrote: > David Chinner wrote: >> I suggest that you run xfs_check on the filesystem and if that >> shows up errors, run xfs_repair onteh filesystem to correct them. >> > It did, and I did, and another xfs_check produced no output. > > Do I need to do anything else to correct it? xfs_repair produced a whole > bunch of stuff that I don't understand...this is the bit that looks most > significant : > >> Phase 6 - check inode connectivity... >> - resetting contents of realtime bitmap and summary inodes >> - traversing filesystem ... >> can't read freespace block 16777216 for directory inode 2095141277 >> rebuilding directory inode 2095141277 >> free block 16777216 for directory inode 2100841732 bad nused >> rebuilding directory inode 2100841732 >> free block 16777216 for directory inode 2102199514 bad nused >> rebuilding directory inode 2102199514 >> free block 16777216 for directory inode 2102200124 bad nused >> rebuilding directory inode 2102200124 >> free block 16777216 for directory inode 2102905843 bad nused >> rebuilding directory inode 2102905843 >> free block 16777216 for directory inode 3277510927 bad nused >> rebuilding directory inode 3277510927 >> free block 16777216 for directory inode 3277524487 bad nused >> rebuilding directory inode 3277524487 >> free block 16777216 for directory inode 3379886019 bad nused >> rebuilding directory inode 3379886019 >> - traversal finished ... >> - moving disconnected inodes to lost+found ... > That last line looks suspicious...furthermore, when I mount the > filesystem, I don't see a 'lost+found' directory (which I've been used > to seeing on IRIX). Ah, perhaps the '...' with *nothing* after it means > it didn't do any moving. Am I right? Yes, the latest xfs_repair doesn't create a lost+found unless it needs to, and if it does so, it will list the inodes moved there. So, in your case, nothing went to lost+found. Regards, Barry. From owner-xfs@oss.sgi.com Sun Oct 7 19:48:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 19:48:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l982mTTf013632 for ; Sun, 7 Oct 2007 19:48:31 -0700 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9722A2F5FA; Sun, 7 Oct 2007 22:48:30 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 07 Oct 2007 22:48:30 -0400 X-Sasl-enc: 4/CFOtLxEje6T6P1X907ntTXw74G1WQQGpR4ZxjmbNLt 1191811709 Received: from [10.0.8.117] (unknown [203.86.69.14]) by mail.messagingengine.com (Postfix) with ESMTP id D268745FB; Sun, 7 Oct 2007 22:48:26 -0400 (EDT) Message-ID: <47099A73.4020703@fastmail.co.uk> Date: Mon, 08 Oct 2007 10:48:19 +0800 From: Max Waterman User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Barry Naujok CC: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <47098DD4.4090207@fastmail.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13299 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: davidmaxwaterman+kernel@fastmail.co.uk Precedence: bulk X-list: xfs Barry Naujok wrote: > Yes, the latest xfs_repair doesn't create a lost+found unless it > needs to, and if it does so, it will list the inodes moved there. > > So, in your case, nothing went to lost+found. > > Regards, > Barry. Great. Thanks a lot for your help :) Max. PS. I'm still missing working at SGI :| From owner-xfs@oss.sgi.com Sun Oct 7 22:07:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 22:07:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9857G9Z006651 for ; Sun, 7 Oct 2007 22:07:18 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 PAA03402; Mon, 8 Oct 2007 15:07:06 +1000 Date: Mon, 08 Oct 2007 15:07:48 +1000 To: "Nicholas Miell" , "Christoph Hellwig" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> <1191610338.2695.8.camel@entropy> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <1191610338.2695.8.camel@entropy> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13300 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sat, 06 Oct 2007 04:52:18 +1000, Nicholas Miell wrote: > On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote: >> [Adding -fsdevel because some of the things touched here might be of >> broader interest and Urban because his name is on nls_utf8.c] >> >> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >> > >> > On it's own, linux only provides case conversion for old-style >> > character sets - 8 bit sequences only. A lot of distos are >> > now defaulting to UTF-8 and Linux NLS stuff does not support >> > case conversion for any unicode sets. >> >> The lack of case tables in nls_utf8.c defintively seems odd to me. >> Urban, is there a reason for that? The only thing that comes to >> mind is that these tables might be quite large. >> > > Case conversion in Unicode is locale dependent. The legacy 8-bit > character encodings don't code for enough characters to run into the > ambiguities, so they can get away with fixed case conversion tables. > Unicode can't. Based on http://www.unicode.org/reports/tr21/tr21-5.html and http://www.unicode.org/Public/UNIDATA/CaseFolding.txt Doing case comparison using that table should cater for most circumstances except a few exeptions. It should be enough to satisfy a locale independant case-insensitive filesystem (ie. the C + F case folding option). Is normalization required after case-folding? What I read implies it is not necessary for this purpose (and would slow things down and bloat the code more). Now I suppose, it's just a question of a fixed table in the kernel driver (HFS+ style), or data stored in a special inode on-disk (NTFS style, shared refcounted in memory when the same). With the on-disk, the table can be generated from mkfs.xfs. Regards, Barry. From owner-xfs@oss.sgi.com Sun Oct 7 22:57:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 22:57:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l985vYqb015807 for ; Sun, 7 Oct 2007 22:57:37 -0700 Received: from [192.168.1.10] (c-67-183-84-122.hsd1.wa.comcast.net[67.183.84.122]) by comcast.net (sccrmhc14) with SMTP id <2007100805444901400fqhp3e>; Mon, 8 Oct 2007 05:44:53 +0000 Subject: Re: RFC: Case-insensitive support for XFS From: Nicholas Miell To: Barry Naujok Cc: Christoph Hellwig , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se In-Reply-To: References: <20071005154442.GA6432@infradead.org> <1191610338.2695.8.camel@entropy> Content-Type: text/plain; charset=UTF-8 Date: Sun, 07 Oct 2007 22:44:48 -0700 Message-Id: <1191822288.2694.10.camel@entropy> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-2.fc7.0.njm.1) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13301 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nmiell@comcast.net Precedence: bulk X-list: xfs On Mon, 2007-10-08 at 15:07 +1000, Barry Naujok wrote: > On Sat, 06 Oct 2007 04:52:18 +1000, Nicholas Miell > wrote: > > > On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote: > >> [Adding -fsdevel because some of the things touched here might be of > >> broader interest and Urban because his name is on nls_utf8.c] > >> > >> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: > >> > > >> > On it's own, linux only provides case conversion for old-style > >> > character sets - 8 bit sequences only. A lot of distos are > >> > now defaulting to UTF-8 and Linux NLS stuff does not support > >> > case conversion for any unicode sets. > >> > >> The lack of case tables in nls_utf8.c defintively seems odd to me. > >> Urban, is there a reason for that? The only thing that comes to > >> mind is that these tables might be quite large. > >> > > > > Case conversion in Unicode is locale dependent. The legacy 8-bit > > character encodings don't code for enough characters to run into the > > ambiguities, so they can get away with fixed case conversion tables. > > Unicode can't. > > Based on http://www.unicode.org/reports/tr21/tr21-5.html and > http://www.unicode.org/Public/UNIDATA/CaseFolding.txt > > Doing case comparison using that table should cater for most > circumstances except a few exeptions. It should be enough > to satisfy a locale independant case-insensitive filesystem > (ie. the C + F case folding option). > > Is normalization required after case-folding? What I read > implies it is not necessary for this purpose (and would > slow things down and bloat the code more). > > Now I suppose, it's just a question of a fixed table in the > kernel driver (HFS+ style), or data stored in a special > inode on-disk (NTFS style, shared refcounted in memory > when the same). With the on-disk, the table can be generated > from mkfs.xfs. You also have to decide whether to screw over people who speak Turkic languages and expect an 'I' to 'ı' mapping or everybody else who expect an 'I' to 'i' mapping. Although, if you're content in ignoring the kernel's native NLS case mapping tables (which expect a locale-independent 1-to-1 mapping), you could just uppercase everything and map both 'i' and 'ı' to 'I'. Then you have to decide whether things like 'ê' map to 'E' or 'Ê', which is also locale dependent. -- Nicholas Miell From owner-xfs@oss.sgi.com Sun Oct 7 23:16:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 23:16:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986FwMK019066 for ; Sun, 7 Oct 2007 23:16:00 -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 QAA05152; Mon, 8 Oct 2007 16:15:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 4CC4A58C38F1; Mon, 8 Oct 2007 16:15:54 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - kill superflous buffer locking Message-Id: <20071008061554.4CC4A58C38F1@chook.melbourne.sgi.com> Date: Mon, 8 Oct 2007 16:15:54 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13302 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs kill superflous buffer locking There is no need to lock any page in xfs_buf.c because we operate on our own address_space and all locking is covered by the buffer semaphore. If we ever switch back to main blockdeive address_space as suggested e.g. for fsblock with a similar scheme the locking will have to be totally revised anyway because the current scheme is neither correct nor coherent with itself. Signed-off-by: Christoph Hellwig Date: Mon Oct 8 16:14:29 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29845a fs/xfs/xfsidbg.c - 1.339 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.339&r2=text&tr2=1.338&f=h fs/xfs/linux-2.6/xfs_buf.h - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.245 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.245&r2=text&tr2=1.244&f=h - kill superflous buffer locking From owner-xfs@oss.sgi.com Sun Oct 7 23:17:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 23:17:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986H2mJ019374 for ; Sun, 7 Oct 2007 23:17:06 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 QAA05203; Mon, 8 Oct 2007 16:16:51 +1000 Date: Mon, 08 Oct 2007 16:17:53 +1000 To: "Nicholas Miell" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "Christoph Hellwig" , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> <1191610338.2695.8.camel@entropy> <1191822288.2694.10.camel@entropy> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1191822288.2694.10.camel@entropy> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13303 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 08 Oct 2007 15:44:48 +1000, Nicholas Miell wrote: > On Mon, 2007-10-08 at 15:07 +1000, Barry Naujok wrote: >> On Sat, 06 Oct 2007 04:52:18 +1000, Nicholas Miell >> wrote: >> >> > On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote: >> >> [Adding -fsdevel because some of the things touched here might be of >> >> broader interest and Urban because his name is on nls_utf8.c] >> >> >> >> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >> >> > >> >> > On it's own, linux only provides case conversion for old-style >> >> > character sets - 8 bit sequences only. A lot of distos are >> >> > now defaulting to UTF-8 and Linux NLS stuff does not support >> >> > case conversion for any unicode sets. >> >> >> >> The lack of case tables in nls_utf8.c defintively seems odd to me. >> >> Urban, is there a reason for that? The only thing that comes to >> >> mind is that these tables might be quite large. >> >> >> > >> > Case conversion in Unicode is locale dependent. The legacy 8-bit >> > character encodings don't code for enough characters to run into the >> > ambiguities, so they can get away with fixed case conversion tables. >> > Unicode can't. >> >> Based on http://www.unicode.org/reports/tr21/tr21-5.html and >> http://www.unicode.org/Public/UNIDATA/CaseFolding.txt >> >> Doing case comparison using that table should cater for most >> circumstances except a few exeptions. It should be enough >> to satisfy a locale independant case-insensitive filesystem >> (ie. the C + F case folding option). >> >> Is normalization required after case-folding? What I read >> implies it is not necessary for this purpose (and would >> slow things down and bloat the code more). >> >> Now I suppose, it's just a question of a fixed table in the >> kernel driver (HFS+ style), or data stored in a special >> inode on-disk (NTFS style, shared refcounted in memory >> when the same). With the on-disk, the table can be generated >> from mkfs.xfs. > > You also have to decide whether to screw over people who speak Turkic > languages and expect an 'I' to 'ı' mapping or everybody else who expect > an 'I' to 'i' mapping. Is there some way in the kernel, that I'm unaware of, in knowing what the user's current language and/or codepage locale is set to? The only thing I've found is the isocharset option that the other filesystems use or the default_nls_table() if one isn't specified. The default one seems to be a CONFIG option. > Although, if you're content in ignoring the kernel's native NLS case > mapping tables (which expect a locale-independent 1-to-1 mapping), you > could just uppercase everything and map both 'i' and 'ı' to 'I'. > > Then you have to decide whether things like 'ê' map to 'E' or 'Ê', which > is also locale dependent. Looking at case-folding, it would be generating lower case equivalent characters, nls->charset2lower. Barry. From owner-xfs@oss.sgi.com Sun Oct 7 23:21:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 23:21:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986LXPD020972 for ; Sun, 7 Oct 2007 23:21:35 -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 QAA05469; Mon, 8 Oct 2007 16:21:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 4D01158C38F1; Mon, 8 Oct 2007 16:21:30 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - kill XFS_INOBT_IS_FREE_DISK Message-Id: <20071008062130.4D01158C38F1@chook.melbourne.sgi.com> Date: Mon, 8 Oct 2007 16:21:30 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13304 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs kill XFS_INOBT_IS_FREE_DISK This macro is unused an all other acros in this family operate on native types, so we most likely won't grow a user either. Signed-off-by: Christoph Hellwig Date: Mon Oct 8 16:20:45 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29846a fs/xfs/xfs_ialloc_btree.h - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h - kill XFS_INOBT_IS_FREE_DISK From owner-xfs@oss.sgi.com Sun Oct 7 23:31:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 23:31:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986V7ne023066 for ; Sun, 7 Oct 2007 23:31: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 QAA05843; Mon, 8 Oct 2007 16:31:05 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 2E85558C38F1; Mon, 8 Oct 2007 16:31:05 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - lose xfs_hex_dump in favor of print_hex_dump Message-Id: <20071008063105.2E85558C38F1@chook.melbourne.sgi.com> Date: Mon, 8 Oct 2007 16:31:05 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13305 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs lose xfs_hex_dump in favor of print_hex_dump No need for xfs to have its own hex dumping routine now that the kernel has one. Signed-off-by: Eric Sandeen Date: Mon Oct 8 16:30:20 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Eric Sandeen Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29847a fs/xfs/xfs_error.c - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h fs/xfs/xfs_error.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h fs/xfs/support/debug.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h - lose xfs_hex_dump in favor of print_hex_dump From owner-xfs@oss.sgi.com Sun Oct 7 23:43:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 07 Oct 2007 23:43:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986hB48025626 for ; Sun, 7 Oct 2007 23:43: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 QAA06115; Mon, 8 Oct 2007 16:43:08 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id B7D9958C38F1; Mon, 8 Oct 2007 16:43:08 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 971186 - fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION Message-Id: <20071008064308.B7D9958C38F1@chook.melbourne.sgi.com> Date: Mon, 8 Oct 2007 16:43:08 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13306 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION XFS_IOC_GETVERSION, XFS_IOC_GETXFLAGS and XFS_IOC_SETXFLAGS all take a "long" which changes size between 32 and 64 bit platforms. So, the ioctl cmds that come in from a 32-bit app aren't as expected, for example on GETXFLAGS, unknown cmd fd(3) cmd(80046601){t:'f';sz:4} due to the size mismatch. So, use instead the 32-bit version of the commands for compat ioctls, and other than that it doesn't take any more manipulation. Also, for both native and compat versions, just define them to the values as defined in fs.h Signed-off-by: Eric Sandeen Date: Mon Oct 8 16:42:26 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-oss Inspected by: Signed-off-by: Eric Sandeen Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29849a fs/xfs/xfs_fs.h - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h fs/xfs/linux-2.6/xfs_ioctl32.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION From owner-xfs@oss.sgi.com Mon Oct 8 00:00:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 08 Oct 2007 00:00:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l986xtPx029058 for ; Sun, 7 Oct 2007 23:59:59 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 QAA06635; Mon, 8 Oct 2007 16:59:46 +1000 Date: Mon, 08 Oct 2007 17:00:58 +1000 To: "Nicholas Miell" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "Christoph Hellwig" , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> <1191610338.2695.8.camel@entropy> <1191822288.2694.10.camel@entropy> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1191822288.2694.10.camel@entropy> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4502/Sun Oct 7 18:52:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13307 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 08 Oct 2007 15:44:48 +1000, Nicholas Miell wrote: > You also have to decide whether to screw over people who speak Turkic > languages and expect an 'I' to 'ı' mapping or everybody else who expect > an 'I' to 'i' mapping. I suspect they would be used to the false case-insensitive match. I tested it on Windows XP with NTFS: Ä° (U+0130) did not match I or i or ı (U+0131). I also tested it with the Turkish language/keyboard set. Once it's set in a filesystem, the handling of it can't really be swapped back and forth either, otherwise, you may lose access to that file. There is no practical way that I can see of supporting this fully, even with using the NLS tables. The on-disk hashes have to remain consistent regardless of what language is specified. Barry. From owner-xfs@oss.sgi.com Mon Oct 8 17:31:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 08 Oct 2007 17:31:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l990VImo000355 for ; Mon, 8 Oct 2007 17:31:19 -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 KAA05296; Tue, 9 Oct 2007 10:31:14 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 2DEEB58C38F1; Tue, 9 Oct 2007 10:31:14 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 971597 - fsck.xfs doesn't verify that the device exists Message-Id: <20071009003114.2DEEB58C38F1@chook.melbourne.sgi.com> Date: Tue, 9 Oct 2007 10:31:14 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/4508/Mon Oct 8 14:22:13 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13308 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Make fsck.xfs verify the device exists Date: Tue Oct 9 10:30:48 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: wtucker@donobi.com,nathans@debian.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29851a xfsprogs/fsck/xfs_fsck.sh - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/fsck/xfs_fsck.sh.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Make fsck.xfs verify the device exists From owner-xfs@oss.sgi.com Tue Oct 9 00:29:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 00:29:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l997Tcix012667 for ; Tue, 9 Oct 2007 00:29:40 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15927; Tue, 9 Oct 2007 17:29:32 +1000 Message-ID: <470B2EEC.5020906@sgi.com> Date: Tue, 09 Oct 2007 17:34:04 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH V2] Ensure sync flushes all dirty data to disk] Content-Type: multipart/mixed; boundary="------------010900060503050001080908" X-Virus-Scanned: ClamAV 0.91.2/4513/Mon Oct 8 20:22:11 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13309 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------010900060503050001080908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [V2 adds a comment for dgc] In xfs_fs_sync_super() treat a sync the same as a filesystem freeze. This is needed to force the log to disk for inodes which are not marked dirty in the Linux inode (the inodes are marked dirty on completion of the log I/O) and so sync_inodes() will not flush them. In xfs_fs_write_inode() a synchronous flush will not get an EAGAIN from xfs_inode_flush() and if an asynchronous flush returns EAGAIN we should pass it on to the caller. If we get an error while flushing the inode then re-dirty it so we can try again later. Lachlan --------------010900060503050001080908 Content-Type: text/x-patch; name="sync.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sync.diff" --- fs/xfs/linux-2.6/xfs_super.c_1.400 2007-10-03 17:17:21.000000000 +1000 +++ fs/xfs/linux-2.6/xfs_super.c 2007-10-09 17:31:36.000000000 +1000 @@ -410,13 +410,12 @@ xfs_fs_write_inode( flags |= FLUSH_SYNC; } error = xfs_inode_flush(XFS_I(inode), flags); - if (error == EAGAIN) { - if (sync) - error = xfs_inode_flush(XFS_I(inode), - flags | FLUSH_LOG); - else - error = 0; - } + /* + * if we failed to write out the inode then mark + * it dirty again so we'll try again later. + */ + if (error) + mark_inode_dirty_sync(inode); return -error; } @@ -621,7 +620,19 @@ xfs_fs_sync_super( int error; int flags; - if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { + /* + * Treat a sync operation like a freeze. This is to work + * around a race in sync_inodes() which works in two phases + * - an asynchronous flush, which can write out an inode + * without waiting for file size updates to complete, and a + * synchronous flush, which wont do anything because the + * async flush removed the inode's dirty flag. Also + * sync_inodes() will not see any files that just have + * outstanding transactions to be flushed because we don't + * dirty the Linux inode until after the transaction I/O + * completes. + */ + if (wait || unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { /* * First stage of freeze - no more writers will make progress * now we are here, so we flush delwri and delalloc buffers @@ -632,7 +643,7 @@ xfs_fs_sync_super( */ flags = SYNC_DATA_QUIESCE; } else - flags = SYNC_FSDATA | (wait ? SYNC_WAIT : 0); + flags = SYNC_FSDATA; error = xfs_sync(mp, flags); sb->s_dirt = 0; --------------010900060503050001080908-- From owner-xfs@oss.sgi.com Tue Oct 9 01:54:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 01:54:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l998sHSr031928 for ; Tue, 9 Oct 2007 01:54: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 SAA18078; Tue, 9 Oct 2007 18:54:14 +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 l998sDdD56997502; Tue, 9 Oct 2007 18:54:14 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l998sC1m56988605; Tue, 9 Oct 2007 18:54:12 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 9 Oct 2007 18:54:12 +1000 From: David Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss Subject: Re: [PATCH V2] Ensure sync flushes all dirty data to disk] Message-ID: <20071009085412.GT23367404@sgi.com> References: <470B2EEC.5020906@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470B2EEC.5020906@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4513/Mon Oct 8 20:22:11 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13310 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 On Tue, Oct 09, 2007 at 05:34:04PM +1000, Lachlan McIlroy wrote: > [V2 adds a comment for dgc] > > In xfs_fs_sync_super() treat a sync the same as a filesystem freeze. > This is needed to force the log to disk for inodes which are not marked > dirty in the Linux inode (the inodes are marked dirty on completion of > the log I/O) and so sync_inodes() will not flush them. > > In xfs_fs_write_inode() a synchronous flush will not get an EAGAIN > from xfs_inode_flush() and if an asynchronous flush returns EAGAIN > we should pass it on to the caller. If we get an error while flushing > the inode then re-dirty it so we can try again later. Looks good now, Lachlan. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 9 03:01:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 03:01:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from mail.albertix.com ([213.152.197.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l99A1iQP011979 for ; Tue, 9 Oct 2007 03:01:46 -0700 Received: from [192.168.1.3] (ip-184-86.sn2.eutelia.it [83.211.184.86]) by mail.albertix.com (Postfix) with ESMTP id 49DACB9BA9 for ; Tue, 9 Oct 2007 11:38:56 +0200 (CEST) Message-ID: <470B4D3A.3060105@albertix.com> Disposition-Notification-To: "Alberto (albertix.com)" Date: Tue, 09 Oct 2007 11:43:22 +0200 From: "Alberto (albertix.com)" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Recover fs Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4513/Mon Oct 8 20:22:11 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13311 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alberto@albertix.com Precedence: bulk X-list: xfs Hi, This is my first question, sorry for my english. I have a very serious problem. I've demage (suppose) data on XFS RAID 0 disk, I'll try explain steps: before: n.2 sata hard disk monted on raid0 with xfs fs after: n.2 sata hard disk monted on raid0 with reiser fs Story: Server is gentoo based OS with TYAN MB with n.4 SATA onboard can be configured in Raid0, raid1, raid0+1. On another controller (PCI) was mounted another sata hd with OS. This hd was faulted, than I decide to mount 2 hd with raid1 configuration for better security. I've decided to move all same size disk to unique controller (on MB). When i moved this hard disks I've confused old disks with new and I've created new raid array on them. Old array was xfs fs and new one i've decided to make reiserfs. After creation of RAID, i've make "mkreiserfs /dev/md1", but not on each single hd Now I have new array (reiserfs) on disks witch before has very important data. When I saw my error, I've unmount array. With fdisk I see my sdc1 free space. In this exact moment i've lounched command: "xfs_repair -n /dev/sdc1". I'm desperade (aprox. crying) , on this disks was 3 years of work data (web, db, materials). It's possibility to recover this data (nothing else was writing after on disk disks) ??? . Pls help me If is possibilty, I promise to make 10 copies (for penitency). Alberto. ALBERTIX.COM di Starosta Wojciech Via Falcone e Borsellino, 11 47827 Villa Verucchio (RN) tel: +39 0541 1796799 fax: +39 0541 1791899 mob: +39 3388908888 PIVA: 03583890409 CIAA: RN-299344 CF: STRWCC67S06Z127F Banca: BANCA POPOLARE DELL'EMILIA ROMAGNA Filiale: VILLA VERUCCHIO ABI: 05387 CAB:68100 CC: 000001472060 CIN: B From owner-xfs@oss.sgi.com Tue Oct 9 18:24:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 18:24:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9A1OJ8q014082 for ; Tue, 9 Oct 2007 18:24:21 -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 LAA17499; Wed, 10 Oct 2007 11:24:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 524D258C38F1; Wed, 10 Oct 2007 11:24:16 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 971670 - Ensure sync flushes all dirty data to disk Message-Id: <20071010012416.524D258C38F1@chook.melbourne.sgi.com> Date: Wed, 10 Oct 2007 11:24:16 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4516/Tue Oct 9 10:31:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13312 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs avoid race in sync_inodes() that can fail to write out all dirty data In xfs_fs_sync_super() treat a sync the same as a filesystem freeze. This is needed to force the log to disk for inodes which are not marked dirty in the Linux inode (the inodes are marked dirty on completion of the log I/O) and so sync_inodes() will not flush them. In xfs_fs_write_inode() a synchronous flush will not get an EAGAIN from xfs_inode_flush() and if an asynchronous flush returns EAGAIN we should pass it on to the caller. If we get an error while flushing the inode then re-dirty it so we can try again later. Date: Wed Oct 10 11:22:49 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-preempt Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29860a fs/xfs/linux-2.6/xfs_super.c - 1.401 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.401&r2=text&tr2=1.400&f=h - avoid race in sync_inodes() that can fail to write out all dirty data From owner-xfs@oss.sgi.com Tue Oct 9 19:27:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 19:27:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9A2RmKN024806 for ; Tue, 9 Oct 2007 19:27:51 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 MAA19227; Wed, 10 Oct 2007 12:27:37 +1000 Date: Wed, 10 Oct 2007 12:27:57 +1000 To: "Nicholas Miell" Subject: Re: RFC: Case-insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: "Christoph Hellwig" , "xfs@oss.sgi.com" , linux-fsdevel@vger.kernel.org, urban@svenskatest.se Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20071005154442.GA6432@infradead.org> <1191610338.2695.8.camel@entropy> <1191822288.2694.10.camel@entropy> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <1191822288.2694.10.camel@entropy> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4516/Tue Oct 9 10:31:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13313 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 08 Oct 2007 15:44:48 +1000, Nicholas Miell wrote: > On Mon, 2007-10-08 at 15:07 +1000, Barry Naujok wrote: >> On Sat, 06 Oct 2007 04:52:18 +1000, Nicholas Miell >> wrote: >> >> > On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote: >> >> [Adding -fsdevel because some of the things touched here might be of >> >> broader interest and Urban because his name is on nls_utf8.c] >> >> >> >> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote: >> >> > >> >> > On it's own, linux only provides case conversion for old-style >> >> > character sets - 8 bit sequences only. A lot of distos are >> >> > now defaulting to UTF-8 and Linux NLS stuff does not support >> >> > case conversion for any unicode sets. >> >> >> >> The lack of case tables in nls_utf8.c defintively seems odd to me. >> >> Urban, is there a reason for that? The only thing that comes to >> >> mind is that these tables might be quite large. >> >> >> > >> > Case conversion in Unicode is locale dependent. The legacy 8-bit >> > character encodings don't code for enough characters to run into the >> > ambiguities, so they can get away with fixed case conversion tables. >> > Unicode can't. >> >> Based on http://www.unicode.org/reports/tr21/tr21-5.html and >> http://www.unicode.org/Public/UNIDATA/CaseFolding.txt >> >> Doing case comparison using that table should cater for most >> circumstances except a few exeptions. It should be enough >> to satisfy a locale independant case-insensitive filesystem >> (ie. the C + F case folding option). >> >> Is normalization required after case-folding? What I read >> implies it is not necessary for this purpose (and would >> slow things down and bloat the code more). >> >> Now I suppose, it's just a question of a fixed table in the >> kernel driver (HFS+ style), or data stored in a special >> inode on-disk (NTFS style, shared refcounted in memory >> when the same). With the on-disk, the table can be generated >> from mkfs.xfs. > > You also have to decide whether to screw over people who speak Turkic > languages and expect an 'I' to 'ı' mapping or everybody else who expect > an 'I' to 'i' mapping. I have had a thought about this. If the case table is stored on-disk like NTFS, then mkfs.xfs can specify whether to use Turkic I's or not. That guarantees consistent case folding for the filesystem. mkfs.xfs can default to a Turkic case table if the user's locale is tr/az and the "default case table" if not. mkfs.xfs will have to highlight this setting if the user specifies the generic case-insensitive option. mkfs.xfs should also allow the user to specify which of the case tables to use. Barry. From owner-xfs@oss.sgi.com Tue Oct 9 22:56:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 09 Oct 2007 22:56:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9A5urdG024362 for ; Tue, 9 Oct 2007 22:56:54 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IfUYw-0004di-3E for xfs@oss.sgi.com; Tue, 09 Oct 2007 22:56:54 -0700 Message-ID: <13129911.post@talk.nabble.com> Date: Tue, 9 Oct 2007 22:56:54 -0700 (PDT) From: cyjoyp To: xfs@oss.sgi.com Subject: please help MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: cyjoyp@gmail.com X-Virus-Scanned: ClamAV 0.91.2/4519/Tue Oct 9 20:26:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13314 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cyjoyp@gmail.com Precedence: bulk X-list: xfs Hi there, I am searching on what all value does di_mode of xfs_dinode_core_t (Core Inode) hold... If you could please help me. As i understand ,di_mode helps us to determine the type of file stored in the Inode.I just wanted to know what are the mode types of file,directory,links,etc... Instant reply is appreciated :-) -- View this message in context: http://www.nabble.com/please-help-tf4598771.html#a13129911 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Wed Oct 10 01:33:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 01:33:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9A8XElM027531 for ; Wed, 10 Oct 2007 01:33:17 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28706; Wed, 10 Oct 2007 18:33:11 +1000 Message-ID: <470C8F5B.90705@sgi.com> Date: Wed, 10 Oct 2007 18:37:47 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: review: use correct buffer flags when reading superblock Content-Type: multipart/mixed; boundary="------------060306000708010602050606" X-Virus-Scanned: ClamAV 0.91.2/4520/Tue Oct 9 22:11:07 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13315 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------060306000708010602050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When reading the superblock during log recovery we are not setting the correct buffer flags. Specifically we are not turning off flags we do not need such as XBF_ASYNC that is causing the synchronous xfs_iowait() to hang. We should also turn off XBF_WRITE and remove the buffer from the delay write queue just to be safe. Lachlan --------------060306000708010602050606 Content-Type: text/x-patch; name="xfs_getsb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_getsb.diff" --- fs/xfs/xfs_log_recover.c_1.329 2007-10-10 15:59:18.000000000 +1000 +++ fs/xfs/xfs_log_recover.c 2007-10-10 16:03:08.000000000 +1000 @@ -3824,7 +3824,10 @@ xlog_do_recover( */ bp = xfs_getsb(log->l_mp, 0); XFS_BUF_UNDONE(bp); + XFS_BUF_UNWRITE(bp); + XFS_BUF_UNDELAYWRITE(bp); XFS_BUF_READ(bp); + XFS_BUF_UNASYNC(bp); xfsbdstrat(log->l_mp, bp); if ((error = xfs_iowait(bp))) { xfs_ioerror_alert("xlog_do_recover", --------------060306000708010602050606-- From owner-xfs@oss.sgi.com Wed Oct 10 03:04:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 03:04:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9AA47gf008289 for ; Wed, 10 Oct 2007 03:04:10 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IfXxr-0002BO-L5; Wed, 10 Oct 2007 10:34:51 +0100 Date: Wed, 10 Oct 2007 10:34:51 +0100 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071010093451.GA7655@infradead.org> References: <470C8F5B.90705@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470C8F5B.90705@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13316 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 On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: > When reading the superblock during log recovery we are not setting > the correct buffer flags. Specifically we are not turning off flags > we do not need such as XBF_ASYNC that is causing the synchronous > xfs_iowait() to hang. We should also turn off XBF_WRITE and remove > the buffer from the delay write queue just to be safe. Where are these set up in the first time? AFAICS the buffer only written out by xfs_unmountfs_writesb, xfs_syncsub and xfs_trans_log_buf, and all these should only ever happen after log recovery has finished. From owner-xfs@oss.sgi.com Wed Oct 10 04:25:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 04:25:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9ABPBaA031977 for ; Wed, 10 Oct 2007 04:25: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 VAA03156; Wed, 10 Oct 2007 21:25:09 +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 l9ABP8dD58319028; Wed, 10 Oct 2007 21:25:09 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9ABP6sc58280706; Wed, 10 Oct 2007 21:25:06 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 10 Oct 2007 21:25:06 +1000 From: David Chinner To: Christoph Hellwig Cc: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071010112505.GH23367404@sgi.com> References: <470C8F5B.90705@sgi.com> <20071010093451.GA7655@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010093451.GA7655@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13317 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 On Wed, Oct 10, 2007 at 10:34:51AM +0100, Christoph Hellwig wrote: > On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: > > When reading the superblock during log recovery we are not setting > > the correct buffer flags. Specifically we are not turning off flags > > we do not need such as XBF_ASYNC that is causing the synchronous > > xfs_iowait() to hang. We should also turn off XBF_WRITE and remove > > the buffer from the delay write queue just to be safe. > > Where are these set up in the first time? AFAICS the buffer only written > out by xfs_unmountfs_writesb, xfs_syncsub and xfs_trans_log_buf, and all > these should only ever happen after log recovery has finished. It can also be written by xfsbufd when it has been bdwrite() or as a result of log tail pushing. And in the case of log recovery, if the superblock buffer is in a transaction that is recovered, xlog_recover_do_buffer_trans() will bdwrite() it after it has been recovered. Hence it will be on the delwri list. Once recovery is complete, xlog_do_recover() then calls XFS_bflush() to write them all out and wait for them. This is down by xfs_flush_buftarg() with the wait flag set, so the async flag on the buffer should be cleared. This is normally the case. The issue here is that when we openteh buftarg, we start up the xfsbufd which will periodically flush the delwri list asynchronously. If recovery takes long enough, it may flush the delwri list before recovery completes.In this case, instead of doing a sync write we'll get an async write being done and that leaves the XBF_ASYNC flag hanging around on the buffer at I/O completion. Because the superblock buffer is XBF_FS_MANAGED, it does not get torn down when it is clean and has no references, so the XBF_ASYNC flag never gets cleared unless the fs specifically clears it. If the superblock is then not recovered out of any further transactions during recovery after xfsbufd flushed it, the XBF_ASYNC flag remains set for the re-read that is issued in xlog_do_recover() and we hang..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 10 04:28:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 04:28:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9ABSPlt000445 for ; Wed, 10 Oct 2007 04:28: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 VAA03248; Wed, 10 Oct 2007 21:28: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 l9ABSLdD58190615; Wed, 10 Oct 2007 21:28:22 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9ABSL8e58346645; Wed, 10 Oct 2007 21:28:21 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 10 Oct 2007 21:28:21 +1000 From: David Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071010112821.GI23367404@sgi.com> References: <470C8F5B.90705@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470C8F5B.90705@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13318 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 On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: > When reading the superblock during log recovery we are not setting > the correct buffer flags. Specifically we are not turning off flags > we do not need such as XBF_ASYNC that is causing the synchronous > xfs_iowait() to hang. We should also turn off XBF_WRITE and remove > the buffer from the delay write queue just to be safe. We really don't need the removal of the write flags - the XFS_bflush() call above the xfs_getsb() call guarantees that they won't be set.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 10 07:33:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 07:33:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_05,SPF_HELO_PASS, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9AEXjww005798 for ; Wed, 10 Oct 2007 07:33:48 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 63BF7300E87B; Wed, 10 Oct 2007 16:33:46 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtK8HL37uxIx; Wed, 10 Oct 2007 16:33:46 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 4971C300E86F; Wed, 10 Oct 2007 16:33:46 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id B4B31F0AC231D; Wed, 10 Oct 2007 16:33:39 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 2A07A2579585; Wed, 10 Oct 2007 16:33:38 +0200 (CEST) Date: Wed, 10 Oct 2007 16:33:38 +0200 From: Louis-David Mitterrand To: xfs-dev , xfs-oss Subject: running xfs_repair on large partitions Message-ID: <20071010143337.GA2815@apartia.fr> Mail-Followup-To: xfs-dev , xfs-oss MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13319 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Hello, 1) it would be nice to have a way to know xfs_repair's version (-V ?), when using it from a rescue disk I'm never sure if I should get a newer one. 2) on a 32bit system, using xfsprogs version 2.9.0 , it seems xfs_repair will fail if its process exceeds 4G. Is that right? Is there a way to circumvent that limitation? Thanks, From owner-xfs@oss.sgi.com Wed Oct 10 08:15:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 08:15:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9AFFbOX019329 for ; Wed, 10 Oct 2007 08:15:39 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id C2E31301E6EC for ; Wed, 10 Oct 2007 17:15:38 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYHPGt2obwOz for ; Wed, 10 Oct 2007 17:15:38 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 8E6DB301CF07 for ; Wed, 10 Oct 2007 17:15:38 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id F3F6BF0AC231D for ; Wed, 10 Oct 2007 17:15:37 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id E025A2579585; Wed, 10 Oct 2007 17:15:37 +0200 (CEST) Date: Wed, 10 Oct 2007 17:15:37 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 Message-ID: <20071010151537.GA31573@apartia.fr> Mail-Followup-To: xfs@oss.sgi.com References: <20071004133302.GA5058@apartia.fr> <4704FA19.2080101@theendofthetunnel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4704FA19.2080101@theendofthetunnel.de> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13320 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Thu, Oct 04, 2007 at 04:35:05PM +0200, Hannes Dorbath wrote: > On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: >> What do you think about it ? > > Another thing, is there a special reason why you use DRBD 0.7.x branch? > AFAIK it will still deadlock with kernel 2.6.22. You are not running .22, > but if you upgrade you might have serious problems. You should really go > with DRBD 8.0.6 if you can. > After upgrading to 8.0.6 we had another xfs-related crash 4 days later. In desperation we are about to abandon xfs and convert this huge partition to ext3. Is there anyting else we could try before taking that step? Thanks, Oct 9 12:20:05 sargon/sargon kernel: SMP Oct 9 12:20:05 sargon/sargon kernel: CPU: 1 Oct 9 12:20:05 sargon/sargon kernel: EIP: 0060:[] Not tainted VLI Oct 9 12:20:05 sargon/sargon kernel: EFLAGS: 00010082 (2.6.22-dl380-g5-20070917 #1) Oct 9 12:20:05 sargon/sargon kernel: EIP is at free_block+0x67/0xfe Oct 9 12:20:05 sargon/sargon kernel: eax: a9b1fb46 ebx: 00000000 ecx: f65f4200 edx: d9741040 Oct 9 12:20:05 sargon/sargon kernel: esi: f65f4000 edi: f79e8f40 ebp: f79da680 esp: f797de5c Oct 9 12:20:05 sargon/sargon kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Oct 9 12:20:05 sargon/sargon kernel: Process kswapd0 (pid: 248, ti=f797c000 task=f7c22a90 task.ti=f797c000) Oct 9 12:20:05 sargon/sargon kernel: Stack: 00000000 00000000 0000001b 00000010 f79e9f14 0000001b 000000d8 f79da680 Oct 9 12:20:05 sargon/sargon kernel: f79e8f40 c015eb6e 00000000 f79e9ec0 f79e9ec0 00000246 cb353240 00000001 Oct 9 12:20:05 sargon/sargon kernel: c015eca7 cb353240 f52f2cf0 dbe833c0 c0210cd0 00000001 dbe833dc dbe833c0 Oct 9 12:20:05 sargon/sargon kernel: Call Trace: Oct 9 12:20:05 sargon/sargon kernel: [] cache_flusharray+0x70/0x96 Oct 9 12:20:05 sargon/sargon kernel: [] kmem_cache_free+0x7d/0x96 Oct 9 12:20:05 sargon/sargon kernel: [] xfs_finish_reclaim+0x121/0x129 Oct 9 12:20:05 sargon/sargon kernel: [] xfs_fs_clear_inode+0x8f/0xb1 Oct 9 12:20:05 sargon/sargon kernel: [] clear_inode+0xa2/0xf0 Oct 9 12:20:05 sargon/sargon kernel: [] dispose_list+0x46/0xc2 Oct 9 12:20:05 sargon/sargon kernel: [] shrink_icache_memory+0x18c/0x1b4 Oct 9 12:20:05 sargon/sargon kernel: [] shrink_slab+0xd9/0x138 Oct 9 12:20:05 sargon/sargon kernel: [] kswapd+0x297/0x3e8 Oct 9 12:20:05 sargon/sargon kernel: [] autoremove_wake_function+0x0/0x35 Oct 9 12:20:05 sargon/sargon kernel: [] kswapd+0x0/0x3e8 Oct 9 12:20:05 sargon/sargon kernel: [] kthread+0x38/0x5d Oct 9 12:20:05 sargon/sargon kernel: [] kthread+0x0/0x5d Oct 9 12:20:05 sargon/sargon kernel: [] kernel_thread_helper+0x7/0x10 Oct 9 12:20:05 sargon/sargon kernel: ======================= Oct 9 12:20:05 sargon/sargon kernel: Code: 00 3d 00 40 02 00 75 03 8b 52 0c 8b 02 84 c0 78 04 0f 0b eb fe 8b 72 1c 8b 54 24 28 8b 46 04 8b bc 95 88 00 00 00 8b 16 89 42 04 <89> 10 2b 4e 0c c7 06 00 01 10 00 c7 46 04 00 02 20 00 89 c8 f7 Oct 9 12:20:05 sargon/sargon kernel: EIP: [] free_block+0x67/0xfe SS:ESP 0068:f797de5c From owner-xfs@oss.sgi.com Wed Oct 10 10:41:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 10:41:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW, SUBJECT_FUZZY_TION autolearn=ham version=3.3.0-r574664 Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9AHewdf017743 for ; Wed, 10 Oct 2007 10:41:00 -0700 Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix1-g20.free.fr (Postfix) with ESMTP id 581631B55FA5 for ; Wed, 10 Oct 2007 19:15:04 +0200 (CEST) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id A49B332281E; Wed, 10 Oct 2007 19:14:58 +0200 (CEST) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp7-g19.free.fr (Postfix) with ESMTP id 46F613228B6; Wed, 10 Oct 2007 19:14:58 +0200 (CEST) Date: Wed, 10 Oct 2007 19:14:52 +0200 From: Emmanuel Florac To: Louis-David Mitterrand Cc: xfs-dev , xfs-oss Subject: Re: running xfs_repair on large partitions Message-ID: <20071010191452.1fdad848@galadriel.home> In-Reply-To: <20071010143337.GA2815@apartia.fr> References: <20071010143337.GA2815@apartia.fr> Organization: Moi. X-Mailer: Claws Mail 2.9.1 (GTK+ 2.8.20; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9AHf1df017756 X-archive-position: 13321 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@free.fr Precedence: bulk X-list: xfs Le Wed, 10 Oct 2007 16:33:38 +0200 vous écriviez: > 1) it would be nice to have a way to know xfs_repair's version > (-V ?), when using it from a rescue disk I'm never sure if I should > get a newer one. Did you try "xfs_repair -V" as you suggest? On my system, it replies with the version... > 2) on a 32bit system, using xfsprogs version 2.9.0 , it seems > xfs_repair will fail if its process exceeds 4G. Is that right? Is > there a way to circumvent that limitation? No, this is precisely what 32 bits mean. A 32 bits process can't address more than 2^32 bits, which is 4GB. However I'm surprised you have this problem; I've xfs_repaired up to 16TB filesystem (maximum manageable with a 32 bits kernel ) without such problem. -- Since we're all here, we must not be all there. -- Bob "Mountain" Beck From owner-xfs@oss.sgi.com Wed Oct 10 11:06:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 11:06:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_12, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.0-r574664 Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9AI6K5Y021912 for ; Wed, 10 Oct 2007 11:06:21 -0700 Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix2-g20.free.fr (Postfix) with ESMTP id 008091B89A28 for ; Wed, 10 Oct 2007 17:39:26 +0200 (CEST) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 7412E32287B; Wed, 10 Oct 2007 19:40:25 +0200 (CEST) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp7-g19.free.fr (Postfix) with ESMTP id 38F08322882; Wed, 10 Oct 2007 19:40:23 +0200 (CEST) Date: Wed, 10 Oct 2007 19:40:13 +0200 From: Emmanuel Florac To: "Alberto (albertix.com)" Cc: xfs@oss.sgi.com Subject: Re: Recover fs Message-ID: <20071010194013.32accad1@galadriel.home> In-Reply-To: <470B4D3A.3060105@albertix.com> References: <470B4D3A.3060105@albertix.com> Organization: Intellique X-Mailer: Claws Mail 2.9.1 (GTK+ 2.8.20; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 00:58:01 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9AI6M5Y021917 X-archive-position: 13322 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Tue, 09 Oct 2007 11:43:22 +0200 vous écriviez: > I'm desperade (aprox. crying) , on this disks was 3 years of work > data (web, db, materials). > It's possibility to recover this data (nothing else was writing > after on disk disks) ??? . Pls help me > If is possibilty, I promise to make 10 copies (for penitency). Alberto, apparently nobody cares to reply because 1) there's essentially nothing to do and 2) you deserved it. I'm sorry, but you really deserved it. Not backing up important data is plain stupid, but not backing up important data when moving it around is completely crazy. Now there is only one thing you may still try, but you won't get back everything, and it will be very long and very painful : scan the hard drive one byte at a time, and look for something you know. If you're looking for JPG files, look for JPG headers, or HTML headers, for databases there's probably some sort of identifiable header too. I did it one for a 12 TB X>FS that went booom (2.6.17 bug) containing only DV files. Here is the perl program I used. #!/usr/bin/perl use strict; use warnings; my ( $file ) = @ARGV; my $blocksize = 144000 ; my $lookupstring = pack "H*", "1F0700" ; my $regexp = qr/^(.*?)($lookupstring.*)$/s ; open ( my $raid, "< $file" ) or die "impossible d'ouvrir $file \n" ; { my $block ; my $offset = 0 ; my $nextblock = 0; my $testfile; my $outnumber = 0; seek $raid, $offset, 0 or die ; while ( my $readbytes = read $raid, $block, $blocksize ) { $offset += $readbytes ; if ( $block =~ m/$regexp/ ) { print "trouvé, fichier $outnumber offset $offset\n"; if ( $testfile ) { print $testfile $1; close $testfile or die "Peut pas fermer, $! "; undef $testfile ; $outnumber++; open $testfile, ">/mnt/destination/out". sprintf ("%09d", $ outnumber) . ".dv" or die "impossible d'écrire sur fichier $outnumber "; print $testfile $2 ; } else { print "OPEN\n"; open $testfile, ">/mnt/destination/out". sprintf ("%09d", $ outnumber) . ".dv" or die "impossible d'écrire sur fichier $outnumber "; print $testfile $2 ; } } else { if ( $testfile ) { print $testfile $block; } } if ($offset > 14293651161088 ) { print "fini....\n"; exit; } } } -- -------------------------------------------------- Emmanuel Florac www.intellique.com -------------------------------------------------- From owner-xfs@oss.sgi.com Wed Oct 10 14:57:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 14:57:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9ALvfFL031487 for ; Wed, 10 Oct 2007 14:57:43 -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 HAA22459; Thu, 11 Oct 2007 07:57:41 +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 l9ALvZdD59245054; Thu, 11 Oct 2007 07:57:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9ALvX8559375639; Thu, 11 Oct 2007 07:57:33 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 11 Oct 2007 07:57:33 +1000 From: David Chinner To: Emmanuel Florac Cc: Louis-David Mitterrand , xfs-dev , xfs-oss Subject: Re: running xfs_repair on large partitions Message-ID: <20071010215733.GL995458@sgi.com> References: <20071010143337.GA2815@apartia.fr> <20071010191452.1fdad848@galadriel.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20071010191452.1fdad848@galadriel.home> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4523/Wed Oct 10 11:30:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13323 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 On Wed, Oct 10, 2007 at 07:14:52PM +0200, Emmanuel Florac wrote: > Le Wed, 10 Oct 2007 16:33:38 +0200 vous écriviez: > > > 1) it would be nice to have a way to know xfs_repair's version (-V ?), > > when using it from a rescue disk I'm never sure if I should get a newer > > one. > > Did you try "xfs_repair -V" as you suggest? On my system, it replies with > the version... > > > 2) on a 32bit system, using xfsprogs version 2.9.0 , it seems xfs_repair > > will fail if its process exceeds 4G. Is that right? Is there a way to > > circumvent that limitation? > > No, this is precisely what 32 bits mean. A 32 bits process can't address > more than 2^32 bits, which is 4GB. I think it's 2GB for a process by default on linux, because the other 2GB is used by the kernel. The split is configurable IIRC. > However I'm surprised you have this > problem; I've xfs_repaired up to 16TB filesystem (maximum manageable with a > 32 bits kernel ) without such problem. Memory usage depends on the number of inodes in the filesystem as well. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 10 15:46:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 15:46:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9AMkj1K007425 for ; Wed, 10 Oct 2007 15:46:50 -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 IAA23819 for ; Thu, 11 Oct 2007 08:46:46 +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 l9AMkjdD59239010 for ; Thu, 11 Oct 2007 08:46:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9AMkiwZ59287659 for xfs@oss.sgi.com; Thu, 11 Oct 2007 08:46:44 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 11 Oct 2007 08:46:44 +1000 From: David Chinner To: xfs@oss.sgi.com Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 Message-ID: <20071010224644.GP995458@sgi.com> References: <20071004133302.GA5058@apartia.fr> <4704FA19.2080101@theendofthetunnel.de> <20071010151537.GA31573@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010151537.GA31573@apartia.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4525/Wed Oct 10 14:40:00 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13324 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 On Wed, Oct 10, 2007 at 05:15:37PM +0200, Louis-David Mitterrand wrote: > On Thu, Oct 04, 2007 at 04:35:05PM +0200, Hannes Dorbath wrote: > > On 04.10.2007 15:33, vindex+lists-xfs@apartia.org wrote: > >> What do you think about it ? > > > > Another thing, is there a special reason why you use DRBD 0.7.x branch? > > AFAIK it will still deadlock with kernel 2.6.22. You are not running .22, > > but if you upgrade you might have serious problems. You should really go > > with DRBD 8.0.6 if you can. > > > > After upgrading to 8.0.6 we had another xfs-related crash 4 days later. > In desperation we are about to abandon xfs and convert this huge > partition to ext3. Is there anyting else we could try before taking that > step? Yes, please turn on slab debugging so we can try to find the cause of this memory corruption. I expect the problem to be in DRBD as nobody else running XFS is reporting this problem. However, without running with the right debug options enabled we'll never get to the bottom of the problem. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 10 19:37:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 19:37:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9B2boik009420 for ; Wed, 10 Oct 2007 19:37:52 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00421; Thu, 11 Oct 2007 12:37:48 +1000 Message-ID: <470D8D91.903@sgi.com> Date: Thu, 11 Oct 2007 12:42:25 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock References: <470C8F5B.90705@sgi.com> <20071010112821.GI23367404@sgi.com> In-Reply-To: <20071010112821.GI23367404@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4526/Wed Oct 10 16:34:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13325 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: >> When reading the superblock during log recovery we are not setting >> the correct buffer flags. Specifically we are not turning off flags >> we do not need such as XBF_ASYNC that is causing the synchronous >> xfs_iowait() to hang. We should also turn off XBF_WRITE and remove >> the buffer from the delay write queue just to be safe. > > We really don't need the removal of the write flags - the XFS_bflush() > call above the xfs_getsb() call guarantees that they won't be set.... > It's not obvious though. It wasn't obvious that ASYNC was still set and look where that got us. From owner-xfs@oss.sgi.com Wed Oct 10 20:30:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 10 Oct 2007 20:30:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9B3Uf8R019427 for ; Wed, 10 Oct 2007 20:30:44 -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 NAA01720; Thu, 11 Oct 2007 13:30:41 +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 l9B3UedD59251905; Thu, 11 Oct 2007 13:30:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9B3UcGt59578367; Thu, 11 Oct 2007 13:30:38 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 11 Oct 2007 13:30:38 +1000 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071011033038.GW995458@sgi.com> References: <470C8F5B.90705@sgi.com> <20071010112821.GI23367404@sgi.com> <470D8D91.903@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <470D8D91.903@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4526/Wed Oct 10 16:34:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13326 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 On Thu, Oct 11, 2007 at 12:42:25PM +1000, Lachlan McIlroy wrote: > David Chinner wrote: > >On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: > >>When reading the superblock during log recovery we are not setting > >>the correct buffer flags. Specifically we are not turning off flags > >>we do not need such as XBF_ASYNC that is causing the synchronous > >>xfs_iowait() to hang. We should also turn off XBF_WRITE and remove > >>the buffer from the delay write queue just to be safe. > > > >We really don't need the removal of the write flags - the XFS_bflush() > >call above the xfs_getsb() call guarantees that they won't be set.... > > It's not obvious though. It wasn't obvious that ASYNC was still set > and look where that got us. Sure, but it is incorrect to have them set at that point - incorrect enough that it might cause corruption. That is, if they are set then the changes made during log replay have not been written to disk and we've got bigger problems than a hanging I/O to worry about.... So rather than clearing them, we should be asserting that the write flags are not set at all. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 11 00:19:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 00:19:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9B7J9Jg026898 for ; Thu, 11 Oct 2007 00:19:12 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA06478; Thu, 11 Oct 2007 17:19:07 +1000 Message-ID: <470DCF81.10704@sgi.com> Date: Thu, 11 Oct 2007 17:23:45 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock References: <470C8F5B.90705@sgi.com> <20071010112821.GI23367404@sgi.com> <470D8D91.903@sgi.com> <20071011033038.GW995458@sgi.com> In-Reply-To: <20071011033038.GW995458@sgi.com> Content-Type: multipart/mixed; boundary="------------090404040807010702010805" X-Virus-Scanned: ClamAV 0.91.2/4528/Wed Oct 10 22:04:31 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13327 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------090404040807010702010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Chinner wrote: > On Thu, Oct 11, 2007 at 12:42:25PM +1000, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Wed, Oct 10, 2007 at 06:37:47PM +1000, Lachlan McIlroy wrote: >>>> When reading the superblock during log recovery we are not setting >>>> the correct buffer flags. Specifically we are not turning off flags >>>> we do not need such as XBF_ASYNC that is causing the synchronous >>>> xfs_iowait() to hang. We should also turn off XBF_WRITE and remove >>>> the buffer from the delay write queue just to be safe. >>> We really don't need the removal of the write flags - the XFS_bflush() >>> call above the xfs_getsb() call guarantees that they won't be set.... >> It's not obvious though. It wasn't obvious that ASYNC was still set >> and look where that got us. > > Sure, but it is incorrect to have them set at that point - incorrect > enough that it might cause corruption. That is, if they are set > then the changes made during log replay have not been written to > disk and we've got bigger problems than a hanging I/O to worry > about.... > > So rather than clearing them, we should be asserting that the > write flags are not set at all. > New patch attached. --------------090404040807010702010805 Content-Type: text/x-patch; name="xfs_getsb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_getsb.diff" --- fs/xfs/xfs_log_recover.c_1.329 2007-10-10 15:59:18.000000000 +1000 +++ fs/xfs/xfs_log_recover.c 2007-10-11 15:03:00.000000000 +1000 @@ -3824,7 +3824,10 @@ xlog_do_recover( */ bp = xfs_getsb(log->l_mp, 0); XFS_BUF_UNDONE(bp); + ASSERT(!(XFS_BUF_ISWRITE(bp))); + ASSERT(!(XFS_BUF_ISDELAYWRITE(bp))); XFS_BUF_READ(bp); + XFS_BUF_UNASYNC(bp); xfsbdstrat(log->l_mp, bp); if ((error = xfs_iowait(bp))) { xfs_ioerror_alert("xlog_do_recover", --------------090404040807010702010805-- From owner-xfs@oss.sgi.com Thu Oct 11 00:36:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 00:36:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9B7aL8X029213 for ; Thu, 11 Oct 2007 00:36:24 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 89F733063911; Thu, 11 Oct 2007 09:36:22 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4528/Wed Oct 10 22:04:31 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf8OX+7t6aAW; Thu, 11 Oct 2007 09:36:22 +0200 (CEST) Received: from [192.168.0.31] (donald.lncsa.com [192.168.0.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sargon.lncsa.com (Postfix) with ESMTP id 748F630005B5; Thu, 11 Oct 2007 09:36:22 +0200 (CEST) Message-ID: <470DD275.9090602@lncsa.com> Date: Thu, 11 Oct 2007 09:36:21 +0200 From: Laurent CARON User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: David Chinner Subject: Re: Crash on 2.6.21.7 Vanilla + DRBD 0.7 References: <20071004133302.GA5058@apartia.fr> <4704FA19.2080101@theendofthetunnel.de> <20071010151537.GA31573@apartia.fr> <20071010224644.GP995458@sgi.com> In-Reply-To: <20071010224644.GP995458@sgi.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Status: Clean X-archive-position: 13328 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.com Precedence: bulk X-list: xfs David Chinner wrote: > Yes, please turn on slab debugging so we can try to find the cause > of this memory corruption. I expect the problem to be in DRBD as > nobody else running XFS is reporting this problem. However, without > running with the right debug options enabled we'll never get to > the bottom of the problem. Hi, Before installing a new kernel i've got a (little?) clue. The setup is as follows: The drbd partition is mounted to a generic mountpoint /dev/drbd1 on /data/web type xfs (rw) The subdirectories of /data/web are mounted (mount --bind) to another directory /data/web/var/www on /var/www type xfs (rw,bind) /data/web/var/lib/postgresql on /var/lib/postgresql type xfs (rw,bind) /data/web/var/lib/mysql on /var/lib/mysql type xfs (rw,bind) It seems I made a mistake here. mount -t xfs --bind /data/web/var/www /var/www instead of mount --bind /data/web/var/www /var/www Could this be 'THE' root of the problem (if the system then sees /var/www as a 'real' XFS filesystem and not a directory mounted over) ? Thanks Laurent From owner-xfs@oss.sgi.com Thu Oct 11 14:54:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 14:54:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9BLs03X013755 for ; Thu, 11 Oct 2007 14:54:03 -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 HAA25301; Fri, 12 Oct 2007 07:53:58 +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 l9BLrudD60781622; Fri, 12 Oct 2007 07:53:57 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9BLrrdg52430338; Fri, 12 Oct 2007 07:53:53 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 12 Oct 2007 07:53:53 +1000 From: David Chinner To: Andrew Clayton Cc: David Chinner , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071011215352.GX995458@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011151512.69f19419@zeus.pccl.info> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 13:02:20 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13329 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 On Thu, Oct 11, 2007 at 03:15:12PM +0100, Andrew Clayton wrote: > On Thu, 11 Oct 2007 11:01:39 +1000, David Chinner wrote: > > > So it's almost certainly pointing at an elevator or driver change, not an > > XFS change. > > heh, git bisect begs to differ :) > > 4c60658e0f4e253cf275f12b7c76bf128515a774 is first bad commit commit > 4c60658e0f4e253cf275f12b7c76bf128515a774 Author: David Chinner > Date: Sat Nov 11 18:05:00 2006 +1100 > > [XFS] Prevent a deadlock when xfslogd unpins inodes. Oh, of course - I failed to notice the significance of this loop in your test: while [foo]; do touch fred rm fred done The inode allocator keeps reusing the same inode. If the transaction that did the unlink has not hit the disk before we allocate the inode again, we have to force the log to get the unlink transaction to disk to get the xfs inode unpinned (i.e. able to be modified in memory again). It's the log force I/O that's introducing the latency. If we don't force the log, then we have a possible use-after free of the linux inode because of a fundamental mismatch between the XFS inode life cycle and the linux inode life cycle. The use-after free only occurs on large machines under heavy, heavy metadata load to many disks and filesystems (requires enough traffic to overload an xfslogd) and is very difficult to reproduce (large machine, lots of disks and 20-30 hours MTTF). I'll have a look at other ways to solve this problem, but it took 6 months to find a solution to the race in the first place so don't hold your breath. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 11 17:26:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 17:26:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9C0QG9h008280 for ; Thu, 11 Oct 2007 17:26:20 -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 KAA28794; Fri, 12 Oct 2007 10:26:17 +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 l9C0QFdD60759405; Fri, 12 Oct 2007 10:26:15 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9C0QDuk60855039; Fri, 12 Oct 2007 10:26:13 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 12 Oct 2007 10:26:13 +1000 From: David Chinner To: David Chinner Cc: Andrew Clayton , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071012002613.GL23367404@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011215352.GX995458@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 13:02:20 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13330 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 On Fri, Oct 12, 2007 at 07:53:53AM +1000, David Chinner wrote: > On Thu, Oct 11, 2007 at 03:15:12PM +0100, Andrew Clayton wrote: > > On Thu, 11 Oct 2007 11:01:39 +1000, David Chinner wrote: > > > > > So it's almost certainly pointing at an elevator or driver change, not an > > > XFS change. > > > > heh, git bisect begs to differ :) > > > > 4c60658e0f4e253cf275f12b7c76bf128515a774 is first bad commit commit > > 4c60658e0f4e253cf275f12b7c76bf128515a774 Author: David Chinner > > Date: Sat Nov 11 18:05:00 2006 +1100 > > > > [XFS] Prevent a deadlock when xfslogd unpins inodes. > > Oh, of course - I failed to notice the significance of > this loop in your test: > > while [foo]; do > touch fred > rm fred > done > > The inode allocator keeps reusing the same inode. If the > transaction that did the unlink has not hit the disk before we > allocate the inode again, we have to force the log to get the unlink > transaction to disk to get the xfs inode unpinned (i.e. able to be > modified in memory again). > > It's the log force I/O that's introducing the latency. > > If we don't force the log, then we have a possible use-after free > of the linux inode because of a fundamental mismatch between > the XFS inode life cycle and the linux inode life cycle. The > use-after free only occurs on large machines under heavy, heavy > metadata load to many disks and filesystems (requires enough > traffic to overload an xfslogd) and is very difficult to > reproduce (large machine, lots of disks and 20-30 hours MTTF). > > I'll have a look at other ways to solve this problem, but it > took 6 months to find a solution to the race in the first place > so don't hold your breath. You can breath again. Here's a test patch (warning - may harm kittens - not fully tested or verified) that solves both the use-after-free issue (by avoiding it altogether) as well the unlink/create latency because the log force is no longer there. (yay! xfsqa test 016 passes again ;) It does have other possible side effects triggering extra log forces elsewhere on inode writeback and affects sync behaviour so it's only a proof of concept at this point. The latency output looks like: open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000281> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000184> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000188> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000182> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000225> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000182> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000185> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000405> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000224> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000199> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000163> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000145> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.817704> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000148> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000143> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000154> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000147> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000158> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000144> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000379> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000151> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000190> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000191> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000150> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.797099> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000139> open("/mnt/scratch/testfile", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0600) = 3 <0.000163> So we still see some operations show high latency - that will most likely be due to the allocation transaction filling a log buffer and pushing it to disk, then having to wait because I/O is in progress on all other log buffers. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_iops.c | 16 ++++++++++++++++ fs/xfs/xfs_iget.c | 18 ------------------ fs/xfs/xfs_inode.c | 34 +--------------------------------- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_inode_item.c | 5 +++++ 5 files changed, 23 insertions(+), 51 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-10-02 16:01:47.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-10-12 09:54:12.466194814 +1000 @@ -71,6 +71,22 @@ xfs_synchronize_atime( } /* + * If the linux inode exists, mark it dirty. + * Used when commiting a dirty inode into a transaction so that + * the inode will get written back by the linux code + */ +void +xfs_mark_inode_dirty_sync( + xfs_inode_t *ip) +{ + bhv_vnode_t *vp; + + vp = XFS_ITOV_NULL(ip); + if (vp) + mark_inode_dirty_sync(vn_to_inode(vp)); +} + +/* * Change the requested timestamp in the given inode. * We don't lock across timestamp updates, and we don't log them but * we do record the fact that there is dirty information in core. Index: 2.6.x-xfs-new/fs/xfs/xfs_iget.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iget.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_iget.c 2007-10-12 09:58:38.263910771 +1000 @@ -140,27 +140,9 @@ again: return ENOENT; } - /* - * There may be transactions sitting in the - * incore log buffers or being flushed to disk - * at this time. We can't clear the - * XFS_IRECLAIMABLE flag until these - * transactions have hit the disk, otherwise we - * will void the guarantee the flag provides - * xfs_iunpin() - */ - if (xfs_ipincount(ip)) { - read_unlock(&pag->pag_ici_lock); - xfs_log_force(mp, 0, - XFS_LOG_FORCE|XFS_LOG_SYNC); - XFS_STATS_INC(xs_ig_frecycle); - goto again; - } - xfs_itrace_exit_tag(ip, "xfs_iget.alloc"); XFS_STATS_INC(xs_ig_found); - xfs_iflags_clear(ip, XFS_IRECLAIMABLE); read_unlock(&pag->pag_ici_lock); Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.c 2007-10-11 09:53:53.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.c 2007-10-12 09:56:49.721912637 +1000 @@ -2807,40 +2807,8 @@ xfs_iunpin( { ASSERT(atomic_read(&ip->i_pincount) > 0); - if (atomic_dec_and_lock(&ip->i_pincount, &ip->i_flags_lock)) { - - /* - * If the inode is currently being reclaimed, the link between - * the bhv_vnode and the xfs_inode will be broken after the - * XFS_IRECLAIM* flag is set. Hence, if these flags are not - * set, then we can move forward and mark the linux inode dirty - * knowing that it is still valid as it won't freed until after - * the bhv_vnode<->xfs_inode link is broken in xfs_reclaim. The - * i_flags_lock is used to synchronise the setting of the - * XFS_IRECLAIM* flags and the breaking of the link, and so we - * can execute atomically w.r.t to reclaim by holding this lock - * here. - * - * However, we still need to issue the unpin wakeup call as the - * inode reclaim may be blocked waiting for the inode to become - * unpinned. - */ - - if (!__xfs_iflags_test(ip, XFS_IRECLAIM|XFS_IRECLAIMABLE)) { - bhv_vnode_t *vp = XFS_ITOV_NULL(ip); - struct inode *inode = NULL; - - BUG_ON(vp == NULL); - inode = vn_to_inode(vp); - BUG_ON(inode->i_state & I_CLEAR); - - /* make sync come back and flush this inode */ - if (!(inode->i_state & (I_NEW|I_FREEING))) - mark_inode_dirty_sync(inode); - } - spin_unlock(&ip->i_flags_lock); + if (atomic_dec_and_test(&ip->i_pincount)) wake_up(&ip->i_ipin_wait); - } } /* Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.h 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.h 2007-10-12 10:00:10.979948827 +1000 @@ -532,6 +532,7 @@ xfs_fsize_t xfs_file_last_byte(xfs_inode void xfs_lock_inodes(xfs_inode_t **, int, int, uint); void xfs_synchronize_atime(xfs_inode_t *); +void xfs_mark_inode_dirty_sync(xfs_inode_t *); xfs_bmbt_rec_host_t *xfs_iext_get_ext(xfs_ifork_t *, xfs_extnum_t); void xfs_iext_insert(xfs_ifork_t *, xfs_extnum_t, xfs_extnum_t, Index: 2.6.x-xfs-new/fs/xfs/xfs_inode_item.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode_item.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode_item.c 2007-10-12 09:54:18.053474268 +1000 @@ -274,6 +274,11 @@ xfs_inode_item_format( */ xfs_synchronize_atime(ip); + /* + * make sure the linux inode is dirty + */ + xfs_mark_inode_dirty_sync(ip); + vecp->i_addr = (xfs_caddr_t)&ip->i_d; vecp->i_len = sizeof(xfs_dinode_core_t); XLOG_VEC_SET_TYPE(vecp, XLOG_REG_TYPE_ICORE); From owner-xfs@oss.sgi.com Thu Oct 11 18:53:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 18:53:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9C1rR49019351 for ; Thu, 11 Oct 2007 18:53: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 LAA01123; Fri, 12 Oct 2007 11:53:24 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id DF38258C38F1; Fri, 12 Oct 2007 11:53:23 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 971603 - Turn off XBF_ASYNC flag before re-reading superblock. Message-Id: <20071012015323.DF38258C38F1@chook.melbourne.sgi.com> Date: Fri, 12 Oct 2007 11:53:23 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 13:02:20 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13331 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Turn off XBF_ASYNC flag before re-reading superblock. Date: Fri Oct 12 11:52:21 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-getsb Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29871a fs/xfs/xfs_log_recover.c - 1.330 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.330&r2=text&tr2=1.329&f=h - Turn off XBF_ASYNC flag before re-reading superblock. From owner-xfs@oss.sgi.com Thu Oct 11 23:14:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 11 Oct 2007 23:14:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9C6DvJk025589 for ; Thu, 11 Oct 2007 23:14:01 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06730; Fri, 12 Oct 2007 16:13:54 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 4522F30E6A4C; Fri, 12 Oct 2007 16:13:54 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - fix up out-of-tree xfs builds Message-Id: <20071012061354.4522F30E6A4C@linuxbuild.melbourne.sgi.com> Date: Fri, 12 Oct 2007 16:13:54 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4530/Thu Oct 11 13:02:20 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13332 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Fix up xfs out-of-tree builds. (a.k.a. external modules) Change -I include directives to find headers in the out-of-tree spot. This allows a directory containing only xfs files to be built as: # make -C /path/to/kernel M=`pwd` Signed-off-by: Eric Sandeen Date: Fri Oct 12 16:13:18 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29878a fs/xfs/Makefile - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - fix up out-of-tree xfs builds. fs/xfs/quota/Makefile - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/Makefile.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - fix up out-of-tree xfs builds. fs/xfs/dmapi/Makefile - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/Makefile.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h - fix up out-of-tree xfs builds. From owner-xfs@oss.sgi.com Fri Oct 12 05:38:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 12 Oct 2007 05:39:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20,DATE_IN_PAST_03_06, J_CHICKENPOX_82 autolearn=no version=3.3.0-r574664 Received: from sas3.stonline.sk (sas3.t-com.sk [213.81.152.136]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9CCciQ2011504 for ; Fri, 12 Oct 2007 05:38:46 -0700 Received: from localhost (localhost) by sas3.stonline.sk (8.13.6/8.13.1) id l9C7caQ1015193; Fri, 12 Oct 2007 09:38:36 +0200 Date: Fri, 12 Oct 2007 09:38:36 +0200 From: Mail Delivery Subsystem Message-Id: <200710120738.l9C7caQ1015193@sas3.stonline.sk> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l9C7caQ1015193.1192174716/sas3.stonline.sk" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Virus-Scanned: ClamAV 0.91.2/4532/Fri Oct 12 02:00:52 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13333 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@sas3.t-com.sk Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l9C7caQ1015193.1192174716/sas3.stonline.sk The original message was received at Fri, 12 Oct 2007 09:38:36 +0200 from [192.168.133.65] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 unknown or illegal alias: ludus@stonline.sk) ----- Transcript of session follows ----- ... while talking to mta-in.stonline.sk.: >>> DATA <<< 550 5.1.1 unknown or illegal alias: ludus@stonline.sk 550 5.1.1 ... User unknown <<< 554 5.5.0 No recipients have been specified. --l9C7caQ1015193.1192174716/sas3.stonline.sk Content-Type: message/delivery-status Reporting-MTA: dns; sas3.stonline.sk Received-From-MTA: DNS; [192.168.133.65] Arrival-Date: Fri, 12 Oct 2007 09:38:36 +0200 Final-Recipient: RFC822; ludus@stonline.sk Action: failed Status: 5.1.1 Remote-MTA: DNS; mta-in.stonline.sk Diagnostic-Code: SMTP; 550 5.1.1 unknown or illegal alias: ludus@stonline.sk Last-Attempt-Date: Fri, 12 Oct 2007 09:38:36 +0200 --l9C7caQ1015193.1192174716/sas3.stonline.sk Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from av-1.stonline.sk ([192.168.133.65]) by sas3.stonline.sk (8.13.6/8.13.1) with ESMTP id l9C7caQ0015193 for ; Fri, 12 Oct 2007 09:38:36 +0200 Received: from smtp.t-com.sk ([192.168.133.65]) by av-1.stonline.sk (8.13.6/8.13.5) with ESMTP id l9C7cZXh017675 for ; Fri, 12 Oct 2007 09:38:36 +0200 Received: from oss.sgi.com (dup-dynamic-202.213-81-198.t-com.sk [213.81.198.202]) by smtp1.stonline.sk (STOnline ESMTP Server) with ESMTP id <0JPS00MZ3FW3K3@smtp1.stonline.sk> for ludus@stonline.sk; Fri, 12 Oct 2007 09:38:35 +0200 (CEST) Date: Fri, 12 Oct 2007 09:37:35 +0200 From: xfs@oss.sgi.com Subject: [NOD32: deleted] Ludus@stonline.sk To: ludus@stonline.sk Message-id: <0JPS00MZ6FW4K3@smtp1.stonline.sk> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_g4H/yBzvqTjJtmLKQi8bVg)" X-Priority: 3 X-MSMail-priority: Normal This is a multi-part message in MIME format. --Boundary_(ID_g4H/yBzvqTjJtmLKQi8bVg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear user of stonline.sk, We have detected that your email account was used to send a large amount of unsolicited email messages during the last week. Probably, your computer was infected by a recent virus and now contains a trojan proxy server. Please follow the instructions in order to keep your computer safe. Have a nice day, stonline.sk technical support team. --- Skontrolované antivírovým programom NOD32 dgjhjkj.zip - Win32/Mydoom.R worm - deleted dgjhjkj.zip -> ZIP -> dgjhjkj.zip - Win32/Mydoom.R worm - error while Cleaning - operation unavailable for this type of object - error while Deleting - operation unavailable for this type of object - was a part of the deleted object --Boundary_(ID_g4H/yBzvqTjJtmLKQi8bVg) Content-Type: text/plain X-Removed: Removed by NOD32 Antivirus System --Boundary_(ID_g4H/yBzvqTjJtmLKQi8bVg)-- --l9C7caQ1015193.1192174716/sas3.stonline.sk-- From owner-xfs@oss.sgi.com Fri Oct 12 08:09:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 12 Oct 2007 08:09:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from frodo.openenterprise.co.uk (ns1.openenterprise.co.uk [81.21.68.157]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9CF9IYQ009100 for ; Fri, 12 Oct 2007 08:09:20 -0700 Received: (qmail 3910 invoked from network); 12 Oct 2007 08:02:37 -0000 Received: from unknown (HELO [172.16.1.10]) ([81.187.75.195]) (envelope-sender ) by frodo.openenterprise.co.uk (qmail-ldap-1.03) with SMTP for ; 12 Oct 2007 08:02:37 -0000 Message-ID: <470F2A1E.9070503@openenterprise.co.uk> Date: Fri, 12 Oct 2007 09:02:38 +0100 From: Nick Gregory User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Repeated XFS Crash on x86_64 fiesty Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4533/Fri Oct 12 03:59:29 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13334 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nick@openenterprise.co.uk Precedence: bulk X-list: xfs Hi, I run a number of x86_64 ubuntu feisty (2.6.20-16-server) systems. Each has a near identical hardware spec i.e. the systems have a large (>6TB) xfs storage partition sat on top of a raid 6 array (using the Areca ARC-1160). Over the last couple of months one system has has its xfs filesystem crash on a semi frequent basis (1-2 times a week). Googling around the error it first seemed to be memory related so I've done a swap for a some new ecc memory - unfortunately the problem persists. The filesystem is reasonable active but the issue doesn't seem to be load related as the issue seems to occur at random times of the day. Can anyone give me any insight on the best place to start looking to track down the issue? Thanks in advance Nick XFS Crash dmesg: [44537.156249] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff8824e188 [44537.156321] [44537.156321] Call Trace: [44537.156391] [] :xfs:xfs_free_ag_extent+0x1b2/0x700 [44537.156416] [] :xfs:xfs_free_extent+0xc8/0x110 [44537.156443] [] :xfs:xfs_bmap_finish+0x102/0x190 [44537.156482] [] :xfs:xfs_itruncate_finish+0x1ac/0x300 [44537.156513] [] :xfs:xfs_setattr+0x8a6/0xf30 [44537.156557] [] :xfs:xfs_vn_setattr+0x143/0x190 [44537.156578] [] notify_change+0x164/0x330 [44537.156589] [] do_truncate+0x4e/0x70 [44537.156597] [] permission+0xca/0x140 [44537.156602] [] may_open+0x1e9/0x260 [44537.156609] [] open_namei+0x2a8/0x680 [44537.156613] [] cp_new_stat+0xe7/0x100 [44537.156617] [] autoremove_wake_function+0x0/0x30 [44537.156625] [] do_filp_open+0x1c/0x40 [44537.156658] [] do_sys_open+0x5a/0x100 [44537.156666] [] system_call+0x7e/0x83 [44537.156675] [44537.156685] xfs_force_shutdown(sda3,0x8) called from line 4272 of file fs/xfs/xfs_bmap.c. Return address = 0xffffffff8825c9be [44537.157614] Filesystem "sda3": Corruption of in-memory data detected. Shutting down filesystem: sda3 [44537.157664] Please umount the filesystem, and rectify the problem(s) On remount of the file system: [45035.275936] xfs_force_shutdown(sda3,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff8829bf3a [45035.275948] xfs_force_shutdown(sda3,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff8829bf3a [45039.698366] XFS mounting filesystem sda3 [45039.822294] Starting XFS recovery on filesystem: sda3 (logdev: internal) [45040.330263] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff8824e188 [45040.330319] [45040.330320] Call Trace: [45040.330358] [] :xfs:xfs_free_ag_extent+0x1b2/0x700 [45040.330382] [] :xfs:xfs_free_extent+0xc8/0x110 [45040.330413] [] :xfs:xlog_recover_finish+0x1be/0x2d0 [45040.330440] [] :xfs:xfs_mountfs+0xa77/0xca0 [45040.330451] [] generic_unplug_device+0x0/0x30 [45040.330457] [] _atomic_dec_and_lock+0x42/0x80 [45040.330481] [] :xfs:xfs_mount+0x997/0xa80 [45040.330503] [] :xfs:xfs_fs_fill_super+0x98/0x230 [45040.330511] [] __down_write_nested+0x12/0xb0 [45040.330516] [] strlcpy+0x4e/0x80 [45040.330523] [] get_filesystem+0x12/0x40 [45040.330528] [] sget+0x3bf/0x3e0 [45040.330533] [] set_bdev_super+0x0/0x10 [45040.330541] [] get_sb_bdev+0x11f/0x190 [45040.330559] [] :xfs:xfs_fs_fill_super+0x0/0x230 [45040.330570] [] vfs_kern_mount+0xc6/0x170 [45040.330579] [] do_kern_mount+0x4a/0x80 [45040.330586] [] do_mount+0x6f9/0x7a0 [45040.330592] [] __handle_mm_fault+0x668/0xab0 [45040.330601] [] link_path_walk+0xd0/0xf0 [45040.330608] [] __up_read+0x21/0xb0 [45040.330614] [] do_page_fault+0x4b9/0x890 [45040.330623] [] __handle_mm_fault+0x443/0xab0 [45040.330629] [] zone_statistics+0x34/0x80 [45040.330652] [] __get_free_pages+0x1b/0x40 [45040.330661] [] sys_mount+0x9b/0x100 [45040.330670] [] system_call+0x7e/0x83 [45040.330680] [45040.365771] Ending XFS recovery on filesystem: sda3 (logdev: internal) From owner-xfs@oss.sgi.com Fri Oct 12 09:44:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 12 Oct 2007 09:44:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from smtp.aaisp.net.uk (smtp.aaisp.net.uk [81.187.81.51]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9CGiRFD000597 for ; Fri, 12 Oct 2007 09:44:28 -0700 Received: from zeus.pccl.info ([81.2.82.67]) by smtp.aaisp.net.uk with esmtp (Exim 4.62) (envelope-from ) id 1IgIoH-0004Br-8S; Fri, 12 Oct 2007 12:36:05 +0100 Date: Fri, 12 Oct 2007 12:36:01 +0100 From: Andrew Clayton To: David Chinner Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071012123601.291fee8a@zeus.pccl.info> In-Reply-To: <20071012002613.GL23367404@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4533/Fri Oct 12 03:59:29 2007 on oss.sgi.com X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/4532/Fri Oct 12 10:00:52 2007, by smtp.aaisp.net.uk) X-Virus-Status: Clean X-archive-position: 13335 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrew@digital-domain.net Precedence: bulk X-list: xfs On Fri, 12 Oct 2007 10:26:13 +1000, David Chinner wrote: > You can breath again. Here's a test patch (warning - may harm heh > kittens - not fully tested or verified) that solves both > the use-after-free issue (by avoiding it altogether) as well the > unlink/create latency because the log force is no longer there. > > (yay! xfsqa test 016 passes again ;) > > It does have other possible side effects triggering extra > log forces elsewhere on inode writeback and affects sync behaviour > so it's only a proof of concept at this point. What kernel is that against?. I got rejects with 2.6.23 However I tried a 2.6.18 on the file server and ran my test, it didn't show the problem. I then made a 2.6.23 but with the patch from my git bisect reverted. Doing the test with that kernel, while writing a 1GB file I saw only one > 1 second latency (1.2) and only a few ~ 0.5 second latencies. However over the longer term I'm still seeing latencies > 1 second. Just leaving my strace test running (no dd) on the raid filesystem I see the latencies come when the raid5 stripe cache fills up. So I think I'm perhaps seeing another problem here. Running the strace (again no dd) on the system disk (not raided) I'm not seeing any latencies. In fact the latencies on the raid array seem to be generally greater than the system disk (all identical disks, all XFS). raid array open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.122943> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.021620> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.014963> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.023264> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.011368> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.002561> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.012623> system disk open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000190> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000039> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000191> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000268> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000188> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000233> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000279> Maybe that's to be expected? > Cheers, > > Dave. Thanks for looking at this. Andrew From owner-xfs@oss.sgi.com Fri Oct 12 12:52:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 12 Oct 2007 12:52:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9CJqKLS001946 for ; Fri, 12 Oct 2007 12:52:23 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 0CA411C000264; Fri, 12 Oct 2007 15:52:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 087AD400FCB3; Fri, 12 Oct 2007 15:52:22 -0400 (EDT) Date: Fri, 12 Oct 2007 15:52:22 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Nick Gregory cc: xfs@oss.sgi.com Subject: Re: Repeated XFS Crash on x86_64 fiesty In-Reply-To: <470F2A1E.9070503@openenterprise.co.uk> Message-ID: References: <470F2A1E.9070503@openenterprise.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4533/Fri Oct 12 03:59:29 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13336 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 Have you run memtest86? Have you checked the CPU? Is it an AMD64 CPU where the memory controller is onboard (and .. if damaged/overheating) could cause problems with the memory? On Fri, 12 Oct 2007, Nick Gregory wrote: > Hi, > > I run a number of x86_64 ubuntu feisty (2.6.20-16-server) systems. Each has a > near identical hardware spec i.e. the systems have a large (>6TB) xfs storage > partition sat on top of a raid 6 array (using the Areca ARC-1160). > > Over the last couple of months one system has has its xfs filesystem crash on > a semi frequent basis (1-2 times a week). Googling around the error it first > seemed to be memory related so I've done a swap for a some new ecc memory - > unfortunately the problem persists. > > The filesystem is reasonable active but the issue doesn't seem to be load > related as the issue seems to occur at random times of the day. > > Can anyone give me any insight on the best place to start looking to track > down the issue? > > Thanks in advance > > Nick > > XFS Crash dmesg: > > [44537.156249] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of > file fs/xfs/xfs_alloc.c. Caller 0xffffffff8824e188 > [44537.156321] > [44537.156321] Call Trace: > [44537.156391] [] :xfs:xfs_free_ag_extent+0x1b2/0x700 > [44537.156416] [] :xfs:xfs_free_extent+0xc8/0x110 > [44537.156443] [] :xfs:xfs_bmap_finish+0x102/0x190 > [44537.156482] [] :xfs:xfs_itruncate_finish+0x1ac/0x300 > [44537.156513] [] :xfs:xfs_setattr+0x8a6/0xf30 > [44537.156557] [] :xfs:xfs_vn_setattr+0x143/0x190 > [44537.156578] [] notify_change+0x164/0x330 > [44537.156589] [] do_truncate+0x4e/0x70 > [44537.156597] [] permission+0xca/0x140 > [44537.156602] [] may_open+0x1e9/0x260 > [44537.156609] [] open_namei+0x2a8/0x680 > [44537.156613] [] cp_new_stat+0xe7/0x100 > [44537.156617] [] autoremove_wake_function+0x0/0x30 > [44537.156625] [] do_filp_open+0x1c/0x40 > [44537.156658] [] do_sys_open+0x5a/0x100 > [44537.156666] [] system_call+0x7e/0x83 > [44537.156675] > [44537.156685] xfs_force_shutdown(sda3,0x8) called from line 4272 of file > fs/xfs/xfs_bmap.c. Return address = 0xffffffff8825c9be > [44537.157614] Filesystem "sda3": Corruption of in-memory data detected. > Shutting down filesystem: sda3 > [44537.157664] Please umount the filesystem, and rectify the problem(s) > > > On remount of the file system: > > [45035.275936] xfs_force_shutdown(sda3,0x1) called from line 424 of file > fs/xfs/xfs_rw.c. Return address = 0xffffffff8829bf3a > [45035.275948] xfs_force_shutdown(sda3,0x1) called from line 424 of file > fs/xfs/xfs_rw.c. Return address = 0xffffffff8829bf3a > [45039.698366] XFS mounting filesystem sda3 > [45039.822294] Starting XFS recovery on filesystem: sda3 (logdev: internal) > [45040.330263] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of > file fs/xfs/xfs_alloc.c. Caller 0xffffffff8824e188 > [45040.330319] > [45040.330320] Call Trace: > [45040.330358] [] :xfs:xfs_free_ag_extent+0x1b2/0x700 > [45040.330382] [] :xfs:xfs_free_extent+0xc8/0x110 > [45040.330413] [] :xfs:xlog_recover_finish+0x1be/0x2d0 > [45040.330440] [] :xfs:xfs_mountfs+0xa77/0xca0 > [45040.330451] [] generic_unplug_device+0x0/0x30 > [45040.330457] [] _atomic_dec_and_lock+0x42/0x80 > [45040.330481] [] :xfs:xfs_mount+0x997/0xa80 > [45040.330503] [] :xfs:xfs_fs_fill_super+0x98/0x230 > [45040.330511] [] __down_write_nested+0x12/0xb0 > [45040.330516] [] strlcpy+0x4e/0x80 > [45040.330523] [] get_filesystem+0x12/0x40 > [45040.330528] [] sget+0x3bf/0x3e0 > [45040.330533] [] set_bdev_super+0x0/0x10 > [45040.330541] [] get_sb_bdev+0x11f/0x190 > [45040.330559] [] :xfs:xfs_fs_fill_super+0x0/0x230 > [45040.330570] [] vfs_kern_mount+0xc6/0x170 > [45040.330579] [] do_kern_mount+0x4a/0x80 > [45040.330586] [] do_mount+0x6f9/0x7a0 > [45040.330592] [] __handle_mm_fault+0x668/0xab0 > [45040.330601] [] link_path_walk+0xd0/0xf0 > [45040.330608] [] __up_read+0x21/0xb0 > [45040.330614] [] do_page_fault+0x4b9/0x890 > [45040.330623] [] __handle_mm_fault+0x443/0xab0 > [45040.330629] [] zone_statistics+0x34/0x80 > [45040.330652] [] __get_free_pages+0x1b/0x40 > [45040.330661] [] sys_mount+0x9b/0x100 > [45040.330670] [] system_call+0x7e/0x83 > [45040.330680] > [45040.365771] Ending XFS recovery on filesystem: sda3 (logdev: internal) > > > > From owner-xfs@oss.sgi.com Sat Oct 13 06:43:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 13 Oct 2007 06:43:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_27, J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_74 autolearn=no version=3.3.0-r574664 Received: from smtp.aaisp.net.uk (smtp.aaisp.net.uk [81.187.81.52]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9DDh7cu024734 for ; Sat, 13 Oct 2007 06:43:08 -0700 Received: from zeus.pccl.info ([81.2.82.67]) by smtp.aaisp.net.uk with esmtp (Exim 4.62) (envelope-from ) id 1IfH8O-0007qv-Sx for xfs@oss.sgi.com; Tue, 09 Oct 2007 16:36:38 +0100 Date: Tue, 9 Oct 2007 16:36:35 +0100 From: Andrew Clayton To: xfs@oss.sgi.com Subject: Latencies in XFS. Message-ID: <20071009163635.413dec0c@zeus.pccl.info> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4539/Sat Oct 13 01:59:25 2007 on oss.sgi.com X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/4514/Tue Oct 9 15:03:20 2007, by smtp.aaisp.net.uk) X-Virus-Status: Clean X-archive-position: 13337 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrew@digital-domain.net Precedence: bulk X-list: xfs Hi, I'll try not to flood with information on the first post. In trying to track down this issue here: http://www.spinics.net/lists/raid/msg17195.html I think I have narrowed it down to XFS. The basic problem I am seeing is that applications on client workstations whose home directories are NFS mounted are stalling in filesystem calls such as open, close, unlink. I have eventually come up with a simple test case which shows the problem (well the seeming filesystem stalls anyway). I did this on my machine at home, Athlon XP 768MB RAM, XFS is on a Seagate IDE. Kernel is 2.8.23-rc9-current git (Oh yeah, no networking/NFS is involved here) If I run the following program /* fslattest.c */ #define _GNU_SOURCE #include #include #include #include #include #include #include int main(int argc, char *argv[]) { char file[255]; if (argc < 2) { printf("Usage: fslattest file\n"); exit(1); } strncpy(file, argv[1], 254); printf("Opening %s\n", file); while (1) { int testfd = open(file, O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600); close(testfd); unlink(file); sleep(1); } exit(0); } e.g $ strace -T -e open fslattest test And then after a few seconds run $ dd if=/dev/zero of=bigfile bs=1M count=500 I see the following Before dd kicks in open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.005043> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000212> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.016844> while dd is running open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <2.000348> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <1.594441> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <2.224636> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <1.074615> dd stopped open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.013224> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.007109> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.007108> Doing the same thing with ext3 shows no such stalls. e.g before, during and after the above dd open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.015423> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000092> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000093> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000088> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000103> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000096> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000094> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000114> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000091> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000274> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.000107> I Just tried the above on a machine here in the office. It seems to have a much faster disk than mine, and the latencies aren't quite a dramatic upto about 1.0 seconds. Mounting with nobarrier reduces that to generally < 0.5 seconds. Just ask if you'd like more info. Cheers, Andrew From owner-xfs@oss.sgi.com Sat Oct 13 07:29:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 13 Oct 2007 07:29:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9DETcbB002563 for ; Sat, 13 Oct 2007 07:29:39 -0700 Received: by nz-out-0506.google.com with SMTP id x3so728490nzd for ; Sat, 13 Oct 2007 07:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=BCX95ooay2PSkYVh68287rtBxZPfkehxncs6yRIZNYk=; b=h6sTfeOO/yD3zaYIDwpgdxY6d9wnlX+dCgFQbflqljQhBoXiiAfLdKIjneSia4V89AlIjBNGV/MkLQlfcanHlhWYAFwLbBY6+TuJAuZTWtK5q7DKfZx/fy7z+Qj2DXcrThJk5BXq+IpXuRtZ7Qdwtwusg+BrwAwpEeI/1k3zBvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B7uQQQ7f77dITpDl2ZCCr/0BBwReJp63UqHLcxH0etLeDr6bTJHapcMCNFf7nkjoUgMG6IEtg2W1Wip+ubU8TzfeNTdRBsHPqkhBHZyztZuur1wVTCla7cG7qRAP8ifXKKSfomeSko+hn4y9BRkrAdlu3xyq/FG436bkj0uki8c= Received: by 10.142.201.3 with SMTP id y3mr1268786wff.1192282517031; Sat, 13 Oct 2007 06:35:17 -0700 (PDT) Received: by 10.142.230.9 with HTTP; Sat, 13 Oct 2007 06:35:17 -0700 (PDT) Message-ID: Date: Sat, 13 Oct 2007 19:05:17 +0530 From: "Bhagi rathi" To: "Andrew Clayton" Subject: Re: XFS regression? Cc: "David Chinner" , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20071012123601.291fee8a@zeus.pccl.info> MIME-Version: 1.0 References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> X-Virus-Scanned: ClamAV 0.91.2/4539/Sat Oct 13 01:59:25 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2847 X-archive-position: 13339 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs David, Can you let me know the use after free problem? I want to understand how the life cycle of linux inode and xfs inode are related to log flush. Any pointer is also of great help. Thanks, - Bhagi On 10/12/07, Andrew Clayton wrote: > > On Fri, 12 Oct 2007 10:26:13 +1000, David Chinner wrote: > > > You can breath again. Here's a test patch (warning - may harm > > heh > > > kittens - not fully tested or verified) that solves both > > the use-after-free issue (by avoiding it altogether) as well the > > unlink/create latency because the log force is no longer there. > > > > (yay! xfsqa test 016 passes again ;) > > > > It does have other possible side effects triggering extra > > log forces elsewhere on inode writeback and affects sync behaviour > > so it's only a proof of concept at this point. > > What kernel is that against?. I got rejects with 2.6.23 > > However I tried a 2.6.18 on the file server and ran my test, it didn't > show the problem. I then made a 2.6.23 but with the patch from my git > bisect reverted. > > Doing the test with that kernel, while writing a 1GB file I saw only > one > 1 second latency (1.2) and only a few ~ 0.5 second latencies. > > However over the longer term I'm still seeing latencies > 1 second. > Just leaving my strace test running (no dd) on the raid filesystem I see > the > latencies come when the raid5 stripe cache fills up. So I think I'm > perhaps seeing another problem here. > > Running the strace (again no dd) on the system disk (not raided) I'm not > seeing any latencies. > > In fact the latencies on the raid array seem to be generally greater > than the system disk (all identical disks, all XFS). > > raid array > > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.122943> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.021620> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.014963> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.023264> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.011368> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.002561> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.012623> > > system disk > > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000190> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000039> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000191> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000268> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000188> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000233> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000279> > > > Maybe that's to be expected? > > > Cheers, > > > > Dave. > > Thanks for looking at this. > > Andrew > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Oct 13 11:10:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 13 Oct 2007 11:10:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.0-r574664 Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9DIAOpt006509 for ; Sat, 13 Oct 2007 11:10:26 -0700 Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix1-g20.free.fr (Postfix) with ESMTP id 537B81B93167 for ; Sat, 13 Oct 2007 20:10:25 +0200 (CEST) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 0AD443227FE; Sat, 13 Oct 2007 20:10:22 +0200 (CEST) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp7-g19.free.fr (Postfix) with ESMTP id BDB443227E9; Sat, 13 Oct 2007 20:10:21 +0200 (CEST) Date: Sat, 13 Oct 2007 20:10:15 +0200 From: Emmanuel Florac To: Andrew Clayton , xfs@oss.sgi.com Subject: Re: Latencies in XFS. Message-ID: <20071013201015.4a8008bb@galadriel.home> In-Reply-To: <20071009163635.413dec0c@zeus.pccl.info> References: <20071009163635.413dec0c@zeus.pccl.info> Organization: Intellique X-Mailer: Claws Mail 2.9.1 (GTK+ 2.8.20; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.91.2/4539/Sat Oct 13 01:59:25 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9DIAQpt006513 X-archive-position: 13340 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Tue, 9 Oct 2007 16:36:35 +0100 vous écriviez: > I think I have narrowed it down to XFS. I notice you use a bleeding-edge unstable kernel, with a whole new scheduler. I tried your benchmark on a machine running a known stable kernel (2.6.20.17) and the slowdown is similar in xfs and other fs. As a side note, I personnally wouldn't choose xfs for desktop users home directories (email,web, etc) because it's much better at pure throughput and quite slower at IOPS than other FSes. Reiserfs is the best of the common FSes for this. I'm quite surprised that apparently your production system is running a prerelease kernel. Why? -- -------------------------------------------------- Emmanuel Florac www.intellique.com -------------------------------------------------- From owner-xfs@oss.sgi.com Sat Oct 13 17:23:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 13 Oct 2007 17:23:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from smtp.aaisp.net.uk (smtp.aaisp.net.uk [81.187.81.51]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9E0NNQ3030253 for ; Sat, 13 Oct 2007 17:23:24 -0700 Received: from alpha.digital-domain.net ([217.169.2.51]) by smtp.aaisp.net.uk with esmtp (Exim 4.62) (envelope-from ) id 1IgrGN-000491-W5; Sun, 14 Oct 2007 01:23:24 +0100 Date: Sun, 14 Oct 2007 01:23:23 +0100 From: Andrew Clayton To: Emmanuel Florac Cc: xfs@oss.sgi.com Subject: Re: Latencies in XFS. Message-ID: <20071014012323.1d6c9e8e@alpha.digital-domain.net> In-Reply-To: <20071013201015.4a8008bb@galadriel.home> References: <20071009163635.413dec0c@zeus.pccl.info> <20071013201015.4a8008bb@galadriel.home> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.13; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: ClamAV 0.91.2/4539/Sat Oct 13 01:59:25 2007 on oss.sgi.com X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/4539/Sat Oct 13 09:59:25 2007, by smtp.aaisp.net.uk) X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9E0NOQ3030260 X-archive-position: 13341 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrew@digital-domain.net Precedence: bulk X-list: xfs On Sat, 13 Oct 2007 20:10:15 +0200, Emmanuel Florac wrote: > Le Tue, 9 Oct 2007 16:36:35 +0100 vous écriviez: > > > I think I have narrowed it down to XFS. > > I notice you use a bleeding-edge unstable kernel, with a whole new > scheduler. I tried your benchmark on a machine running a known stable > kernel (2.6.20.17) and the slowdown is similar in xfs and other fs. I don't see the slowdown in ext3. > As a side note, I personnally wouldn't choose xfs for desktop users > home directories (email,web, etc) because it's much better at pure > throughput and quite slower at IOPS than other FSes. Reiserfs is the > best of the common FSes for this. > > I'm quite surprised that apparently your production system is running > a prerelease kernel. Why? Actually it's now running 2.6.23 From owner-xfs@oss.sgi.com Sun Oct 14 05:21:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 05:21:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from frodo.openenterprise.co.uk (ns1.openenterprise.co.uk [81.21.68.157]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9ECLa9M029237 for ; Sun, 14 Oct 2007 05:21:41 -0700 Received: (qmail 68461 invoked from network); 14 Oct 2007 12:21:37 -0000 Received: from unknown (HELO [172.16.1.10]) ([81.187.75.195]) (envelope-sender ) by frodo.openenterprise.co.uk (qmail-ldap-1.03) with SMTP for ; 14 Oct 2007 12:21:37 -0000 Message-ID: <471209D0.9090305@openenterprise.co.uk> Date: Sun, 14 Oct 2007 13:21:36 +0100 From: Nick Gregory User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Justin Piszcz CC: xfs@oss.sgi.com Subject: Re: Repeated XFS Crash on x86_64 fiesty References: <470F2A1E.9070503@openenterprise.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13342 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nick@openenterprise.co.uk Precedence: bulk X-list: xfs Justin Piszcz wrote: > Have you run memtest86? Have you checked the CPU? Is it an AMD64 CPU > where the memory controller is onboard (and .. if damaged/overheating) > could cause problems with the memory? > Thanks for the suggestions. Shortly after my posting I had a drive fail shortly followed by another three taking out 6TB of data :-( , luckily part of a replicated pair. So its certainly a hardware thing either a bad raid card or a bad batch of drives rather than anything to do with XFS. From owner-xfs@oss.sgi.com Sun Oct 14 06:03:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 06:03:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_27, RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 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.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9ED3Hoc001507 for ; Sun, 14 Oct 2007 06:03:20 -0700 Resent-From: pg_mh@sabi.co.UK Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1Ih2YY-0002Lc-UD for ; Sun, 14 Oct 2007 13:26:54 +0100 Resent-Message-ID: <18194.2830.556977.355055@base.ty.sabi.co.UK> Resent-Date: Sun, 14 Oct 2007 13:26:54 +0100 Resent-To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 7bit 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> Message-ID: <18192.58798.363482.613421@base.ty.sabi.co.UK> References: <20071009163635.413dec0c@zeus.pccl.info> In-Reply-To: <20071009163635.413dec0c@zeus.pccl.info> X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13343 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_mh@sabi.co.UK Precedence: bulk X-list: xfs >>> On Tue, 9 Oct 2007 16:36:35 +0100, Andrew Clayton >>> said: andrew> [ ... ] The basic problem I am seeing is that andrew> applications on client workstations whose home andrew> directories are NFS mounted are stalling in filesystem andrew> calls such as open, close, unlink. Metadata and data sync/flushing can be handled very differently by the same filesystem and by different filesystems. [ ... ] andrew> [ ... ] e.g $ strace -T -e open fslattest test andrew> And then after a few seconds run andrew> $ dd if=/dev/zero of=bigfile bs=1M count=500 andrew> I see the following So metadata and data sync/flush are competing, and also 'dd' is hitting heavily the buffer cache, with 500MB on a 768MB system. andrew> Before dd kicks in andrew> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <0.005043> andrew> [ ... ] while dd is running andrew> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0600) = 3 <2.000348> andrew> [ ... ] Doing the same thing with ext3 shows no such andrew> stalls. All this does not sound that susprising to me. [ ... ] andrew> I Just tried the above on a machine here in the andrew> office. It seems to have a much faster disk than mine, andrew> and the latencies aren't quite a dramatic upto about 1.0 andrew> seconds. Mounting with nobarrier reduces that to andrew> generally < 0.5 seconds. That's a rather clear hint I suppose. My suggestion would be to run 'vmstat 1' watching in particular the cache and 'bi'/'bo' columns while doing experiments with: * Increasing value of the 'commit' mount option of 'ext3'. * Different value of the 'data' mount option of 'ext3'. * The elevator algorithm for the affected disks. * Changing values of '/proc/sys/net/bdflush'. * The 'oflag=direct' option of 'dd'. And the impact the above have on the memory-write-caching of XFS and the ordering of CPU and disk operations in general. There are many odd interactions of these parameters, here is an example of a discussion of a different case: http://www.sabi.co.uk/blog/0707jul.html#070701b Also, having a look at some bits of your Linux RAID list post: > /dev/md0 is currently mounted with the following options > noatime,logbufs=8,sunit=512,swidth=1024 > xfs_info shows > [ ... ] > = sunit=64 swidth=128 blks, unwritten=1 > Chunk Size : 256K > [ ... ] > 0 8 17 0 active sync /dev/sdb1 > 1 8 33 1 active sync /dev/sdc1 > 2 8 49 2 active sync /dev/sdd1 It might we useful to reconsider some of the build vs. mount parameters, and the chunk size (consider the non trivial issue of excessive stripe length). From owner-xfs@oss.sgi.com Sun Oct 14 07:49:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 07:49:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.0-r574664 Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9EEnVfL019415 for ; Sun, 14 Oct 2007 07:49:33 -0700 Received: from smtp7-g19.free.fr (smtp7-g19.free.fr [212.27.42.64]) by postfix2-g20.free.fr (Postfix) with ESMTP id 010C21BBD132 for ; Sun, 14 Oct 2007 14:48:30 +0200 (CEST) Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 36EF63227F4; Sun, 14 Oct 2007 16:49:30 +0200 (CEST) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp7-g19.free.fr (Postfix) with ESMTP id E53D63227F9; Sun, 14 Oct 2007 16:49:29 +0200 (CEST) Date: Sun, 14 Oct 2007 16:49:23 +0200 From: Emmanuel Florac To: Andrew Clayton Cc: xfs@oss.sgi.com Subject: Re: Latencies in XFS. Message-ID: <20071014164923.083d55dd@galadriel.home> In-Reply-To: <20071014012323.1d6c9e8e@alpha.digital-domain.net> References: <20071009163635.413dec0c@zeus.pccl.info> <20071013201015.4a8008bb@galadriel.home> <20071014012323.1d6c9e8e@alpha.digital-domain.net> Organization: Intellique X-Mailer: Claws Mail 2.9.1 (GTK+ 2.8.20; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9EEnXfL019423 X-archive-position: 13344 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Sun, 14 Oct 2007 01:23:23 +0100 vous écriviez: > > I notice you use a bleeding-edge unstable kernel, with a whole new > > scheduler. I tried your benchmark on a machine running a known > > stable kernel (2.6.20.17) and the slowdown is similar in xfs and > > other fs. > > I don't see the slowdown in ext3. I tried it and the slowdown is proportionnally similar, though XFS is slower IO-wise. -- -------------------------------------------------- Emmanuel Florac www.intellique.com -------------------------------------------------- From owner-xfs@oss.sgi.com Sun Oct 14 15:33:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 15:34:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_40,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 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.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9EMXqM9018524 for ; Sun, 14 Oct 2007 15:33:54 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1Ih3nb-0002Pu-4J for ; Sun, 14 Oct 2007 14:46:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18194.7606.548806.972422@base.ty.sabi.co.UK> Date: Sun, 14 Oct 2007 14:46:30 +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: Repeated XFS Crash on x86_64 fiesty In-Reply-To: <471209D0.9090305@openenterprise.co.uk> References: <470F2A1E.9070503@openenterprise.co.uk> <471209D0.9090305@openenterprise.co.uk> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13345 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 >>> On Sun, 14 Oct 2007 13:21:36 +0100, Nick Gregory >>> said: nick> [ ... ] Shortly after my posting I had a drive fail shortly nick> followed by another three taking out 6TB of data :-( , nick> luckily part of a replicated pair. So its certainly a nick> hardware thing either a bad raid card or a bad batch of nick> drives rather than anything to do with XFS. Multiple drive failures are somewhat more common than desirable, and RAID is based on the idea that failures are uncorrelated. But then I have seen storage systems where all the drives were of the same brand, model and even had nearly consecutive serial numbers, and of course got delivered at the same time, and never mind that all these drives end up all in the same rack, with the same cooling and power circuit and get started and stopped at the same times. For my home PC I have 4 drives of different brands, models, ordered at different times from different shops, and the backups are in external cases that are usually unconnected and unplugged from mains. Can't be too careful :-). From owner-xfs@oss.sgi.com Sun Oct 14 16:10:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 16:10:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9EN9xPp021249 for ; Sun, 14 Oct 2007 16:10:02 -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 JAA15372; Mon, 15 Oct 2007 09:09:57 +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 l9EN9sdD64708221; Mon, 15 Oct 2007 09:09:55 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9EN9nm364675854; Mon, 15 Oct 2007 09:09:49 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 15 Oct 2007 09:09:49 +1000 From: David Chinner To: Bhagi rathi Cc: Andrew Clayton , David Chinner , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071014230949.GO23367404@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> 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-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13346 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 On Sat, Oct 13, 2007 at 07:05:17PM +0530, Bhagi rathi wrote: > David, Can you let me know the use after free problem? I want to understand > how the life cycle of linux inode > and xfs inode are related to log flush. Log I/O completion: -> xfs_trans_commited -> xfs_iunpin(xfs inode) get linux inode from xfs inode -> mark_inode_dirty_sync(linux inode) Freeing the linux inode: clear_inode(linux_inode) -> xfs_inactive() -> xfs_trans_commit() (e.g. freeing data associated with unlinked inode) -> xfs_ipin() (link between xfs and linux inode broken) linux inode freed So, in log I/O completion, we can be completing a previous transaction at the same time clear_inode() is running, and hence in xfs_iunpin() we can race with the freeing of the linux inode as xfs_iunpin does not hold any locks. > Any pointer is also of great help. /me points at the code. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 14 16:19:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 14 Oct 2007 16:19:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9ENJQdJ026190 for ; Sun, 14 Oct 2007 16:19:28 -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 JAA15680; Mon, 15 Oct 2007 09:19:27 +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 l9ENJPdD64650707; Mon, 15 Oct 2007 09:19:26 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9ENJNZj58970889; Mon, 15 Oct 2007 09:19:23 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 15 Oct 2007 09:19:23 +1000 From: David Chinner To: Andrew Clayton Cc: David Chinner , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071014231923.GP23367404@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071012123601.291fee8a@zeus.pccl.info> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13347 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 On Fri, Oct 12, 2007 at 12:36:01PM +0100, Andrew Clayton wrote: > On Fri, 12 Oct 2007 10:26:13 +1000, David Chinner wrote: > > > You can breath again. Here's a test patch (warning - may harm > > heh > > > kittens - not fully tested or verified) that solves both > > the use-after-free issue (by avoiding it altogether) as well the > > unlink/create latency because the log force is no longer there. > > > > (yay! xfsqa test 016 passes again ;) > > > > It does have other possible side effects triggering extra > > log forces elsewhere on inode writeback and affects sync behaviour > > so it's only a proof of concept at this point. > > What kernel is that against?. I got rejects with 2.6.23 The xfs-dev tree - i.e. the XFS that will be in 2.6.25 ;) > However I tried a 2.6.18 on the file server and ran my test, it didn't > show the problem. I then made a 2.6.23 but with the patch from my git > bisect reverted. > > Doing the test with that kernel, while writing a 1GB file I saw only > one > 1 second latency (1.2) and only a few ~ 0.5 second latencies. > > However over the longer term I'm still seeing latencies > 1 second. Sure - you've got a busy disk. If the truncate has to flush the log and wait for space, then it's going to take some time for I/Os to complete. Full queue + busy disk == unpredictable latency for all operations. > Just leaving my strace test running (no dd) on the raid filesystem I see > the > latencies come when the raid5 stripe cache fills up. So I think I'm > perhaps seeing another problem here. Software raid isn't good for latency, either ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 15 02:36:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 02:37:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9F9aoPv006857 for ; Mon, 15 Oct 2007 02:36:52 -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 B0C5D22FF8; Mon, 15 Oct 2007 11:36:51 +0200 (CEST) To: David Chinner Cc: Jeremy Fitzhardinge , xfs@oss.sgi.com, Xen-devel , Linux Kernel Mailing List , Mark Williamson , Morten =?iso-8859-1?Q?B=C3=B8geskov?= , xfs-masters@oss.sgi.com, nickpiggin@yahoo.com.au Subject: Re: Interaction between Xen and XFS: stray RW mappings From: Andi Kleen References: <470FA7C3.90404@goop.org> <20071014225618.GN23367404@sgi.com> Date: Mon, 15 Oct 2007 11:36:50 +0200 In-Reply-To: <20071014225618.GN23367404@sgi.com> (David Chinner's message of "Mon\, 15 Oct 2007 08\:56\:18 +1000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13348 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs David Chinner writes: > > And yes, we delay unmapping pages until we have a batch of them > to unmap. vmap and vunmap do not scale, so this is batching helps > alleviate some of the worst of the problems. You're keeping vmaps around for already freed pages? That will be a big problem for proper PAT support, which needs to track all mappings to memory. It's not just a problem for Xen. In fact I suspect it is already broken with DRM or AGP for example which can use UC and WC mappings -- if you keep the mapping around and DRM or AGP turns the page in another mapping uncacheable you're creating an illegal cache attribute alias. These are known to occasionally create cache corruptions on several x86s; giving ___VERY___ hard to debug bugs once a blue moon. Probably it'll require some generic VM batching mechanism where Xen or PAT code can hook into the list or force unmap the mappings as needed. Definitely needs to be fixed if true. You're lucky that Xen caught it in time. -Andi From owner-xfs@oss.sgi.com Mon Oct 15 03:04:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 03:05:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9FA4nhO010573 for ; Mon, 15 Oct 2007 03:04:51 -0700 Received: by nz-out-0506.google.com with SMTP id x3so788036nzd for ; Mon, 15 Oct 2007 03:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=uH7Y97zo/3oY8Fc+H+V9bXAnozWQfHkRPUl4s0rs0NQ=; b=g7wqFS0S6t+h6mQ2Lb2nHf/PH3PpO295vId2yPngb1x/MEncpFffVXd29DaCUWrSFou960yQ2ySZLv2J3nhACIf9WGra+di2VQ6prCkOp9PTIywQrQM/YJLvR0zz2CS+MWN94I2xsXPJaCwDgGaO9vNcxyxhTE+9jRftIsKpooI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CKVipNUeJhnVTL4SjqMAonHpkDyP+2jmSFbejxZIEUVrC07hBaqtxrc8GzjqIGh+1zNDZKPiWMi1RnNPLU+tMjhHeeIC2gjGD6vhfZKpDtNuer3IjeSGvJn5ntbKFRPOoV5saWtMewGz47f8bCPqM5FdEktFivif2vdy6wlu+9Q= Received: by 10.142.139.19 with SMTP id m19mr1371113wfd.1192442314219; Mon, 15 Oct 2007 02:58:34 -0700 (PDT) Received: by 10.142.230.9 with HTTP; Mon, 15 Oct 2007 02:58:34 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 15:28:34 +0530 From: "Bhagi rathi" To: "David Chinner" Subject: Re: XFS regression? Cc: "Andrew Clayton" , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20071014230949.GO23367404@sgi.com> MIME-Version: 1.0 References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> <20071014230949.GO23367404@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1499 X-archive-position: 13349 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs Thanks Dave for the response. Thinking futher, why is that xfs_iunpin has to mark the inode dirty? All transactions generally modify one time or other, xfs_ichgtime takes care of marking inode as dirty. I am thinking on why we need to mark the inode dirty at all, either in the context of unpin or in the context for formatting the inode. -Bhagi. On 10/15/07, David Chinner wrote: > > On Sat, Oct 13, 2007 at 07:05:17PM +0530, Bhagi rathi wrote: > > David, Can you let me know the use after free problem? I want to > understand > > how the life cycle of linux inode > > and xfs inode are related to log flush. > > Log I/O completion: > > -> xfs_trans_commited > -> xfs_iunpin(xfs inode) > get linux inode from xfs inode > -> mark_inode_dirty_sync(linux inode) > > Freeing the linux inode: > > clear_inode(linux_inode) > -> xfs_inactive() > -> xfs_trans_commit() (e.g. freeing data associated with unlinked > inode) > -> xfs_ipin() > (link between xfs and linux inode broken) > linux inode freed > > So, in log I/O completion, we can be completing a previous > transaction at the same time clear_inode() is running, and > hence in xfs_iunpin() we can race with the freeing of the > linux inode as xfs_iunpin does not hold any locks. > > > Any pointer is also of great help. > > /me points at the code. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Oct 15 04:57:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 04:58:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9FBvpWs029081 for ; Mon, 15 Oct 2007 04:57:54 -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 VAA01964; Mon, 15 Oct 2007 21:57:51 +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 l9FBvmdD64965585; Mon, 15 Oct 2007 21:57:49 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9FBvjC465353400; Mon, 15 Oct 2007 21:57:45 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 15 Oct 2007 21:57:45 +1000 From: David Chinner To: Bhagi rathi Cc: David Chinner , Andrew Clayton , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071015115745.GK995458@sgi.com> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> <20071014230949.GO23367404@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13350 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 On Mon, Oct 15, 2007 at 03:28:34PM +0530, Bhagi rathi wrote: > Thanks Dave for the response. Thinking futher, why is that xfs_iunpin has > to mark the inode dirty? Because the inode has been modified, and instead of sprinkling mark_inode_dirty_sync() all over the code, we can do it in a single spot that catches all inode modifications. We don't have to think about it by doing this - inodes in transactions get marked dirty for free.... > All transactions generally modify one time or other, xfs_ichgtime takes care > of marking inode as > dirty. Sure, but there's plenty of other transactions that don't have such a convenient hook. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 15 06:35:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 06:35:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from smtp.aaisp.net.uk (smtp.aaisp.net.uk [81.187.81.52]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9FDZ97v009469 for ; Mon, 15 Oct 2007 06:35:12 -0700 Received: from zeus.pccl.info ([81.2.82.67]) by smtp.aaisp.net.uk with esmtp (Exim 4.62) (envelope-from ) id 1IgKZP-0004ni-LI; Fri, 12 Oct 2007 14:28:51 +0100 Date: Fri, 12 Oct 2007 14:28:47 +0100 From: Andrew Clayton To: David Chinner Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS regression? Message-ID: <20071012142847.110a1110@zeus.pccl.info> In-Reply-To: <20071012123601.291fee8a@zeus.pccl.info> References: <20071010152742.1b2a7bce@zeus.pccl.info> <20071011010139.GT995458@sgi.com> <20071011151512.69f19419@zeus.pccl.info> <20071011215352.GX995458@sgi.com> <20071012002613.GL23367404@sgi.com> <20071012123601.291fee8a@zeus.pccl.info> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Scanned: Clear (Version: ClamAV 0.91.2/4533/Fri Oct 12 11:59:29 2007, by smtp.aaisp.net.uk) X-Virus-Status: Clean X-archive-position: 13351 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrew@digital-domain.net Precedence: bulk X-list: xfs On Fri, 12 Oct 2007 12:36:01 +0100, Andrew Clayton wrote: Ignore the numbers below. under normal conditions the raid array and single drive show basically the same numbers. The raid array numbers were done over NFS. > raid array > > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.122943> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.021620> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.014963> > > system disk > > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000190> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000039> > open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000191> While we're talking number's... raid array, strace over NFS open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.018330> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.026398> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <8.927449> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <1.284661> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.030078> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.021407> open("test", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.018660> raid array, strace locally open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000069> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000044> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <8.995286> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <1.258810> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <1.225763> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000056> open("test2", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3 <0.000092> Those where running concurrently. I think that rules out networking. I'm getting more convinced it's a raid5 problem... Andrew From owner-xfs@oss.sgi.com Mon Oct 15 16:29:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 16:29:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9FNTMVB032325 for ; Mon, 15 Oct 2007 16:29:25 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20340 for ; Tue, 16 Oct 2007 09:29:24 +1000 Message-ID: <4713F7D3.2090201@sgi.com> Date: Tue, 16 Oct 2007 09:29:23 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: Review: Fix dbflush panic in xfs_qm_sync Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13352 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs The recent behaviour layer removal dropped the check for quotas that have been requested at mount time but have subsequently been turned off. This results in a panic when accessing m_quotainfo which has been freed. This patch adds the check originally made by xfs_qm_syncall() to xfs_qm_sync() Signed-off-by: Donald Douwsma --- 2.6.x-xfs.orig/fs/xfs/quota/xfs_qm.c +++ 2.6.x-xfs/fs/xfs/quota/xfs_qm.c @@ -1007,6 +1007,9 @@ xfs_qm_sync( boolean_t nowait; int error; + if (! XFS_IS_QUOTA_ON(mp)) + return 0; + restarts = 0; /* * We won't block unless we are asked to. From owner-xfs@oss.sgi.com Mon Oct 15 20:10:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 20:10:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9G3AfGS001525 for ; Mon, 15 Oct 2007 20:10:44 -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 NAA25721; Tue, 16 Oct 2007 13:10:38 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 73E5458C38F1; Tue, 16 Oct 2007 13:10:38 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 971902 - eagerly remove vmap mappings to avoid upsetting Xen Message-Id: <20071016031038.73E5458C38F1@chook.melbourne.sgi.com> Date: Tue, 16 Oct 2007 13:10:38 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13353 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 eagerly remove vmap mappings to avoid upsetting Xen XFS leaves stray mappings around when it vmaps memory to make it virtually contigious. This upsets Xen if one of those pages is being recycled into a pagetable, since it finds an extra writable mapping of the page. This patch solves the problem in a brute force way, by making XFS always eagerly unmap its mappings. Signed-off-by: Jeremy Fitzhardinge Date: Tue Oct 16 13:10:07 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: jeremy@xensource.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29886a fs/xfs/linux-2.6/xfs_buf.c - 1.246 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.246&r2=text&tr2=1.245&f=h - Always unmap buffers immediately if we are configure to run Xen. From owner-xfs@oss.sgi.com Mon Oct 15 22:13:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 22:13:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9G5D9xi020257 for ; Mon, 15 Oct 2007 22:13:13 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28592; Tue, 16 Oct 2007 15:13:07 +1000 Message-ID: <4714498A.8090902@sgi.com> Date: Tue, 16 Oct 2007 15:18:02 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss Subject: Re: Review: Fix dbflush panic in xfs_qm_sync References: <4713F7D3.2090201@sgi.com> In-Reply-To: <4713F7D3.2090201@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13354 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Could mp->m_quotainfo become NULL after this check but before we lock the list with xfs_qm_mplist_lock()? There doesn't seem to be any locking to protect changes to this field? Donald Douwsma wrote: > The recent behaviour layer removal dropped the check for quotas that > have been > requested at mount time but have subsequently been turned off. This results > in a panic when accessing m_quotainfo which has been freed. > > This patch adds the check originally made by xfs_qm_syncall() to > xfs_qm_sync() > > > Signed-off-by: Donald Douwsma > > --- 2.6.x-xfs.orig/fs/xfs/quota/xfs_qm.c > +++ 2.6.x-xfs/fs/xfs/quota/xfs_qm.c > @@ -1007,6 +1007,9 @@ xfs_qm_sync( > boolean_t nowait; > int error; > > + if (! XFS_IS_QUOTA_ON(mp)) > + return 0; > + > restarts = 0; > /* > * We won't block unless we are asked to. > > > From owner-xfs@oss.sgi.com Mon Oct 15 23:07:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 15 Oct 2007 23:07:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9G67XbG026920 for ; Mon, 15 Oct 2007 23:07:35 -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 QAA00052; Tue, 16 Oct 2007 16:07:29 +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 l9G67SdD66699429; Tue, 16 Oct 2007 16:07:29 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9G67Qjk66680322; Tue, 16 Oct 2007 16:07:26 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 16 Oct 2007 16:07:26 +1000 From: David Chinner To: Lachlan McIlroy Cc: Donald Douwsma , xfs-oss Subject: Re: Review: Fix dbflush panic in xfs_qm_sync Message-ID: <20071016060726.GR995458@sgi.com> References: <4713F7D3.2090201@sgi.com> <4714498A.8090902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4714498A.8090902@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13355 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 On Tue, Oct 16, 2007 at 03:18:02PM +1000, Lachlan McIlroy wrote: > Could mp->m_quotainfo become NULL after this check but before we > lock the list with xfs_qm_mplist_lock()? There doesn't seem to > be any locking to protect changes to this field? Possible - in theory. Likely - no. We do the same unlocked check in a few places... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 16 00:38:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 16 Oct 2007 00:38:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_00,EMPTY_MESSAGE, MISSING_SUBJECT,TVD_SPACE_RATIO autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9G7cHPL008419 for ; Tue, 16 Oct 2007 00:38: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 RAA01642 for ; Tue, 16 Oct 2007 17:22: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 l9G7MmdD66595263 for ; Tue, 16 Oct 2007 17:22:49 +1000 (AEST) Received: (from xaiki@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9G7Mmd466683444 for xfs@oss.sgi.com; Tue, 16 Oct 2007 17:22:48 +1000 (AEST) Date: Tue, 16 Oct 2007 17:22:48 +1000 (AEST) From: Niv Sardi-Altivanik Message-Id: <200710160722.l9G7Mmd466683444@snort.melbourne.sgi.com> Apparently-To: X-Virus-Scanned: ClamAV 0.91.2/4540/Sat Oct 13 18:43:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13356 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@snort.melbourne.sgi.com Precedence: bulk X-list: xfs From owner-xfs@oss.sgi.com Tue Oct 16 18:54:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 16 Oct 2007 18:54:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9H1sU2G021526 for ; Tue, 16 Oct 2007 18:54:33 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29135; Wed, 17 Oct 2007 11:54:28 +1000 Message-ID: <47156B54.8070102@sgi.com> Date: Wed, 17 Oct 2007 11:54:28 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Lachlan McIlroy , xfs-oss Subject: Re: Review: Fix dbflush panic in xfs_qm_sync References: <4713F7D3.2090201@sgi.com> <4714498A.8090902@sgi.com> <20071016060726.GR995458@sgi.com> In-Reply-To: <20071016060726.GR995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13357 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Oct 16, 2007 at 03:18:02PM +1000, Lachlan McIlroy wrote: >> Could mp->m_quotainfo become NULL after this check but before we >> lock the list with xfs_qm_mplist_lock()? There doesn't seem to >> be any locking to protect changes to this field? > > Possible - in theory. Likely - no. We do the same unlocked check in a > few places... > The mplist lock doesnt prevent the quotainfo going away while its held. It's just guarding a hashlist that lives in quotainfo structure. So none of this code prevents a quotaoff race. In the short term this change restores the original checks. But in the longer term we should review the locking in the quota system, possibly adding a quotaoff lock to xfs_mount_t. Don From owner-xfs@oss.sgi.com Tue Oct 16 19:14:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 16 Oct 2007 19:14:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9H2EhIN023735 for ; Tue, 16 Oct 2007 19:14:45 -0700 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 MAA29707; Wed, 17 Oct 2007 12:14:41 +1000 Message-ID: <47157073.6080005@sgi.com> Date: Wed, 17 Oct 2007 12:16:19 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: xfs-dev CC: linux-xfs@oss.sgi.com Subject: Review: Make xfs_bulkstat() to report unlinked but referenced inodes Content-Type: multipart/mixed; boundary="------------040801000200090007020209" X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13358 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 This is a multi-part message in MIME format. --------------040801000200090007020209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We need xfs_bulkstat() to report inode stat for inodes with link count zero but reference count non zero. The fix here: http://oss.sgi.com/archives/xfs/2007-09/msg00266.html changed this behavior and made xfs_bulkstat() to filter all unlinked inodes including those that are not destroyed yet but held by reference. The attached patch returns back to the original behavior by marking the on-disk inode buffer dirty when di_mode is cleared (at that time both inode link and reference counter are zero). Regards, Vlad --------------040801000200090007020209 Content-Type: text/x-patch; name="Make-xfs_bulkstat-report-inodes-with-link-count-zero-and-reference-count-non-zero.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Make-xfs_bulkstat-report-inodes-with-link-count-zero-and-ref"; filename*1="erence-count-non-zero.patch" Index: linux-xfs1/fs/xfs/xfs_inode.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_inode.c +++ linux-xfs1/fs/xfs/xfs_inode.c @@ -1951,24 +1951,6 @@ xfs_iunlink( ASSERT(agi->agi_unlinked[bucket_index]); ASSERT(be32_to_cpu(agi->agi_unlinked[bucket_index]) != agino); - error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); - if (error) - return error; - - /* - * Clear the on-disk di_nlink. This is to prevent xfs_bulkstat - * from picking up this inode when it is reclaimed (its incore state - * initialzed but not flushed to disk yet). The in-core di_nlink is - * already cleared in xfs_droplink() and a corresponding transaction - * logged. The hack here just synchronizes the in-core to on-disk - * di_nlink value in advance before the actual inode sync to disk. - * This is OK because the inode is already unlinked and would never - * change its di_nlink again for this inode generation. - * This is a temporary hack that would require a proper fix - * in the future. - */ - dip->di_core.di_nlink = 0; - if (be32_to_cpu(agi->agi_unlinked[bucket_index]) != NULLAGINO) { /* * There is already another inode in the bucket we need @@ -1976,6 +1958,10 @@ xfs_iunlink( * Here we put the head pointer into our next pointer, * and then we fall through to point the head at us. */ + error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); + if (error) + return error; + ASSERT(be32_to_cpu(dip->di_next_unlinked) == NULLAGINO); /* both on-disk, don't endian flip twice */ dip->di_next_unlinked = agi->agi_unlinked[bucket_index]; @@ -2365,6 +2351,8 @@ xfs_ifree( int error; int delete; xfs_ino_t first_ino; + xfs_dinode_t *dip; + xfs_buf_t *ibp; ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); ASSERT(ip->i_transp == tp); @@ -2400,8 +2388,27 @@ xfs_ifree( * by reincarnations of this inode. */ ip->i_d.di_gen++; + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + error = xfs_itobp(ip->i_mount, tp, ip, &dip, &ibp, 0, 0); + if (error) + return error; + + /* + * Clear the on-disk di_mode. This is to prevent xfs_bulkstat + * from picking up this inode when it is reclaimed (its incore state + * initialzed but not flushed to disk yet). The in-core di_mode is + * already cleared and a corresponding transaction logged. + * The hack here just synchronizes the in-core to on-disk + * di_mode value in advance before the actual inode sync to disk. + * This is OK because the inode is already unlinked and would never + * change its di_mode again for this inode generation. + * This is a temporary hack that would require a proper fix + * in the future. + */ + dip->di_core.di_mode = 0; + if (delete) { xfs_ifree_cluster(ip, tp, first_ino); } Index: linux-xfs1/fs/xfs/xfs_itable.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_itable.c +++ linux-xfs1/fs/xfs/xfs_itable.c @@ -291,7 +291,7 @@ xfs_bulkstat_use_dinode( dip = (xfs_dinode_t *) xfs_buf_offset(bp, clustidx << mp->m_sb.sb_inodelog); /* - * Check the buffer containing the on-disk inode for di_nlink == 0. + * Check the buffer containing the on-disk inode for di_mode == 0. * This is to prevent xfs_bulkstat from picking up just reclaimed * inodes that have their in-core state initialized but not flushed * to disk yet. This is a temporary hack that would require a proper @@ -299,7 +299,7 @@ xfs_bulkstat_use_dinode( */ if (be16_to_cpu(dip->di_core.di_magic) != XFS_DINODE_MAGIC || !XFS_DINODE_GOOD_VERSION(dip->di_core.di_version) || - !dip->di_core.di_nlink) + !dip->di_core.di_mode) return 0; if (flags & BULKSTAT_FG_QUICK) { *dipp = dip; --------------040801000200090007020209-- From owner-xfs@oss.sgi.com Tue Oct 16 21:58:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 16 Oct 2007 21:58:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9H4vxwx009492 for ; Tue, 16 Oct 2007 21:58:03 -0700 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l9H4w0vt011468 for ; Wed, 17 Oct 2007 13:58:00 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l9H4u2SA023962 for ; Wed, 17 Oct 2007 13:56:02 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l9H4u2f07733 for xfs@oss.sgi.com; Wed, 17 Oct 2007 13:56:02 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l9H4u2B26717 for ; Wed, 17 Oct 2007 13:56:02 +0900 (JST) Received: from TNESG9305.wm.jp.nec.com ([10.64.168.199] [10.64.168.199]) by mail.jp.nec.com with ESMTP; Wed, 17 Oct 2007 13:56:01 +0900 Message-Id: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> Date: Wed, 17 Oct 2007 13:56:00 +0900 To: xfs@oss.sgi.com Subject: [PATCH] flush inode when changing atime. From: Utako Kusaka MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13359 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: u-kusaka@wm.jp.nec.com Precedence: bulk X-list: xfs Hi, The atime is changed for reading but it returns to a previous value after unmount. i_update_core is still off after reading a file using read(), readdir() and readlink(). So an inode isn't flushed to disk. I referred to following fix when I made a patch: TAKE 946679 - fix, speedup and simplify atime handling http://marc.info/?l=linux-xfs&m=113398234310217&w=4 Example: # ls -lu mpnt/log3 -rw-r--r-- 1 root root 63494 2007-04-05 16:35 mpnt/log3 # less mpnt/log3 # ls -lu mpnt/log3 -rw-r--r-- 1 root root 63494 2007-10-05 15:27 mpnt/log3 # umount mpnt/ # mount -t xfs /dev/sda6 mpnt # ls -lu mpnt/log3 -rw-r--r-- 1 root root 63494 2007-04-05 16:35 mpnt/log3 -- Utako Signed-off-by: Utako Kusaka ---------- --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-10-15 15:50:10.000000000 +0900 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-10-15 16:49:35.000000000 +0900 @@ -1003,6 +1003,8 @@ xfs_readlink( error = xfs_readlink_bmap(ip, link); } + ip->i_update_core = 1; + out: xfs_iunlock(ip, XFS_ILOCK_SHARED); return error; --- linux-2.6-xfs.orig/fs/xfs/xfs_dir2.c 2007-10-15 15:50:09.000000000 +0900 +++ linux-2.6-xfs/fs/xfs/xfs_dir2.c 2007-10-15 16:48:47.000000000 +0900 @@ -318,6 +318,9 @@ xfs_readdir( else rval = xfs_dir2_leaf_getdents(dp, dirent, bufsize, offset, filldir); + + dp->i_update_core = 1; + return rval; } --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-10-15 15:50:10.000000000 +0900 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-10-15 16:50:50.000000000 +0900 @@ -275,6 +275,9 @@ xfs_read( XFS_STATS_ADD(xs_read_bytes, ret); xfs_iunlock(ip, XFS_IOLOCK_SHARED); + + if (likely(!(ioflags & IO_INVIS))) + ip->i_update_core = 1; return ret; } ---------- From owner-xfs@oss.sgi.com Tue Oct 16 22:46:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 16 Oct 2007 22:47:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9H5krRI019832 for ; Tue, 16 Oct 2007 22:46:55 -0700 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 PAA04748; Wed, 17 Oct 2007 15:46:51 +1000 Message-ID: <4715A22D.1070409@sgi.com> Date: Wed, 17 Oct 2007 15:48:29 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: xfs-dev CC: xfs mailing list Subject: Review: Make xfs_bulkstat() to report unlinked but referenced inodes Content-Type: multipart/mixed; boundary="------------080804040807060908060006" X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13360 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 This is a multi-part message in MIME format. --------------080804040807060908060006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We need xfs_bulkstat() to report inode stat for inodes with link count zero but reference count non zero. The fix here: http://oss.sgi.com/archives/xfs/2007-09/msg00266.html changed this behavior and made xfs_bulkstat() to filter all unlinked inodes including those that are not destroyed yet but held by reference. The attached patch returns back to the original behavior by marking the on-disk inode buffer "dirty" when di_mode is cleared (at that time both inode link and reference counter are zero). Regards, Vlad --------------080804040807060908060006 Content-Type: text/x-patch; name="Make-xfs_bulkstat-report-inodes-with-link-count-zero-and-reference-count-non-zero.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Make-xfs_bulkstat-report-inodes-with-link-count-zero-and-ref"; filename*1="erence-count-non-zero.patch" Index: linux-xfs1/fs/xfs/xfs_inode.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_inode.c +++ linux-xfs1/fs/xfs/xfs_inode.c @@ -1951,24 +1951,6 @@ xfs_iunlink( ASSERT(agi->agi_unlinked[bucket_index]); ASSERT(be32_to_cpu(agi->agi_unlinked[bucket_index]) != agino); - error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); - if (error) - return error; - - /* - * Clear the on-disk di_nlink. This is to prevent xfs_bulkstat - * from picking up this inode when it is reclaimed (its incore state - * initialzed but not flushed to disk yet). The in-core di_nlink is - * already cleared in xfs_droplink() and a corresponding transaction - * logged. The hack here just synchronizes the in-core to on-disk - * di_nlink value in advance before the actual inode sync to disk. - * This is OK because the inode is already unlinked and would never - * change its di_nlink again for this inode generation. - * This is a temporary hack that would require a proper fix - * in the future. - */ - dip->di_core.di_nlink = 0; - if (be32_to_cpu(agi->agi_unlinked[bucket_index]) != NULLAGINO) { /* * There is already another inode in the bucket we need @@ -1976,6 +1958,10 @@ xfs_iunlink( * Here we put the head pointer into our next pointer, * and then we fall through to point the head at us. */ + error = xfs_itobp(mp, tp, ip, &dip, &ibp, 0, 0); + if (error) + return error; + ASSERT(be32_to_cpu(dip->di_next_unlinked) == NULLAGINO); /* both on-disk, don't endian flip twice */ dip->di_next_unlinked = agi->agi_unlinked[bucket_index]; @@ -2365,6 +2351,8 @@ xfs_ifree( int error; int delete; xfs_ino_t first_ino; + xfs_dinode_t *dip; + xfs_buf_t *ibp; ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); ASSERT(ip->i_transp == tp); @@ -2400,8 +2388,27 @@ xfs_ifree( * by reincarnations of this inode. */ ip->i_d.di_gen++; + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + error = xfs_itobp(ip->i_mount, tp, ip, &dip, &ibp, 0, 0); + if (error) + return error; + + /* + * Clear the on-disk di_mode. This is to prevent xfs_bulkstat + * from picking up this inode when it is reclaimed (its incore state + * initialzed but not flushed to disk yet). The in-core di_mode is + * already cleared and a corresponding transaction logged. + * The hack here just synchronizes the in-core to on-disk + * di_mode value in advance before the actual inode sync to disk. + * This is OK because the inode is already unlinked and would never + * change its di_mode again for this inode generation. + * This is a temporary hack that would require a proper fix + * in the future. + */ + dip->di_core.di_mode = 0; + if (delete) { xfs_ifree_cluster(ip, tp, first_ino); } Index: linux-xfs1/fs/xfs/xfs_itable.c =================================================================== --- linux-xfs1.orig/fs/xfs/xfs_itable.c +++ linux-xfs1/fs/xfs/xfs_itable.c @@ -291,7 +291,7 @@ xfs_bulkstat_use_dinode( dip = (xfs_dinode_t *) xfs_buf_offset(bp, clustidx << mp->m_sb.sb_inodelog); /* - * Check the buffer containing the on-disk inode for di_nlink == 0. + * Check the buffer containing the on-disk inode for di_mode == 0. * This is to prevent xfs_bulkstat from picking up just reclaimed * inodes that have their in-core state initialized but not flushed * to disk yet. This is a temporary hack that would require a proper @@ -299,7 +299,7 @@ xfs_bulkstat_use_dinode( */ if (be16_to_cpu(dip->di_core.di_magic) != XFS_DINODE_MAGIC || !XFS_DINODE_GOOD_VERSION(dip->di_core.di_version) || - !dip->di_core.di_nlink) + !dip->di_core.di_mode) return 0; if (flags & BULKSTAT_FG_QUICK) { *dipp = dip; --------------080804040807060908060006-- From owner-xfs@oss.sgi.com Wed Oct 17 00:13:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 00:14:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from ent-pocinrl01.gannett.com (ent-pocinrl01.gannett.com [167.8.66.14]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9H7Du8N029546 for ; Wed, 17 Oct 2007 00:13:59 -0700 Received: from ENT-POCEXHUB02.us.ad.gannett.com (unknown [172.30.1.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ent-pocinrl01.gannett.com (Postfix) with ESMTP id 43D52233F31 for ; Wed, 17 Oct 2007 02:51:57 -0400 (EDT) Received: from mail.dmreg.com (10.4.12.26) by ENT-POCEXHUB02.us.ad.gannett.com (172.30.1.46) with Microsoft SMTP Server id 8.0.730.1; Wed, 17 Oct 2007 02:51:57 -0400 Received: from des-vscan01.desmoines.local ([10.4.12.45]) by mail.dmreg.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 01:51:51 -0500 X-Mailer: Network Associates, Inc. Webshield SMTP, Version 4.5 MR2 Date: Wed, 17 Oct 2007 02:51:57 -0400 To: Subject: Corrupt message detected Message-ID: X-OriginalArrivalTime: 17 Oct 2007 06:51:51.0335 (UTC) FILETIME=[322C3B70:01C8108A] MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13361 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: owner-xfs@oss.sgi.com Precedence: bulk X-list: xfs A corrupt mail message, ID 1192603907370 from has been detected. From owner-xfs@oss.sgi.com Wed Oct 17 02:08:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 02:09:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9H98s8p011344 for ; Wed, 17 Oct 2007 02:08:56 -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 TAA09071; Wed, 17 Oct 2007 19:08: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 l9H98ldD63489684; Wed, 17 Oct 2007 19:08:47 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9H98ipC57818710; Wed, 17 Oct 2007 19:08:44 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 17 Oct 2007 19:08:44 +1000 From: David Chinner To: Utako Kusaka Cc: xfs@oss.sgi.com Subject: Re: [PATCH] flush inode when changing atime. Message-ID: <20071017090844.GZ995458@sgi.com> References: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13362 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 On Wed, Oct 17, 2007 at 01:56:00PM +0900, Utako Kusaka wrote: > Hi, > > The atime is changed for reading but it returns to a previous value > after unmount. i_update_core is still off after reading a file using > read(), readdir() and readlink(). So an inode isn't flushed to disk. I think this was done by design - Christoph? I can't remember exactly as it was more than two years ago this change was made. It is effectively equivalent to using the relatime mount option. The question is whether we want to change the default behaviour or whether we need to supply an "atimeisatime" mount option for those that really need atime to be updated on every access. > I referred to following fix when I made a patch: > TAKE 946679 - fix, speedup and simplify atime handling > http://marc.info/?l=linux-xfs&m=113398234310217&w=4 Yes, that was the patch that removed the explicit atime updates in the XFS code. Your fix is reverting part of that change. > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-10-15 15:50:10.000000000 +0900 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-10-15 16:49:35.000000000 +0900 > @@ -1003,6 +1003,8 @@ xfs_readlink( > error = xfs_readlink_bmap(ip, link); > } > > + ip->i_update_core = 1; > + If we are going to put these back in, then they should be calls to xfs_ichgtime_fast() so that we know what the reason for marking the core dirty is. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 17 04:03:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 04:03:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9HB3k9r007872 for ; Wed, 17 Oct 2007 04:03:48 -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 VAA11210; Wed, 17 Oct 2007 21:03:40 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id D4B3158C38F1; Wed, 17 Oct 2007 21:03:39 +1000 (EST) Date: Wed, 17 Oct 2007 21:03:39 +1000 To: torvalds@linux-foundation.org Cc: tes@sgi.com, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc1 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071017110339.D4B3158C38F1@chook.melbourne.sgi.com> From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4541/Tue Oct 16 12:55:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13363 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 Hi Linus, Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus These include changes we have had scheduled for 2.6.24. In particular they include Christoph's (hch's) behavior removal patches. --Tim This will update the following files: fs/xfs/Makefile-linux-2.6 | 3 - fs/xfs/linux-2.6/xfs_aops.c | 57 ++-- fs/xfs/linux-2.6/xfs_aops.h | 2 +- fs/xfs/linux-2.6/xfs_buf.c | 26 ++- fs/xfs/linux-2.6/xfs_export.c | 20 +- fs/xfs/linux-2.6/xfs_file.c | 174 +++------- fs/xfs/linux-2.6/xfs_fs_subr.c | 54 ++-- fs/xfs/linux-2.6/xfs_fs_subr.h | 4 - fs/xfs/linux-2.6/xfs_globals.c | 5 - fs/xfs/linux-2.6/xfs_globals.h | 1 - fs/xfs/linux-2.6/xfs_ioctl.c | 242 +++++++------ fs/xfs/linux-2.6/xfs_ioctl32.c | 8 +- fs/xfs/linux-2.6/xfs_iops.c | 196 ++++------- fs/xfs/linux-2.6/xfs_iops.h | 8 +- fs/xfs/linux-2.6/xfs_linux.h | 3 +- fs/xfs/linux-2.6/xfs_lrw.c | 104 +++---- fs/xfs/linux-2.6/xfs_lrw.h | 23 +-- fs/xfs/linux-2.6/xfs_super.c | 298 ++++++++-------- fs/xfs/linux-2.6/xfs_super.h | 5 +- fs/xfs/linux-2.6/xfs_vfs.c | 327 ------------------ fs/xfs/linux-2.6/xfs_vfs.h | 168 +--------- fs/xfs/linux-2.6/xfs_vnode.c | 100 +++--- fs/xfs/linux-2.6/xfs_vnode.h | 345 ++----------------- fs/xfs/quota/xfs_qm.c | 51 +--- fs/xfs/quota/xfs_qm.h | 6 +- fs/xfs/quota/xfs_qm_bhv.c | 239 ++----------- fs/xfs/quota/xfs_qm_syscalls.c | 21 +- fs/xfs/support/move.c | 51 --- fs/xfs/support/move.h | 70 ---- fs/xfs/xfs_acl.c | 33 +- fs/xfs/xfs_acl.h | 19 +- fs/xfs/xfs_ag.h | 4 + fs/xfs/xfs_attr.c | 50 ++- fs/xfs/xfs_attr.h | 17 +- fs/xfs/xfs_behavior.c | 183 ---------- fs/xfs/xfs_behavior.h | 185 ---------- fs/xfs/xfs_bmap.c | 150 +++++---- fs/xfs/xfs_bmap.h | 4 +- fs/xfs/xfs_bmap_btree.c | 255 +++++--------- fs/xfs/xfs_bmap_btree.h | 68 +--- fs/xfs/xfs_buf_item.c | 1 + fs/xfs/xfs_clnt.h | 1 - fs/xfs/xfs_dfrag.c | 6 +- fs/xfs/xfs_dinode.h | 65 ++-- fs/xfs/xfs_dir2.c | 117 +------ fs/xfs/xfs_dir2.h | 17 - fs/xfs/xfs_dir2_block.c | 64 ++--- fs/xfs/xfs_dir2_block.h | 5 +- fs/xfs/xfs_dir2_data.c | 1 + fs/xfs/xfs_dir2_leaf.c | 76 ++--- fs/xfs/xfs_dir2_leaf.h | 6 +- fs/xfs/xfs_dir2_node.c | 1 + fs/xfs/xfs_dir2_sf.c | 122 +++---- fs/xfs/xfs_dir2_sf.h | 5 +- fs/xfs/xfs_dmapi.h | 17 +- fs/xfs/xfs_dmops.c | 43 ++- fs/xfs/xfs_error.c | 21 +- fs/xfs/xfs_error.h | 5 +- fs/xfs/xfs_extfree_item.c | 1 + fs/xfs/xfs_fsops.c | 17 +- fs/xfs/xfs_ialloc.c | 6 +- fs/xfs/xfs_ialloc.h | 7 +- fs/xfs/xfs_iget.c | 605 +++++++++++--------------------- fs/xfs/xfs_inode.c | 383 +++++++++++---------- fs/xfs/xfs_inode.h | 158 +++++---- fs/xfs/xfs_iocore.c | 4 +- fs/xfs/xfs_iomap.c | 8 - fs/xfs/xfs_iomap.h | 1 - fs/xfs/xfs_itable.c | 78 +++-- fs/xfs/xfs_log.c | 100 +++--- fs/xfs/xfs_log_priv.h | 21 +- fs/xfs/xfs_log_recover.c | 32 +- fs/xfs/xfs_mount.c | 242 +++++++------- fs/xfs/xfs_mount.h | 176 +++++----- fs/xfs/xfs_qmops.c | 40 ++- fs/xfs/xfs_quota.h | 10 +- fs/xfs/xfs_rename.c | 38 +-- fs/xfs/xfs_rw.c | 5 +- fs/xfs/xfs_rw.h | 34 -- fs/xfs/xfs_sb.h | 68 ++++- fs/xfs/xfs_trans.c | 76 ++--- fs/xfs/xfs_trans_ail.c | 1 + fs/xfs/xfs_trans_extfree.c | 1 + fs/xfs/xfs_types.h | 12 - fs/xfs/xfs_utils.c | 9 +- fs/xfs/xfs_utils.h | 6 +- fs/xfs/xfs_vfsops.c | 351 ++++++++++++------- fs/xfs/xfs_vfsops.h | 28 ++ fs/xfs/xfs_vnodeops.c | 745 +++++++++++++--------------------------- fs/xfs/xfs_vnodeops.h | 86 +++++ 90 files changed, 2762 insertions(+), 4739 deletions(-) delete mode 100644 fs/xfs/linux-2.6/xfs_vfs.c delete mode 100644 fs/xfs/support/move.c delete mode 100644 fs/xfs/support/move.h delete mode 100644 fs/xfs/xfs_behavior.c delete mode 100644 fs/xfs/xfs_behavior.h create mode 100644 fs/xfs/xfs_vfsops.h create mode 100644 fs/xfs/xfs_vnodeops.h through these commits: commit 7f015072348a14f16d548be557ee58c5c55df0aa Author: Jeremy Fitzhardinge Date: Wed Oct 17 13:55:03 2007 +1000 [XFS] eagerly remove vmap mappings to avoid upsetting Xen XFS leaves stray mappings around when it vmaps memory to make it virtually contigious. This upsets Xen if one of those pages is being recycled into a pagetable, since it finds an extra writable mapping of the page. This patch solves the problem in a brute force way, by making XFS always eagerly unmap its mappings. SGI-PV: 971902 SGI-Modid: xfs-linux-melb:xfs-kern:29886a Signed-off-by: Jeremy Fitzhardinge Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 6572bc28de150aaa6ca182eaf3e60c199ba48630 Author: Christoph Hellwig Date: Wed Sep 19 15:27:39 2007 +1000 [XFS] simplify validata_fields Stop using xfs_getattr and a onstack bhv_vattr_t just to get three fields from the underlying inode and opencode copying from the inode fields instead. SGI-PV: 970662 SGI-Modid: xfs-linux-melb:xfs-kern:29711a Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 150f29ef2e96392c6ddf24d49289dd40df2783f0 Author: Tim Shimmin Date: Tue Oct 16 16:20:12 2007 +1000 [XFS] no longer using io_vnode, as was remaining from 23 cherrypick Because we cherrypicked SGI-Modid xfs-linux-melb:xfs-kern:29675a and it depended on the sgi mod which removed io_vnode (which was not cherrypicked in 23) it was hand modified. This fixes things back up (to the originial mod) now we have moved on again. Reviewed-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 479ba36bbb322a21aa65cc89223c50adf78f4a56 Author: Tim Shimmin Date: Tue Oct 16 15:32:57 2007 +1000 [XFS] Remove STATIC which was missing from prior manual merge Removes STATIC on xfs_freeze function which was not manually applied for SGI-Modid: xfs-linux-melb:xfs-kern:29504a. Reviewed-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit cd514bdaa87e48b52d4074390043f19ce43ea2c4 Author: Tim Shimmin Date: Mon Oct 15 13:18:59 2007 +1000 [XFS] Put back the QUEUE_ORDERED_NONE test in the barrier check. Put back the QUEUE_ORDERED_NONE test which caused us grief in sles when it was taken out as, IIRC, it allowed md/lvm to be thought of as supporting barriers when they weren't in some configurations. This patch will be reverting what went in as part of a change for the SGI-pv 964544 (SGI-Modid: xfs-linux-melb:xfs-kern:28568a). SGI-PV: 971783 SGI-Modid: xfs-linux-melb:xfs-kern:29882a Signed-off-by: Tim Shimmin Signed-off-by: David Chinner commit bebf963fec2f319d162c18d06b6592f572c9c101 Author: Lachlan McIlroy Date: Mon Oct 15 13:18:02 2007 +1000 [XFS] Turn off XBF_ASYNC flag before re-reading superblock. SGI-PV: 971603 SGI-Modid: xfs-linux-melb:xfs-kern:29871a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit e893bffd4cf2f000f3058319eea5abeeb1755969 Author: Lachlan McIlroy Date: Fri Oct 12 11:13:35 2007 +1000 [XFS] avoid race in sync_inodes() that can fail to write out all dirty data In xfs_fs_sync_super() treat a sync the same as a filesystem freeze. This is needed to force the log to disk for inodes which are not marked dirty in the Linux inode (the inodes are marked dirty on completion of the log I/O) and so sync_inodes() will not flush them. In xfs_fs_write_inode() a synchronous flush will not get an EAGAIN from xfs_inode_flush() and if an asynchronous flush returns EAGAIN we should pass it on to the caller. If we get an error while flushing the inode then re-dirty it so we can try again later. SGI-PV: 971670 SGI-Modid: xfs-linux-melb:xfs-kern:29860a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit c2cba57e83dd7d2dda4ec425998b536669632c82 Author: Lachlan McIlroy Date: Fri Oct 12 11:12:20 2007 +1000 [XFS] This fix prevents bulkstat from spinning in an infinite loop. Here 'agino' increments through the inodes in an allocation group. At the end of the innermost 'for' loop it will hold the value of the next inode to look at (ie the first inode in the next cluster/chunk). Assigning 'lastino' to 'agino' resets it to the last inode in the last inode cluster we just looked at. This causes us to look up the very same cluster and examine all the inodes all over again, and again, and again... We also want to set 'lastino' for the cases when we're not interested in the inode so that the next call to bulkstat won't re-examine the same uninteresting inodes. SGI-PV: 971064 SGI-Modid: xfs-linux-melb:xfs-kern:29840a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 3e5daf05a0c7cce36dc2db41933b14b36d2048dc Author: Christoph Hellwig Date: Thu Oct 11 18:09:12 2007 +1000 [XFS] simplify xfs_create/mknod/symlink prototype Simplify the prototype for xfs_create/xfs_mkdir/xfs_symlink by not passing down a bhv_vattr_t that just hogs stack space. Instead pass down the mode in a mode_t and in case of xfs_create the rdev as a scalar type as well. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29794a Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit c83bfab1faec9c32297d2079c06adaaaea2650d9 Author: Christoph Hellwig Date: Thu Oct 11 17:47:00 2007 +1000 [XFS] avoid xfs_getattr in XFS_IOC_FSGETXATTR ioctl No need to call into xfs_getattr and put a big bhv_vattr_t on the stack just to get a little information from the XFS inode. Add a helper called xfs_ioc_fsgetxattr instead that deals with retrieving the information in a clean way. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29780a Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 859d718279b6e1d6bc27a701db47c1be720b5907 Author: Vlad Apostolov Date: Thu Oct 11 17:44:18 2007 +1000 [XFS] get_bulkall() could return incorrect inode state In the following scenario xfs_bulkstat() returns incorrect stale inode state: 1. File_A is created and its inode synced to disk. 2. File_A is unlinked and doesn't exist anymore. 3. Filesystem sync is invoked. 4. File_B is created. File_B happens to reclaim File_A's inode. 5. xfs_bulkstat() is called and detects File_B but reports the incorrect File_A inode state. Explanation for the incorrect inode state is that inodes are not immediately synced on file create for performance reasons. This leaves the on-disk inode buffer uninitialized (or with old state from a previous generation inode) and this is what xfs_bulkstat() would report. The patch marks the on-disk inode buffer "dirty" on unlink. When the inode is reclaimed (by a new file create), xfs_bulkstat() would filter this inode by the "dirty" mark. Once the inode is flushed to disk, the on-disk buffer "dirty" mark is automatically removed and a following xfs_bulkstat() would return the correct inode state. Marking the on-disk inode buffer "dirty" on unlink is achieved by setting the on-disk di_nlink field to 0. Note that the in-core di_nlink has already been set to 0 and a corresponding transaction logged by xfs_droplink(). This is an exception from the rule that any on-disk inode buffer changes has to be followed by a disk write (inode flush). Synchronizing the in-core to on-disk di_nlink values in advance (before the actual inode flush to disk) should be fine in this case because the inode is already unlinked and it would never change its di_nlink again for this inode generation. SGI-PV: 970842 SGI-Modid: xfs-linux-melb:xfs-kern:29757a Signed-off-by: Vlad Apostolov Signed-off-by: Alex Elder Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Mark Goodwin Signed-off-by: Tim Shimmin commit ba532a980b7dcccf5eebd2cd409a9cb37faa2bb4 Author: Christoph Hellwig Date: Wed Sep 19 15:27:18 2007 +1000 [XFS] Kill unused IOMAP_EOF flag SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29705a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 574342f4ad450b33bc85ec53210b8aa8bfff2fcf Author: Vlad Apostolov Date: Fri Sep 14 15:23:44 2007 +1000 [XFS] fix when DMAPI mount option processing happens Fix for a regression caused by a recent patch that moved the DMAPI mount option processing inside xfs_parseargs(). The DMAPI mount option used to be processed in the DMAPI module loaded before xfs_parseargs() was invoked. SGI-PV: 970451 SGI-Modid: xfs-linux-melb:xfs-kern:29683a Signed-off-by: Vlad Apostolov Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 5903c4956f7b429f515ba107d9c04bbbe7ce8f9d Author: Lachlan McIlroy Date: Fri Sep 14 15:22:08 2007 +1000 [XFS] ensure file size is logged on synchronous writes Synchronous writes currently log inode changes before syncing pages to disk. Since the file size is updated on I/O completion we wont be writing out the updated file size and if we crash the file will have the wrong size. This change moves the logging after the syncing of the pages to ensure we log the correct file size. SGI-PV: 970334 SGI-Modid: xfs-linux-melb:xfs-kern:29649a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit cc92e7ac8d96418d99f0c31a9a132e9fccc54553 Author: Christoph Hellwig Date: Thu Aug 30 17:21:54 2007 +1000 [XFS] growlock should be a mutex m_growlock only needs plain binary mutex semantics, so use a struct mutex instead of a semaphore for it. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29512a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 0adba5363ccbee073f127feb1d6942e64ee63ab3 Author: Christoph Hellwig Date: Thu Aug 30 17:21:46 2007 +1000 [XFS] replace some large xfs_log_priv.h macros by proper functions ... or in the case of XLOG_TIC_ADD_OPHDR remove a useless macro entirely. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29511a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit b267ce9952374c51099f21d6c3a59c78fa0d7586 Author: Christoph Hellwig Date: Thu Aug 30 17:21:30 2007 +1000 [XFS] kill struct bhv_vfs Now that struct bhv_vfs doesn't have any members left we can kill it and go directly from the super_block to the xfs_mount everywhere. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29509a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 743944967021f3759d3540b0dfbc7ee7215bc4b0 Author: Christoph Hellwig Date: Thu Aug 30 17:21:22 2007 +1000 [XFS] move syncing related members from struct bhv_vfs to struct xfs_mount SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29508a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit bd186aa901c183d6e25257711b6c64b42a90dde0 Author: Christoph Hellwig Date: Thu Aug 30 17:21:12 2007 +1000 [XFS] kill the vfs_flags member in struct bhv_vfs All flags are added to xfs_mount's m_flag instead. Note that the 32bit inode flag was duplicated in both of them, but only cleared in the mount when it was not nessecary due to the filesystem beeing small enough. Two flags are still required here - one to indicate the mount option setting, and one to indicate if it applies or not. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29507a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 0ce4cfd4f7dde5891d5b3e3c1a28ff7a7b4d36b3 Author: Christoph Hellwig Date: Thu Aug 30 17:20:53 2007 +1000 [XFS] kill the vfs_fsid and vfs_altfsid members in struct bhv_vfs vfs_altfsid was just a pointer to mp->m_fixedfsid so we can trivially replace it with the latter. vfs_fsid also was identical to m_fixedfsid through rather obfuscated ways so we can kill it as well and simply its only user. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29506a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 745f691912b700ac98607b525f3c892204c7f12f Author: Christoph Hellwig Date: Thu Aug 30 17:20:39 2007 +1000 [XFS] call common xfs vfs-level helpers directly and remove vfs operations Also remove the now dead behavior code. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29505a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 48c872a9f3ec4cdc37801aae9ef16c80026503ea Author: Christoph Hellwig Date: Thu Aug 30 17:20:31 2007 +1000 [XFS] decontaminate vfs operations from behavior details All vfs ops now take struct xfs_mount pointers and the behaviour related glue is split out into methods of its own. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29504a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit b09cc77109dbf33463480952de10511a2b67bba6 Author: Christoph Hellwig Date: Thu Aug 30 17:19:57 2007 +1000 [XFS] remove dependency of the quota module on behaviors Mount options are now parsed by the main XFS module and rejected if quota support is not available, and there are some new quota operation for the quotactl syscall and calls to quote in the mount, unmount and sync callchains. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29503a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 293688ec420f1160ed93ea4c7948ed5baf8bafa7 Author: Christoph Hellwig Date: Wed Aug 29 11:59:36 2007 +1000 [XFS] remove dependency of the dmapi module on behaviors Mount options are now parsed by the main XFS module and rejected if dmapi support is not available, and there is a new dm operation to send the mount event. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29502a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit f541d270dbce375b7bd8cef466bdaf0cff945b45 Author: Christoph Hellwig Date: Wed Aug 29 11:53:22 2007 +1000 [XFS] move freeing the mount structure from xfs_mount_free into the callers In the next patch we need to look at the mount structure until just before it's freed, so we need to be able to free it as the very last thing in xfs_unmount. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29501a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 0a74cd1964501fdb577176f14ed3d02b8e148127 Author: Christoph Hellwig Date: Wed Aug 29 11:53:12 2007 +1000 [XFS] kill struct bhv_vnode Now that struct bhv_vnode is empty we can just kill it. Retain bhv_vnode_t as a typedef for struct inode for the time being until all the fallout is cleaned up. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29500a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 2aeaa258c0527026228c43148ec6dffdc56bea1c Author: Christoph Hellwig Date: Wed Aug 29 11:46:57 2007 +1000 [XFS] kill the v_number member in struct bhv_vnode It's entirely unused except for ignored arguments in the mrlock initialization, so remove it. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29499a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 1543d79c45a374f934f95ca34d87e2eeeb2039b4 Author: Christoph Hellwig Date: Wed Aug 29 11:46:47 2007 +1000 [XFS] move v_trace from bhv_vnode to xfs_inode struct bhv_vnode is on it's way out, so move the trace buffer to the XFS inode. Note that this makes the tracing macros rather misnamed, but this kind of fallout will be fixed up incrementally later on. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29498a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit b677c210cec0d6755335ffc01691982c417dd39e Author: Christoph Hellwig Date: Wed Aug 29 11:46:28 2007 +1000 [XFS] move v_iocount from bhv_vnode to xfs_inode struct bhv_vnode is on it's way out, so move the I/O count to the XFS inode. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29497a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 09262b4339de5417a10803fbfac277eebb38ca5a Author: Christoph Hellwig Date: Wed Aug 29 11:44:50 2007 +1000 [XFS] Create xfs_iflags_test_and_clear helper function SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29496a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit b3aea4edc2903fdee34920630b8b2433f6452f02 Author: Christoph Hellwig Date: Wed Aug 29 11:44:37 2007 +1000 [XFS] kill the v_flag member in struct bhv_vnode All flags previously handled at the vnode level are not in the xfs_inode where we already have a flags mechanisms and free bits for flags previously in the vnode. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29495a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 2f6f7b3d9b5600e1f6e7622c62ab30f36bd0f57f Author: Christoph Hellwig Date: Wed Aug 29 11:44:18 2007 +1000 [XFS] kill v_vfsp member from struct bhv_vnode We can easily get at the vfsp through the super_block but it will soon be gone anyway. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29494a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 739bfb2a7dfa369324f74aad1d020d6e0775e4f0 Author: Christoph Hellwig Date: Wed Aug 29 10:58:01 2007 +1000 [XFS] call common xfs vnode-level helpers directly and remove vnode operations SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29493a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 993386c19afa53fa54d00c7721e56ba820b3400d Author: Christoph Hellwig Date: Tue Aug 28 16:12:30 2007 +1000 [XFS] decontaminate vnode operations from behavior details All vnode ops now take struct xfs_inode pointers and the behaviour related glue is split out into methods of it's own. This required fixing xfs_create/mkdir/symlink to not mess with the inode pointer but rather use a separate boolean for error handling. Thanks to Dave Chinner for that fix. SGI-PV: 969608 SGI-Modid: xfs-linux-melb:xfs-kern:29492a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit b93bd20cd59eb7ec172f95d08b100fea688d8bcf Author: Vlad Apostolov Date: Tue Aug 28 14:00:28 2007 +1000 [XFS] do not have XFSMNT_IDELETE as default when mounted with XFSMNT_DMAPI XFS inodes are dynamically allocated on demand, rather than being allocated at mkfs time. Chunks of 64 inodes are allocated at once, but they are never freed. Over time, this can lead to filesystem fragmentation, clusters of inodes and the btrees which point at them can be scattered around the system. By freeing clusters as they are emptied, we will reduce fragmentation of the free space after removing files. This in turn will allow us to make better placement decisions when repopulating a filesystem. The XFSMNT_IDELETE mount option enables freeing clusters when they get empty. Unfortunately a side effect of freeing inode clusters is that the inode generation numbers of such inodes would be reset to zero when the cluster is reclaimed. This is a problem in particular for a DMAPI enabled filesystem as the the DMAPI handles need to be unique and persistent in time. An unique DMAPI handle is built with the help of the inode generation number. When the last one is prematurely reset by an inode cluster reclaim, there is a high probability of different generation inodes to end up having identical DMAPI handles. To avoid the problem with identical DMAPI handles, the XFSMNT_IDELETE mount option should be set as default, only if the filesystem is not mounted with XFSMNT_DMAPI. SGI-PV: 969192 SGI-Modid: xfs-linux-melb:xfs-kern:29486a Signed-off-by: Vlad Apostolov Signed-off-by: David Chinner Signed-off-by: Mark Goodwin Signed-off-by: Tim Shimmin commit da353b0d64e070ae7c5342a0d56ec20ae9ef5cfb Author: David Chinner Date: Tue Aug 28 14:00:13 2007 +1000 [XFS] Radix tree based inode caching One of the perpetual scaling problems XFS has is indexing it's incore inodes. We currently uses hashes and the default hash sizes chosen can only ever be a tradeoff between memory consumption and the maximum realistic size of the cache. As a result, anyone who has millions of inodes cached on a filesystem needs to tunes the size of the cache via the ihashsize mount option to allow decent scalability with inode cache operations. A further problem is the separate inode cluster hash, whose size is based on the ihashsize but is smaller, and so under certain conditions (sparse cluster cache population) this can become a limitation long before the inode hash is causing issues. The following patchset removes the inode hash and cluster hash and replaces them with radix trees to avoid the scalability limitations of the hashes. It also reduces the size of the inodes by 3 pointers.... SGI-PV: 969561 SGI-Modid: xfs-linux-melb:xfs-kern:29481a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit 39cd9f877e63ce7e02cdc7f5dbf1b908451c9532 Author: Christoph Hellwig Date: Tue Aug 28 13:59:21 2007 +1000 [XFS] kill move.[ch] Kill uio related functions and defines now that they're unused. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29480a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 804c83c37607efe415774c3a170ad72a789e5992 Author: Christoph Hellwig Date: Tue Aug 28 13:59:03 2007 +1000 [XFS] stop using uio in the readlink code Simplify the readlink code to get rid of the last user of uio. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29479a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b Author: Christoph Hellwig Date: Tue Aug 28 13:58:24 2007 +1000 [XFS] use filldir internally Currently xfs has a rather complicated internal scheme to allow for different directory formats in IRIX. This patch rips all code related to this out and pushes useage of the Linux filldir callback into the lowlevel directory code. This does not make the code any less portable because filldir can be used to create dirents of all possible variations (including the IRIX ones as proved by the IRIX binary emulation code under arch/mips/). This patch get rid of an unessecary copy in the readdir path, about 400 lines of code and one of the last two users of the uio structure. This version is updated to deal with dmapi aswell which greatly simplifies the get_dirattrs code. The dmapi part has been tested using the get_dirattrs tools from the xfstest dmapi suite1 with various small and large directories. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29478a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 2bdf7cd0baa67608ada1517a281af359faf4c58c Author: Christoph Hellwig Date: Tue Aug 28 13:58:06 2007 +1000 [XFS] superblock endianess annotations Creates a new xfs_dsb_t that is __be annotated and keeps xfs_sb_t for the incore one. xfs_xlatesb is renamed to xfs_sb_to_disk and only handles the incore -> disk conversion. A new helper xfs_sb_from_disk handles the other direction and doesn't need the slightly hacky table-driven approach because we only ever read the full sb from disk. The handling of shared r/o filesystems has been buggy on little endian system and fixing this required shuffling around of some code in that area. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29477a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 347d1c01956d567c18afef0cc253eb235cafacd8 Author: Christoph Hellwig Date: Tue Aug 28 13:57:51 2007 +1000 [XFS] dinode endianess annotations Biggest bit is duplicating the dinode structure so we have one annotated for native endianess and one for disk endianess. The other significant change is that xfs_xlate_dinode_core is split into one helper per direction to allow for proper annotations, everything else is trivial. As a sidenode splitting out the incore dinode means we can move it into xfs_inode.h in a later patch and severely improving on the include hell in xfs. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29476a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit ddc6d3b32a8a732c343dc225048fae06c129e48a Author: Michal Piotrowski Date: Thu Aug 23 16:20:10 2007 +1000 [XFS] Fix build regression from mod/commit which did cleanup of xfs_bmbt_*set_allf In sgi mod# xfs-linux-melb:xfs-kern:29319a, the variable renaming was not complete and variable 'b' was left unchanged for non-lbd 32 bit machines. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29469a Signed-off-by: Michal Piotrowski Signed-off-by: Tim Shimmin commit 948c6d4fd894d9c7f9ad764cedbe443aa866def2 Author: Eric Sandeen Date: Thu Aug 23 16:19:57 2007 +1000 [XFS] optimize dmapi event tests w/o dmapi config SGI-PV: 969372 SGI-Modid: xfs-linux-melb:xfs-kern:29444a Signed-off-by: Eric Sandeen Signed-off-by: Vlad Apostolov Signed-off-by: Tim Shimmin commit eb9df39daf870d6f9e9528f092d506be04ebad2f Author: Christoph Hellwig Date: Thu Aug 16 18:42:07 2007 +1000 [XFS] remove unessecary vfs argument to DM_EVENT_ENABLED SGI-PV: 968690 SGI-Modid: xfs-linux-melb:xfs-kern:29340a Signed-off-by: Christoph Hellwig Signed-off-by: Vlad Apostolov Signed-off-by: Tim Shimmin commit 49ee6c911f0ae5b3a9a04e0589e3265e52f94f53 Author: Jesper Juhl Date: Thu Aug 16 16:25:42 2007 +1000 [XFS] Fix a potential NULL pointer deref in XFS on failed mount. If we fail to open the the log device buftarg, we can fall through to error handling code that fails to check for a NULL log device buftarg before calling xfs_free_buftarg(). This patch fixes the issue by checking mp->m_logdev_targp against NULL in xfs_unmountfs_close() and doing the proper xfs_blkdev_put(logdev); and xfs_blkdev_put(rtdev); on (!mp->m_rtdev_targp) in xfs_mount(). Discovered by the Coverity checker. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29328a Signed-off-by: Jesper Juhl Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit dcb3b83febd1028afbc4a32cf7642a6580e349c6 Author: Eric Sandeen Date: Thu Aug 16 16:25:33 2007 +1000 [XFS] clean up xfs_start_flags xfs_start_flags can make use of is_power_of_2 to tidy up the test a little bit. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29327a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit af3a2e8a3f3055ef269b09433bb28e33a0d1b8c0 Author: Eric Sandeen Date: Thu Aug 16 16:25:23 2007 +1000 [XFS] move linux/log2.h header to xfs_linux.h Generally we try not to directly include linux header files in core xfs code; xfs_linux.h is the spot for that. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29326a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 6385f4d5579ccada7bd1d9fefbdea5515457b10d Author: Eric Sandeen Date: Thu Aug 16 16:25:10 2007 +1000 [XFS] Remove xfs_physmem Now that nobody's using it, remove xfs_physmem & friends. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29325a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 425f9ddd534573f58df8e7b633a534fcfc16d44d Author: Eric Sandeen Date: Thu Aug 16 16:24:55 2007 +1000 [XFS] Pick a single default inode cluster size. Remove scaling of inode "clusters" based on machine memory; small cluster cut-point was an unrealistic 32MB and was probably never tested. Removes another user of xfs_physmem. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29324a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 1cb51258758d725028e9ee9688d462de125a053d Author: Eric Sandeen Date: Thu Aug 16 16:24:43 2007 +1000 [XFS] choose single default logbuf count & size Remove sizing of logbuf size & count based on physical memory; this was never a very good gauge as it's looking at global memory, but deciding on sizing per-filesystem; no account is made of the total number of filesystems, for example. For now just take the largest "default" case, as was set for machines with >400MB - 8 x 32k buffers. This can always be tuned higher or lower with mount options if necessary. Removes one more user of xfs_physmem. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29323a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 40906630f18fdf5ac27f5928c20f76eeac8fb0f0 Author: Eric Sandeen Date: Thu Aug 16 16:24:31 2007 +1000 [XFS] Remove m_nreadaheads m_nreadaheads in the mount struct is never used; remove it and the various macros assigned to it. Also remove a couple other unused macros in the same areas. Removes one user of xfs_physmem. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29322a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit cd8b0a97bd9216578a44a9bf82188cd901295964 Author: Christoph Hellwig Date: Thu Aug 16 16:24:15 2007 +1000 [XFS] endianess annotations for xfs_bmbt_rec_t SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29321a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit e05596643d4bb5ab7d813d1ac5724178ca4c7134 Author: Christoph Hellwig Date: Thu Aug 16 16:24:02 2007 +1000 [XFS] cleanup defintions of BMBT_*BITLEN macros The BMBT_*BITLEN are currently defined in a complicated way depending on XFS_NATIVE_HOST. But if all the macros are expanded they (obviously) expand to the same value for both cases. This patch defines the macros in the most simple way and updates the comment describing them to remove outdated bits. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29320a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 8cba43447e7a843cd446a73baa91fe686f01e565 Author: Christoph Hellwig Date: Thu Aug 16 16:23:53 2007 +1000 [XFS] clean up xfs_bmbt_set_all/xfs_bmbt_disk_set_all xfs_bmbt_set_all/xfs_bmbt_disk_set_all are identical to xfs_bmbt_set_allf/xfs_bmbt_disk_set_allf except that the former take a xfs_bmbt_irec_t and the latter take the individual extent fields as scalar values. This patch reimplements xfs_bmbt_set_all/xfs_bmbt_disk_set_all as trivial wrappers around xfs_bmbt_set_allf/xfs_bmbt_disk_set_allf and cleans up the variable naming in xfs_bmbt_set_allf/xfs_bmbt_disk_set_allf to have some meaning instead of one char variable names. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29319a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit a6f64d4aea0d0c8483e910c7dd2d1ee48e42245c Author: Christoph Hellwig Date: Thu Aug 16 16:23:40 2007 +1000 [XFS] split ondisk vs incore versions of xfs_bmbt_rec_t currently xfs_bmbt_rec_t is used both for ondisk extents as well as host-endian ones. This patch adds a new xfs_bmbt_rec_host_t for the native endian ones and cleans up the fallout. There have been various endianess issues in the tracing / debug printf code that are fixed by this patch. SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29318a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit d580ef6eaae6eaaef1e06c7d689fc9949faee9da Author: Christoph Hellwig Date: Thu Aug 16 16:23:11 2007 +1000 [XFS] remove confusing INT_ comments in xfs_bmap_btree.c SGI-PV: 968563 SGI-Modid: xfs-linux-melb:xfs-kern:29317a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 3bacbcd8830f89fc527f5c7dc13f24d0ce692980 Author: Vlad Apostolov Date: Thu Aug 16 15:20:25 2007 +1000 [XFS] hole not shown when file is created with resvsp SGI-PV: 967674 SGI-Modid: xfs-linux-melb:xfs-kern:29211a Signed-off-by: Vlad Apostolov Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 0bfefc46dc028df60120acdb92062169c9328769 Author: David Chinner Date: Mon May 14 18:24:23 2007 +1000 [XFS] Barriers need to be dynamically checked and switched off If the underlying block device suddenly stops supporting barriers, we need to handle the -EOPNOTSUPP error in a sane manner rather than shutting down the filesystem. If we get this error, clear the barrier flag, reissue the I/O, and tell the world bad things are occurring. SGI-PV: 964544 SGI-Modid: xfs-linux-melb:xfs-kern:28568a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin From owner-xfs@oss.sgi.com Wed Oct 17 09:15:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 09:15:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HGF667028929 for ; Wed, 17 Oct 2007 09:15:08 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 5FE0D301C603 for ; Wed, 17 Oct 2007 18:15:08 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8b8pMjF+2qW for ; Wed, 17 Oct 2007 18:15:08 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 3CCCE300EB21 for ; Wed, 17 Oct 2007 18:15:08 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id AD82EF08D9018 for ; Wed, 17 Oct 2007 18:15:04 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 8E8EF24CAEDA; Wed, 17 Oct 2007 18:15:04 +0200 (CEST) Date: Wed, 17 Oct 2007 18:15:04 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071017161504.GA13077@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EA9741.6060303@sandeen.net> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13364 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote: > Louis-David Mitterrand wrote: > > Hello, > > > > While cleaning up /lost+found a directory resisted removal: > > > > sylla:/lost+found# rm 1879629858 -rf > > rm: cannot remove directory `1879629858': Directory not empty > > > > The directory _is_ empty and "-rf" should remove it anyway, so this > > looks like a fs error. > > > > This is on debian unstable with 2.6.23-rc6. > > Any errors in the system logs? I'd try most recent xfs_repair next. If > that doesn't fix it, make an xfs_metadump for Barry to look at. :) > Make a backup first if you're paranoid. Hi again, Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't remove that file: sylla:/# rm /lost+found/3912672557 rm: cannot remove `/lost+found/3912672557': Operation not permitted sylla:/# ls -li /lost+found/3912672557 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz From owner-xfs@oss.sgi.com Wed Oct 17 09:15:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 09:15:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from mail.pawisda.de (mail.pawisda.de [213.157.4.156]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HGFeIw029237 for ; Wed, 17 Oct 2007 09:15:43 -0700 Received: from localhost (localhost.intra.frontsite.de [127.0.0.1]) by mail.pawisda.de (Postfix) with ESMTP id B1EF6F161 for ; Wed, 17 Oct 2007 17:48:43 +0200 (CEST) Received: from mail.pawisda.de ([127.0.0.1]) by localhost (ndb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19122-03 for ; Wed, 17 Oct 2007 17:48:37 +0200 (CEST) Received: from [192.168.51.2] (lw-pc002.intra.frontsite.de [192.168.51.2]) by mail.pawisda.de (Postfix) with ESMTP id B86E8E822 for ; Wed, 17 Oct 2007 17:48:37 +0200 (CEST) Message-ID: <47162ED4.6000108@linworks.de> Date: Wed, 17 Oct 2007 17:48:36 +0200 From: Ruben Porras User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: "xfs@oss.sgi.com" Subject: Re: REVIEW: xfs_reno #2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Scanned: by amavisd-new at pawisda.de X-Virus-Status: Clean X-archive-position: 13365 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben.porras@linworks.de Precedence: bulk X-list: xfs Barry Naujok wrote: > A couple changes from the first xfs_reno: > > - Major one is that symlinks are now supported, but only > owner, group and extended attributes are copied for them > (not times or inode attributes). > > - Man page! > > > To make this better, ideally we need some form of > "swap inodes" function in the kernel, where the entire > contents of the inode themselves are swapped. This form > can handle any inode and without any of the dir/file/attr/etc > copy/swap mechanisms we have in xfs_reno. > If everything goes as planned I will have time next month to look at xfs_reno. -- Rubén Porras LinWorks GmbH From owner-xfs@oss.sgi.com Wed Oct 17 09:18:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 09:19:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HGIuht030520 for ; Wed, 17 Oct 2007 09:18:58 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id B03401C000264; Wed, 17 Oct 2007 12:18:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id AB3234019581; Wed, 17 Oct 2007 12:18:58 -0400 (EDT) Date: Wed, 17 Oct 2007 12:18:58 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Louis-David Mitterrand cc: linux-xfs@oss.sgi.com Subject: Re: can't remove dir In-Reply-To: <20071017161504.GA13077@apartia.fr> Message-ID: References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13366 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 On Wed, 17 Oct 2007, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote: >> Louis-David Mitterrand wrote: >>> Hello, >>> >>> While cleaning up /lost+found a directory resisted removal: >>> >>> sylla:/lost+found# rm 1879629858 -rf >>> rm: cannot remove directory `1879629858': Directory not empty >>> >>> The directory _is_ empty and "-rf" should remove it anyway, so this >>> looks like a fs error. >>> >>> This is on debian unstable with 2.6.23-rc6. >> >> Any errors in the system logs? I'd try most recent xfs_repair next. If >> that doesn't fix it, make an xfs_metadump for Barry to look at. :) >> Make a backup first if you're paranoid. > > Hi again, > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > remove that file: > > sylla:/# rm /lost+found/3912672557 > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > sylla:/# ls -li /lost+found/3912672557 > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > lsattr -l /lost+found/3912672557 Shows? From owner-xfs@oss.sgi.com Wed Oct 17 09:30:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 09:30:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HGUfWc000945 for ; Wed, 17 Oct 2007 09:30:43 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 2A038300E870 for ; Wed, 17 Oct 2007 18:30:44 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTL-qjneF5ad for ; Wed, 17 Oct 2007 18:30:44 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 0AD7F300EB25 for ; Wed, 17 Oct 2007 18:30:44 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 723D7F0AF2F09 for ; Wed, 17 Oct 2007 18:30:43 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 5EE5024CAEDA; Wed, 17 Oct 2007 18:30:43 +0200 (CEST) Date: Wed, 17 Oct 2007 18:30:43 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071017163043.GA13676@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13367 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Wed, Oct 17, 2007 at 12:18:58PM -0400, Justin Piszcz wrote: >> >> Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't >> remove that file: >> >> sylla:/# rm /lost+found/3912672557 >> rm: cannot remove `/lost+found/3912672557': Operation not permitted >> >> sylla:/# ls -li /lost+found/3912672557 >> 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 >> /lost+found/3912672557 -> unix.7.gz >> > > lsattr -l /lost+found/3912672557 > > Shows? sylla:~# lsattr -l /lost+found/3912672557 lsattr: No such file or directory While reading flags on /lost+found/3912672557 The file is a dangling link. From owner-xfs@oss.sgi.com Wed Oct 17 14:08:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 14:09:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from smtp2.linux-foundation.org (smtp2.linux-foundation.org [207.189.120.14]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HL8t6X014530 for ; Wed, 17 Oct 2007 14:08:58 -0700 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l9HKoZkL025382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2007 13:50:36 -0700 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id l9HKoYre007753; Wed, 17 Oct 2007 13:50:34 -0700 Date: Wed, 17 Oct 2007 13:50:34 -0700 From: Andrew Morton To: Christoph Hellwig Cc: tes@sgi.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [GIT PULL] XFS update for 2.6.24-rc1 Message-Id: <20071017135034.0f8cc3bf.akpm@linux-foundation.org> In-Reply-To: <20071017203658.GA22073@infradead.org> References: <20071017110339.D4B3158C38F1@chook.melbourne.sgi.com> <20071017203658.GA22073@infradead.org> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13369 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Wed, 17 Oct 2007 21:36:58 +0100 Christoph Hellwig wrote: > On Wed, Oct 17, 2007 at 09:03:39PM +1000, Tim Shimmin wrote: > > Hi Linus, > > > > Please pull from the for-linus branch: > > git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus > > > > These include changes we have had scheduled for 2.6.24. > > In particular they include Christoph's (hch's) behavior removal patches. > > Can you please send my '[PATCH] cleanup fid types mess' to Linus aswell? > I have a stack of 15 patches reworking the nfs exporting code waiting > in -mm to get in in this merge window that depend on this cleanup to > free struct fid for generic useage. > > Also getting the makefile cleanup into mainline to reduce spurious difference > would help a lot. argh, -mm's *new-export*.patch has a dependency upon git-xfs's ef6567a363c5f301c0bc885068d93cd9b3c05cc9. I never knew that, but I would have found out later today... Tim, if you want I can just steal that diff out of the xfs tree and send it in separately. From owner-xfs@oss.sgi.com Wed Oct 17 14:08:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 14:08:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HL8kW5014494 for ; Wed, 17 Oct 2007 14:08:47 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IiFdS-0005l9-Me; Wed, 17 Oct 2007 21:36:58 +0100 Date: Wed, 17 Oct 2007 21:36:58 +0100 From: Christoph Hellwig To: Tim Shimmin Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: Re: [GIT PULL] XFS update for 2.6.24-rc1 Message-ID: <20071017203658.GA22073@infradead.org> Mail-Followup-To: Christoph Hellwig , Tim Shimmin , torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org References: <20071017110339.D4B3158C38F1@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017110339.D4B3158C38F1@chook.melbourne.sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13368 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 On Wed, Oct 17, 2007 at 09:03:39PM +1000, Tim Shimmin wrote: > Hi Linus, > > Please pull from the for-linus branch: > git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus > > These include changes we have had scheduled for 2.6.24. > In particular they include Christoph's (hch's) behavior removal patches. Can you please send my '[PATCH] cleanup fid types mess' to Linus aswell? I have a stack of 15 patches reworking the nfs exporting code waiting in -mm to get in in this merge window that depend on this cleanup to free struct fid for generic useage. Also getting the makefile cleanup into mainline to reduce spurious difference would help a lot. From owner-xfs@oss.sgi.com Wed Oct 17 14:24:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 14:25:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9HLOd97016928 for ; Wed, 17 Oct 2007 14:24:42 -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 HAA27422 for ; Thu, 18 Oct 2007 07:24:41 +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 l9HLOedD68989844 for ; Thu, 18 Oct 2007 07:24:41 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9HLOdOp68939488 for linux-xfs@oss.sgi.com; Thu, 18 Oct 2007 07:24:39 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 18 Oct 2007 07:24:39 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071017212434.GB995458@sgi.com> References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017161504.GA13077@apartia.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13370 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 On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > remove that file: > > sylla:/# rm /lost+found/3912672557 > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > sylla:/# ls -li /lost+found/3912672557 > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz Can you post the output of: # xfs_db -r -c "inode 3912672557" -c "p" Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Oct 17 14:33:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 14:33:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9HLXGr8018201 for ; Wed, 17 Oct 2007 14:33:18 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id E7DDB92CF4D; Thu, 18 Oct 2007 07:33:17 +1000 (EST) Received: from 192.168.3.1 (proxying for 211.28.181.43) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Thu, 18 Oct 2007 07:33:40 +1000 (EST) Message-ID: <48509.192.168.3.1.1192656820.squirrel@mail.aconex.com> Date: Thu, 18 Oct 2007 07:33:40 +1000 (EST) Subject: [Fwd: Bug#446877: attr(1) implies it only works with XFS] From: nscott@aconex.com To: bnaujok@sgi.com Cc: xfs@oss.sgi.com, agruen@suse.de, rrt@sc3d.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20071018073340_27115" X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.91.2/4543/Wed Oct 17 07:16:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13371 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs ------=_20071018073340_27115 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Barry, Could you merge this docs patch into the oss.sgi.com cvs tree please? thanks mate. ---------------------------- Original Message ---------------------------- Subject: Bug#446877: attr(1) implies it only works with XFS From: "Reuben Thomas" Date: Wed, October 17, 2007 10:47 pm To: "Nathan Scott" Cc: 446877@bugs.debian.org -------------------------------------------------------------------------- On Wed, 17 Oct 2007, Nathan Scott wrote: > All sounds good to me - please send a patch with those changes. Attached. To confirm what I've done: 0. I've replaced ".P" by ".PP", in the pages I've edited as according to groff_man(7), they are aliases for the same command, and I wasted a few minutes checking what was going on when I found them both. In attr.5, .PP was already used exclusively, whereas in attr.1 both were. 1. In attr.1, I just moved the text that was already there mentioning getfattr and setfattr further up the page (and then changed a couple of words at the start of the next paragraph to avoid ambiguity). 2. In attr.5, I removed the links to filesystem patches, mentioned ext4, JFS and reiserfs, and, lower down, added details of their attribute support. I removed implementation details, so that I could for example refer to XFS and reiserfs in the same paragraph, removed the hope that ext2/3/4's limits would one day be raised (since the relevant code is still the same in ext4 as it was in ext2!), but also removed the erroneous implication that all extended attributes must fit on a single disk block in those FSes (in fact, *each* must fit on a single disk block, so in practice, for small tags of the sort given in the examples, any of the file systems is fine). -- http://rrt.sc3d.org/ | golf, n. a good walk spoiled (Twain) ------=_20071018073340_27115 Content-Type: text/x-diff; name="attr-man.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="attr-man.patch" diff -Nur attr-2.4.39/man/man1/attr.1 attr-2.4.39-rrt/man/man1/attr.1 --- attr-2.4.39/man/man1/attr.1 2007-09-11 03:00:50.000000000 +0100 +++ attr-2.4.39-rrt/man/man1/attr.1 2007-10-17 13:26:49.000000000 +0100 @@ -16,12 +16,6 @@ .SH OVERVIEW Extended attributes implement the ability for a user to attach name:value pairs to objects within the XFS filesystem. -.P -They could be used to store meta-information about the file. -For example "character-set=kanji" could tell a document browser to -use the Kanji character set when displaying that document -and "thumbnail=..." could provide a reduced resolution overview of a -high resolution graphic image. .PP This document describes the .I attr @@ -32,7 +26,13 @@ and .IR setfattr (1) documentation. -.P +.PP +Extended attributes can be used to store meta-information about the file. +For example "character-set=kanji" could tell a document browser to +use the Kanji character set when displaying that document +and "thumbnail=..." could provide a reduced resolution overview of a +high resolution graphic image. +.PP In the XFS filesystem, the .I names can be up to 256 bytes in length, terminated by the first 0 byte. @@ -41,10 +41,10 @@ The .I values can be up to 64KB of arbitrary binary data. -.P +.PP Attributes can be attached to all types of XFS inodes: regular files, directories, symbolic links, device nodes, etc. -.P +.PP XFS uses 2 disjoint attribute name spaces associated with every filesystem object. They are the diff -Nur attr-2.4.39/man/man5/attr.5 attr-2.4.39-rrt/man/man5/attr.5 --- attr-2.4.39/man/man5/attr.5 2007-09-11 03:00:50.000000000 +0100 +++ attr-2.4.39-rrt/man/man5/attr.5 2007-10-17 13:35:41.000000000 +0100 @@ -32,12 +32,8 @@ Space consumed for extended attributes is counted towards the disk quotas of the file owner and file group. .PP -Currently, support for extended attributes is implemented on Linux by -the ext2, ext3 and XFS filesystem patches, which can be downloaded from -.B http://acl.bestbits.at/ -and -.B http://oss.sgi.com/projects/xfs/ -respectively. +Currently, support for extended attributes is implemented on Linux by the +ext2, ext3, ext4, XFS, JFS and reiserfs filesystems. .SH EXTENDED ATTRIBUTE NAMESPACES Attribute names are zero-terminated strings. The attribute name is always specified in the fully qualified @@ -106,16 +102,23 @@ .SH FILESYSTEM DIFFERENCES The kernel and the filesystem may place limits on the maximum number and size of extended attributes that can be associated with a file. +Some file systems, such as ext2/3 and reiserfs, require the filesystem +to be mounted with the +.B user_xattr +mount option in order for extended user attributes to be used. +.PP +In the current ext2, ext3 and ext4 filesystem implementations, each +extended attribute must fit on a single filesystem block (1024, 2048 +or 4096 bytes, depending on the block size specified when the +filesystem was created). +.PP +In the XFS and reiserfs filesystem implementations, there is no +practical limit on the number or size of extended attributes +associated with a file, and the algorithms used to store extended +attribute information on disk are scalable. .PP -In the current ext2 and ext3 filesystem implementations, all extended -attributes must fit on a single filesystem block (1024, 2048 or 4096 bytes, -depending on the block size specified when the filesystem -was created). This limit may be removed in a future version. -.PP -In the XFS filesystem implementation, there is no practical limit on the -number of extended attributes associated with a file, and the algorithms -used to store extended attribute information on disk are scalable (stored -either inline in the inode, as an extent, or in a B+ tree). +In the JFS filesystem implementation, names can be up to 255 bytes and +values up to 65,535 bytes. .SH ADDITIONAL NOTES Since the filesystems on which extended attributes are stored might also be used on architectures with a different byte order and machine word ------=_20071018073340_27115-- From owner-xfs@oss.sgi.com Wed Oct 17 18:37:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 18:37:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I1bWhJ006524 for ; Wed, 17 Oct 2007 18:37:34 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 LAA04444; Thu, 18 Oct 2007 11:37:30 +1000 Date: Thu, 18 Oct 2007 11:37:45 +1000 To: "Louis-David Mitterrand" , linux-xfs@oss.sgi.com Subject: Re: can't remove dir From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20071017161504.GA13077@apartia.fr> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13372 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Thu, 18 Oct 2007 02:15:04 +1000, Louis-David Mitterrand wrote: > On Fri, Sep 14, 2007 at 09:14:25AM -0500, Eric Sandeen wrote: >> Louis-David Mitterrand wrote: >> > Hello, >> > >> > While cleaning up /lost+found a directory resisted removal: >> > >> > sylla:/lost+found# rm 1879629858 -rf >> > rm: cannot remove directory `1879629858': Directory not empty >> > >> > The directory _is_ empty and "-rf" should remove it anyway, so this >> > looks like a fs error. >> > >> > This is on debian unstable with 2.6.23-rc6. >> >> Any errors in the system logs? I'd try most recent xfs_repair next. If >> that doesn't fix it, make an xfs_metadump for Barry to look at. :) >> Make a backup first if you're paranoid. > > Hi again, > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > remove that file: > > sylla:/# rm /lost+found/3912672557 > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > sylla:/# ls -li /lost+found/3912672557 > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 > /lost+found/3912672557 -> unix.7.gz Can you apply the patch in http://oss.sgi.com/archives/xfs/2007-09/msg00222.html and run the patched repair on your filesytem? Barry. From owner-xfs@oss.sgi.com Wed Oct 17 20:48:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 20:48:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I3lvlZ030868 for ; Wed, 17 Oct 2007 20:48:00 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07885; Thu, 18 Oct 2007 13:47:48 +1000 Message-ID: <4716D891.1060108@sgi.com> Date: Thu, 18 Oct 2007 13:52:49 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Utako Kusaka , xfs@oss.sgi.com Subject: Re: [PATCH] flush inode when changing atime. References: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> <20071017090844.GZ995458@sgi.com> In-Reply-To: <20071017090844.GZ995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13373 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Oct 17, 2007 at 01:56:00PM +0900, Utako Kusaka wrote: >> Hi, >> >> The atime is changed for reading but it returns to a previous value >> after unmount. i_update_core is still off after reading a file using >> read(), readdir() and readlink(). So an inode isn't flushed to disk. > > I think this was done by design - Christoph? I can't remember exactly > as it was more than two years ago this change was made. It is effectively > equivalent to using the relatime mount option. > > The question is whether we want to change the default behaviour or > whether we need to supply an "atimeisatime" mount option for those > that really need atime to be updated on every access. > If we change it back then will anything that scans the filesystem cause inodes to be dirtied and create a lot of inode flush traffic that we don't currently have? >> I referred to following fix when I made a patch: >> TAKE 946679 - fix, speedup and simplify atime handling >> http://marc.info/?l=linux-xfs&m=113398234310217&w=4 > > Yes, that was the patch that removed the explicit atime updates > in the XFS code. Your fix is reverting part of that change. > >> --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-10-15 15:50:10.000000000 +0900 >> +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-10-15 16:49:35.000000000 +0900 >> @@ -1003,6 +1003,8 @@ xfs_readlink( >> error = xfs_readlink_bmap(ip, link); >> } >> >> + ip->i_update_core = 1; >> + > > If we are going to put these back in, then they should be > calls to xfs_ichgtime_fast() so that we know what the reason > for marking the core dirty is. > xfs_ichgtime_fast() will also dirty the linux inode so that sync will push out the change. From owner-xfs@oss.sgi.com Wed Oct 17 21:03:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 21:03:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I43N1P032593 for ; Wed, 17 Oct 2007 21:03:27 -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 OAA08209; Thu, 18 Oct 2007 14:03:21 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id F318C58C38F1; Thu, 18 Oct 2007 14:03:20 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: 971596 971186 - Undo mod xfs-linux-melb:xfs-kern:29845a due to a regression Message-Id: <20071018040320.F318C58C38F1@chook.melbourne.sgi.com> Date: Thu, 18 Oct 2007 14:03:20 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13374 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Undo mod xfs-linux-melb:xfs-kern:29845a due to a regression Date: Thu Oct 18 14:02:08 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-buflock Inspected by: lachlan Undoes mod: xfs-linux-melb:xfs-kern:29845a Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29902a fs/xfs/xfsidbg.c - 1.340 - changed fs/xfs/linux-2.6/xfs_buf.h - 1.122 - changed fs/xfs/linux-2.6/xfs_buf.c - 1.247 - changed From owner-xfs@oss.sgi.com Wed Oct 17 21:08:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 21:09:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I48nCF000969 for ; Wed, 17 Oct 2007 21:08:53 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08314; Thu, 18 Oct 2007 14:08:44 +1000 Message-ID: <4716DD79.6040309@sgi.com> Date: Thu, 18 Oct 2007 14:13:45 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill superflous buffer locking References: <20070924184926.GA20661@lst.de> In-Reply-To: <20070924184926.GA20661@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13375 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph, We've had to reverse this change because it's caused a regression. We haven't been able to identify why we see the following assertion trigger with these changes but the assertion goes away without the changes. Until we figure out why we'll have to leave the buffer locking in. <5>XFS mounting filesystem hdb2 <5>Starting XFS recovery on filesystem: hdb2 (logdev: internal) <4>XFS: xlog_recover_process_data: bad clientid <4>Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2912 <0>------------[ cut here ]------------ <2>kernel BUG at fs/xfs/support/debug.c:81! <0>invalid opcode: 0000 [#1] <0>SMP <4>Modules linked in: <0>CPU: 2 <0>EIP: 0060:[] Not tainted VLI <0>EFLAGS: 00010286 (2.6.23-kali-26_xfs-debug #1) <0>EIP is at assfail+0x1e/0x22 <0>eax: 00000043 ebx: f3002a50 ecx: 00000001 edx: 00000086 <0>esi: f56e2300 edi: f8fa5c28 ebp: efa67ae4 esp: efa67ad4 <0>ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 <0>Process mount (pid: 15191, ti=efa66000 task=f7b43570 task.ti=efa66000) <0>Stack: c05c8bda c05c6762 c05c4750 00000b60 efa67b1c c0269a35 00000004 c05c5903 <0> f3a14000 efa67ba8 f7e458c0 f8fa5c34 efa67bb8 f8fa6a38 0000000d 00001e00 <0> f8fa4000 00000000 efa67bf4 c026a566 f8fa4000 00000001 00000651 00000000 <0>Call Trace: <0> [] show_trace_log_lvl+0x1a/0x2f <0> [] show_stack_log_lvl+0x9b/0xa3 <0> [] show_registers+0x1b9/0x28b <0> [] die+0x119/0x27b <0> [] do_trap+0x8a/0xa3 <0> [] do_invalid_op+0x88/0x92 <0> [] error_code+0x72/0x78 <0> [] xlog_recover_process_data+0x6a/0x1ff <0> [] xlog_do_recovery_pass+0x810/0x9f3 <0> [] xlog_do_log_recovery+0x62/0xe2 <0> [] xlog_do_recover+0x1d/0x187 <0> [] xlog_recover+0x88/0x95 <0> [] xfs_log_mount+0x100/0x144 <0> [] xfs_mountfs+0x278/0x639 <0> [] xfs_mount+0x25c/0x2f7 <0> [] xfs_fs_fill_super+0xab/0x1fd <0> [] get_sb_bdev+0xd6/0x114 <0> [] xfs_fs_get_sb+0x21/0x27 <0> [] vfs_kern_mount+0x41/0x7a <0> [] do_kern_mount+0x37/0xbd <0> [] do_mount+0x566/0x5c0 <0> [] sys_mount+0x6f/0xa9 <0> [] sysenter_past_esp+0x5f/0x85 <0> ======================= <0>Code: 04 24 10 00 00 00 e8 2a e7 03 00 c9 c3 55 89 e5 83 ec 10 89 4c 24 0c 89 54 24 08 89 44 24 04 c7 04 24 da 8b 5c c0 e8 07 bf e9 ff <0f> 0b eb fe 55 83 e0 07 89 e5 57 bf 07 00 00 00 56 89 d6 53 89 <0>EIP: [] assfail+0x1e/0x22 SS:ESP 0068:efa67ad4 Lachlan Christoph Hellwig wrote: > There is no need to lock any page in xfs_buf.c because we operate > on our own address_space and all locking is covered by the buffer > semaphore. If we ever switch back to main blockdeive address_space > as suggested e.g. for fsblock with a similar scheme the locking will > have to be totally revised anyway because the current scheme is > neither correct nor coherent with itself. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.c 2007-09-23 13:28:00.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c 2007-09-23 14:13:43.000000000 +0200 > @@ -396,6 +396,7 @@ _xfs_buf_lookup_pages( > congestion_wait(WRITE, HZ/50); > goto retry; > } > + unlock_page(page); > > XFS_STATS_INC(xb_page_found); > > @@ -405,10 +406,7 @@ _xfs_buf_lookup_pages( > ASSERT(!PagePrivate(page)); > if (!PageUptodate(page)) { > page_count--; > - if (blocksize >= PAGE_CACHE_SIZE) { > - if (flags & XBF_READ) > - bp->b_locked = 1; > - } else if (!PagePrivate(page)) { > + if (blocksize < PAGE_CACHE_SIZE && !PagePrivate(page)) { > if (test_page_region(page, offset, nbytes)) > page_count++; > } > @@ -418,11 +416,6 @@ _xfs_buf_lookup_pages( > offset = 0; > } > > - if (!bp->b_locked) { > - for (i = 0; i < bp->b_page_count; i++) > - unlock_page(bp->b_pages[i]); > - } > - > if (page_count == bp->b_page_count) > bp->b_flags |= XBF_DONE; > > @@ -747,7 +740,6 @@ xfs_buf_associate_memory( > bp->b_page_count = ++i; > ptr += PAGE_CACHE_SIZE; > } > - bp->b_locked = 0; > > bp->b_count_desired = bp->b_buffer_length = len; > bp->b_flags |= XBF_MAPPED; > @@ -1093,25 +1085,13 @@ xfs_buf_iostart( > return status; > } > > -STATIC_INLINE int > -_xfs_buf_iolocked( > - xfs_buf_t *bp) > -{ > - ASSERT(bp->b_flags & (XBF_READ | XBF_WRITE)); > - if (bp->b_flags & XBF_READ) > - return bp->b_locked; > - return 0; > -} > - > STATIC_INLINE void > _xfs_buf_ioend( > xfs_buf_t *bp, > int schedule) > { > - if (atomic_dec_and_test(&bp->b_io_remaining) == 1) { > - bp->b_locked = 0; > + if (atomic_dec_and_test(&bp->b_io_remaining) == 1) > xfs_buf_ioend(bp, schedule); > - } > } > > STATIC int > @@ -1146,10 +1126,6 @@ xfs_buf_bio_end_io( > > if (--bvec >= bio->bi_io_vec) > prefetchw(&bvec->bv_page->flags); > - > - if (_xfs_buf_iolocked(bp)) { > - unlock_page(page); > - } > } while (bvec >= bio->bi_io_vec); > > _xfs_buf_ioend(bp, 1); > @@ -1161,13 +1137,12 @@ STATIC void > _xfs_buf_ioapply( > xfs_buf_t *bp) > { > - int i, rw, map_i, total_nr_pages, nr_pages; > + int rw, map_i, total_nr_pages, nr_pages; > struct bio *bio; > int offset = bp->b_offset; > int size = bp->b_count_desired; > sector_t sector = bp->b_bn; > unsigned int blocksize = bp->b_target->bt_bsize; > - int locking = _xfs_buf_iolocked(bp); > > total_nr_pages = bp->b_page_count; > map_i = 0; > @@ -1190,7 +1165,7 @@ _xfs_buf_ioapply( > * filesystem block size is not smaller than the page size. > */ > if ((bp->b_buffer_length < PAGE_CACHE_SIZE) && > - (bp->b_flags & XBF_READ) && locking && > + (bp->b_flags & XBF_READ) && > (blocksize >= PAGE_CACHE_SIZE)) { > bio = bio_alloc(GFP_NOIO, 1); > > @@ -1207,24 +1182,6 @@ _xfs_buf_ioapply( > goto submit_io; > } > > - /* Lock down the pages which we need to for the request */ > - if (locking && (bp->b_flags & XBF_WRITE) && (bp->b_locked == 0)) { > - for (i = 0; size; i++) { > - int nbytes = PAGE_CACHE_SIZE - offset; > - struct page *page = bp->b_pages[i]; > - > - if (nbytes > size) > - nbytes = size; > - > - lock_page(page); > - > - size -= nbytes; > - offset = 0; > - } > - offset = bp->b_offset; > - size = bp->b_count_desired; > - } > - > next_chunk: > atomic_inc(&bp->b_io_remaining); > nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - BBSHIFT); > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.h 2007-09-05 11:17:42.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h 2007-09-23 14:04:36.000000000 +0200 > @@ -143,7 +143,6 @@ typedef struct xfs_buf { > void *b_fspriv2; > void *b_fspriv3; > unsigned short b_error; /* error code on I/O */ > - unsigned short b_locked; /* page array is locked */ > unsigned int b_page_count; /* size of page array */ > unsigned int b_offset; /* page offset in first page */ > struct page **b_pages; /* array of page pointers */ > Index: linux-2.6-xfs/fs/xfs/xfsidbg.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c 2007-09-23 13:33:07.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfsidbg.c 2007-09-23 14:04:36.000000000 +0200 > @@ -2110,9 +2110,9 @@ print_xfs_buf( > (unsigned long long) bp->b_file_offset, > (unsigned long long) bp->b_buffer_length, > bp->b_addr); > - kdb_printf(" b_bn 0x%llx b_count_desired 0x%lx b_locked %d\n", > + kdb_printf(" b_bn 0x%llx b_count_desired 0x%lxn", > (unsigned long long)bp->b_bn, > - (unsigned long) bp->b_count_desired, (int)bp->b_locked); > + (unsigned long) bp->b_count_desired); > kdb_printf(" b_queuetime %ld (now=%ld/age=%ld) b_io_remaining %d\n", > bp->b_queuetime, jiffies, bp->b_queuetime + age, > bp->b_io_remaining.counter); > > > From owner-xfs@oss.sgi.com Wed Oct 17 21:17:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 17 Oct 2007 21:17:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I4Hkgw004914 for ; Wed, 17 Oct 2007 21:17: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 OAA08612; Thu, 18 Oct 2007 14:17:45 +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 l9I4HgdD68444905; Thu, 18 Oct 2007 14:17:42 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9I4HaD469389651; Thu, 18 Oct 2007 14:17:36 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 18 Oct 2007 14:17:36 +1000 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , Utako Kusaka , xfs@oss.sgi.com Subject: Re: [PATCH] flush inode when changing atime. Message-ID: <20071018041736.GA66820511@sgi.com> References: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> <20071017090844.GZ995458@sgi.com> <4716D891.1060108@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4716D891.1060108@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13376 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 On Thu, Oct 18, 2007 at 01:52:49PM +1000, Lachlan McIlroy wrote: > David Chinner wrote: > >On Wed, Oct 17, 2007 at 01:56:00PM +0900, Utako Kusaka wrote: > >>Hi, > >> > >>The atime is changed for reading but it returns to a previous value > >>after unmount. i_update_core is still off after reading a file using > >>read(), readdir() and readlink(). So an inode isn't flushed to disk. > > > >I think this was done by design - Christoph? I can't remember exactly > >as it was more than two years ago this change was made. It is effectively > >equivalent to using the relatime mount option. > > > >The question is whether we want to change the default behaviour or > >whether we need to supply an "atimeisatime" mount option for those > >that really need atime to be updated on every access. > > > If we change it back then will anything that scans the filesystem cause > inodes to be dirtied and create a lot of inode flush traffic that we > don't currently have? Right. And given that it's taken over 2 years for anyone to notice that atime only get updated when a file is otherwise dirtied.... > >If we are going to put these back in, then they should be > >calls to xfs_ichgtime_fast() so that we know what the reason > >for marking the core dirty is. > > xfs_ichgtime_fast() will also dirty the linux inode so that sync > will push out the change. The VFS already calls filp_accessed, which marks the linux inode dirty. We're telling sync that the inode really isn't dirty when it tries to flush it, so it's not going to disk.... As Christoph pointed out last night to me the problem really is that VFS atime updates don't have a callback into the filesystem(*) so if we want to write back atime we've basically got to duplicate VFS infrastructure. (*) i.e. call ->setattr to set the atime. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 18 00:26:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 00:26:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I7Q0ED008887 for ; Thu, 18 Oct 2007 00:26:04 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13412; Thu, 18 Oct 2007 17:25:58 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 4121830A7943; Thu, 18 Oct 2007 17:25:58 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 969769 - Fix dbflush panic in xfs_qm_sync Message-Id: <20071018072558.4121830A7943@linuxbuild.melbourne.sgi.com> Date: Thu, 18 Oct 2007 17:25:58 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13377 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Fix dbflush panic in xfs_qm_sync. The recent behaviour layer removal dropped the check for quotas that have been requested at mount time but have subsequently been turned off. This results in a panic when accessing m_quotainfo which has been freed. This patch adds the check originally made by xfs_qm_syncall() to xfs_qm_sync(). Date: Thu Oct 18 17:24:16 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: dgc,lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29908a fs/xfs/quota/xfs_qm.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - Fix dbflush panic in xfs_qm_sync From owner-xfs@oss.sgi.com Thu Oct 18 00:56:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 00:56:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I7uIKv012822 for ; Thu, 18 Oct 2007 00:56:22 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14142; Thu, 18 Oct 2007 17:56:11 +1000 Message-ID: <471712C8.4050805@sgi.com> Date: Thu, 18 Oct 2007 18:01:12 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Utako Kusaka , xfs@oss.sgi.com Subject: Re: [PATCH] flush inode when changing atime. References: <200710170456.AA06101@TNESG9305.wm.jp.nec.com> <20071017090844.GZ995458@sgi.com> <4716D891.1060108@sgi.com> <20071018041736.GA66820511@sgi.com> In-Reply-To: <20071018041736.GA66820511@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13378 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Oct 18, 2007 at 01:52:49PM +1000, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Wed, Oct 17, 2007 at 01:56:00PM +0900, Utako Kusaka wrote: >>>> Hi, >>>> >>>> The atime is changed for reading but it returns to a previous value >>>> after unmount. i_update_core is still off after reading a file using >>>> read(), readdir() and readlink(). So an inode isn't flushed to disk. >>> I think this was done by design - Christoph? I can't remember exactly >>> as it was more than two years ago this change was made. It is effectively >>> equivalent to using the relatime mount option. >>> >>> The question is whether we want to change the default behaviour or >>> whether we need to supply an "atimeisatime" mount option for those >>> that really need atime to be updated on every access. >>> >> If we change it back then will anything that scans the filesystem cause >> inodes to be dirtied and create a lot of inode flush traffic that we >> don't currently have? > > Right. And given that it's taken over 2 years for anyone to notice > that atime only get updated when a file is otherwise dirtied.... > >>> If we are going to put these back in, then they should be >>> calls to xfs_ichgtime_fast() so that we know what the reason >>> for marking the core dirty is. >> xfs_ichgtime_fast() will also dirty the linux inode so that sync >> will push out the change. > > The VFS already calls filp_accessed, which marks the linux inode > dirty. We're telling sync that the inode really isn't dirty when > it tries to flush it, so it's not going to disk.... Ah, so it is. We could compare the linux inode atime with the xfs inode atime in the inode flush path and if they are different sync them and dirty the xfs inode (set i_update_core). But as you said it should be a mount option cause flushing inodes just for atime updates would hurt. > > As Christoph pointed out last night to me the problem really is that > VFS atime updates don't have a callback into the filesystem(*) so if > we want to write back atime we've basically got to duplicate VFS > infrastructure. > > (*) i.e. call ->setattr to set the atime. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Thu Oct 18 01:41:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 01:41:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from smtpi.seznam.cz (smtpi.seznam.cz [77.75.73.97]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9I8fKuu017864 for ; Thu, 18 Oct 2007 01:41:22 -0700 Received: (qmail 11386 invoked from network); 18 Oct 2007 08:14:43 -0000 Received: from unknown (HELO smtp.kancelar.seznam.cz) (192.168.1.64) by smtp.go.seznam.cz with SMTP; 18 Oct 2007 08:14:43 -0000 Received: (qmail 22052 invoked by uid 0); 18 Oct 2007 08:14:44 -0000 Received: from 10.0.2.184 (EHLO [10.0.2.184]) by box.kancelar.seznam.cz id FixusSMTPd22050; 18 Oct 2007 08:14:44 -0000 Message-ID: <4717156C.3030308@firma.seznam.cz> Date: Thu, 18 Oct 2007 10:12:28 +0200 From: Anton A Vorobev User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Slow seek in kernels >= 2.6.18 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Smtpd: szn-smtpd v1.3-3 X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13379 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: anton.vorobev@firma.seznam.cz Precedence: bulk X-list: xfs Hi! A question. We've got an application that runs about 30-40 minutes. After kernel upgrade from 2.6.17 branch, it runs about 3 hours. I've made tests with the help of bonnie++, it shows that random seek operations are about 3 times slower in kernels newer than 2.6.18 in comparison with 2.6.17. This difference may be seen only during high load of a server. When it is in normal state, parameters are rather the same. We use XFS filesystem. Does any one know may it be because of upgrade of XFS driver in kernel? Any ideas? Thanks a lot. ______________________________________________________________ Anton Vorobev Programátor Seznam.cz, a.s. Radlická 608/2 150 00 Praha 5 tel.: +420 234 694 706 fax: +420 234 694 115 anton.vorobev@firma.seznam.cz http://www.seznam.cz From owner-xfs@oss.sgi.com Thu Oct 18 03:41:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 03:41:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IAfjUA000536 for ; Thu, 18 Oct 2007 03:41:48 -0700 Received: by wr-out-0506.google.com with SMTP id c48so123758wra for ; Thu, 18 Oct 2007 03:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=/kaIt7ZlHbd1OyUCZ1c2Wynoi5Uc1bj4I7l7qv67b5E=; b=YKsFG0g6lUUH1klxKzzr5LY4MZbBmkuiPerHuKPxN55xvFMVF9rjCUa/dofHCN67FGdR1AHKxhbfvmUl3CdxbeNkoypydJ2uMr/grunrgsVChD/qeaLosc0A8cWC89zrbxRp7xWczRPXkGDbVM+ExfMLQvdf61fu4ur+QUxL6f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=T+xb39AVLma0cLP9QJDsKMFAu4ynAu8VlOCSDXLiDm7TyCKPTHPw8OWDMEjvrKZtvCwHcWvOP1+NdCTQDY4ccobpaSnzPQKOQ414pqAULMk7RrR0aoEVGMDk90gkh/Lyki/Z4BkWZveX+qM7BdsCExzkImMEE0QM/V3yrzQBrLE= Received: by 10.142.107.1 with SMTP id f1mr34187wfc.1192702505377; Thu, 18 Oct 2007 03:15:05 -0700 (PDT) Received: by 10.142.13.15 with HTTP; Thu, 18 Oct 2007 03:15:05 -0700 (PDT) Message-ID: Date: Thu, 18 Oct 2007 15:45:05 +0530 From: "Bhagi rathi" To: "Anton A Vorobev" Subject: Re: Slow seek in kernels >= 2.6.18 Cc: xfs@oss.sgi.com In-Reply-To: <4717156C.3030308@firma.seznam.cz> MIME-Version: 1.0 References: <4717156C.3030308@firma.seznam.cz> X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1362 X-archive-position: 13380 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs Is it the same on ext file-systems? Can you run the same tests on disk devices directly to rule out scheduling issues of i/o requests by device drivers? One way I was thinking that we got a kind of cache pollution or invalidation thus exposing to do more seeks. Can you tell the equivalent file-system operations that your application in general do? This will give a lot of insight on what could be happening. -Bhagi. On 10/18/07, Anton A Vorobev wrote: > > Hi! > > A question. We've got an application that runs about 30-40 minutes. > After kernel upgrade from 2.6.17 branch, it runs about 3 hours. > I've made tests with the help of bonnie++, it shows that random seek > operations are about 3 times slower in kernels newer than 2.6.18 in > comparison with 2.6.17. This difference may be seen only during high > load of a server. When it is in normal state, parameters are rather the > same. > > We use XFS filesystem. Does any one know may it be because of upgrade of > XFS driver in kernel? Any ideas? > > Thanks a lot. > > ______________________________________________________________ > Anton Vorobev > Program=E1tor > Seznam.cz, a.s. Radlick=E1 608/2 150 00 Praha 5 > > tel.: +420 234 694 706 > fax: +420 234 694 115 > anton.vorobev@firma.seznam.cz > http://www.seznam.cz > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Oct 18 04:03:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 04:03:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_22 autolearn=no version=3.3.0-r574664 Received: from cernmxlb.cern.ch (cernmx07.cern.ch [137.138.166.171]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IB2pHl003284 for ; Thu, 18 Oct 2007 04:03:00 -0700 DomainKey-Status: no signature - Generated by CERN IT/IS DomainKeys v1.0 Keywords: CERN SpamKiller Note: -49 Charset: west-latin X-Filter: CERNMX07 CERN MX v2.0 060921.0942 Release Received: from [128.141.37.212] ([128.141.37.212]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Oct 2007 12:50:41 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: xfs@oss.sgi.com From: Mario Kadastik Subject: raw vs XFS sequential write and system load Date: Thu, 18 Oct 2007 12:50:44 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Oct 2007 10:50:41.0098 (UTC) FILETIME=[B9CA4AA0:01C81174] X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13381 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mario.kadastik@cern.ch Precedence: bulk X-list: xfs Hello, I have a slight problem. Namely we have 4 systems with each having 2x 3ware 9550SX cards in them each with hardware RAID5. Everything is running the latest FW etc. The systems have at least 3GB of memory and at least 2 CPU-s (one has 4GB and 4 cpu-s). Now my problem is that as this is a Grid storage node and we transfer constantly files 2+ GB back and forth with tens of them in parallel, then the system seems to be having serious problems. We can do read speeds basically with only limit being the network without the system picking up any load (we do use the blockdev -- setra 16384) and can keep running combined 200MB/s to the network over a long period of time. However if we get writes to the systems then even at low speeds they hog the systems and send the load of the systems to 20+ (largest I have recovered from is 150, usually they are between 20-60). As this makes the system basically unusable I did a lot of digging to try to understand what causes such a high load. The basic thing is that with vmstat I can see a number of blocked processes during the writes and high io wait for the system. All of the RAID5-s have XFS on top of them. Finally after weeks of not getting any adequate response from 3ware etc I freed up one of the systems to do some extra tests. Just yesterday I measured the basic difference of doing a direct dd to the actual raw device versus doing the dd to a local file in XFS. The results are in detail here: http://hep.kbfi.ee/dbg/jupiter_test.txt As you can see the system is quite responsive during the read and write sequentially to the raw device. There are no blocked processes and the io wait is < 5%. However going to XFS we immediately see blocked processes which over time leads to very high load on the system. Is there something I'm missing? I did create the XFS with the correct RAID 5 su,sw settings, but is there a way to tune the XFS or general kernel parameters in a way that this blocking doesn't occur that much with XFS. I don't really care if I don't get 400MB/s read/write performance, I'd be satisfied with 10% of that during production load as long as the system is able to not fall over because of it. Just as a clarification, the io done is sequential write or read of 2.5GB files, there will be a number of files accessed in parallel (I'd say up to 20 in parallel, but I can limit the number). I have googled around a lot, but to be honest have not enough inside info on the kernel tunables to make an educated guess on where to begin. I'd assume the io patterns of XFS differ from raw sequential read/write, but probably it could be tuned to some extent to better match the hardware and probably there are ways to make sure that instead of load going up the speed goes down. Thanks in advance, Mario Kadastik From owner-xfs@oss.sgi.com Thu Oct 18 06:26:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 06:26:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_17, J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46, J_CHICKENPOX_47,J_CHICKENPOX_48,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IDQJ0K026867 for ; Thu, 18 Oct 2007 06:26:21 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 7B9493015E28 for ; Thu, 18 Oct 2007 15:11:17 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY49l3QlOpxk for ; Thu, 18 Oct 2007 15:11:17 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 585E53013BA2 for ; Thu, 18 Oct 2007 15:11:17 +0200 (CEST) Received: from styx.apartia.fr (styx.apartia.fr [10.0.3.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "styx.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by zenon.apartia.fr (Postfix) with ESMTP id CABDBF08AA01E for ; Thu, 18 Oct 2007 15:11:16 +0200 (CEST) Received: by styx.apartia.fr (Postfix, from userid 1000) id 11C50250D6CB; Thu, 18 Oct 2007 15:11:17 +0200 (CEST) Date: Thu, 18 Oct 2007 15:11:16 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071018131116.GA11957@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017212434.GB995458@sgi.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13382 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > > remove that file: > > > > sylla:/# rm /lost+found/3912672557 > > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > > > sylla:/# ls -li /lost+found/3912672557 > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > Can you post the output of: > > # xfs_db -r -c "inode 3912672557" -c "p" Here: core.magic = 0x494e core.mode = 0120777 core.version = 1 core.format = 1 (local) core.nlinkv1 = 1 core.uid = 0 core.gid = 0 core.flushiter = 1 core.atime.sec = Sun Apr 9 19:10:38 2006 core.atime.nsec = 316368304 core.mtime.sec = Sun Apr 9 19:10:38 2006 core.mtime.nsec = 316368304 core.ctime.sec = Sun Apr 9 19:10:38 2006 core.ctime.nsec = 317368152 core.size = 9 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0x4d291522 core.dmstate = 21036 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 1 core.append = 1 core.sync = 0 core.noatime = 1 core.nodump = 0 core.rtinherit = 1 core.projinherit = 0 core.nosymlinks = 0 core.extsz = 0 core.extszinherit = 0 core.nodefrag = 1 core.gen = 0 next_unlinked = null u.symlink = "unix.7.gz" Thanks, From owner-xfs@oss.sgi.com Thu Oct 18 09:07:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 09:07:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IG7Sah006782 for ; Thu, 18 Oct 2007 09:07:30 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IiXaD-0004o3-Ph; Thu, 18 Oct 2007 16:46:49 +0100 Date: Thu, 18 Oct 2007 16:46:49 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071018154649.GA16837@infradead.org> References: <470C8F5B.90705@sgi.com> <20071010093451.GA7655@infradead.org> <20071010112505.GH23367404@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010112505.GH23367404@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13383 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 On Wed, Oct 10, 2007 at 09:25:06PM +1000, David Chinner wrote: > > Where are these set up in the first time? AFAICS the buffer only written > > out by xfs_unmountfs_writesb, xfs_syncsub and xfs_trans_log_buf, and all > > these should only ever happen after log recovery has finished. > > It can also be written by xfsbufd when it has been bdwrite() > or as a result of log tail pushing. Hmm, true. > Because the superblock buffer is XBF_FS_MANAGED, it does not get > torn down when it is clean and has no references, so the XBF_ASYNC > flag never gets cleared unless the fs specifically clears it. If the > superblock is then not recovered out of any further transactions > during recovery after xfsbufd flushed it, the XBF_ASYNC flag remains > set for the re-read that is issued in xlog_do_recover() and we > hang..... Makes sense as an explanation. I still don't really like patch, maybe we should always clear the ASYNC flag in the b_iodone callback? From owner-xfs@oss.sgi.com Thu Oct 18 09:16:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 09:16:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IGFxxT008734 for ; Thu, 18 Oct 2007 09:16:01 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IiY2T-00063r-Iu; Thu, 18 Oct 2007 17:16:01 +0100 Date: Thu, 18 Oct 2007 17:16:01 +0100 From: Christoph Hellwig To: Donald Douwsma Cc: xfs-oss Subject: Re: Review: Fix dbflush panic in xfs_qm_sync Message-ID: <20071018161601.GA21492@infradead.org> References: <4713F7D3.2090201@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4713F7D3.2090201@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13384 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 On Tue, Oct 16, 2007 at 09:29:23AM +1000, Donald Douwsma wrote: > The recent behaviour layer removal dropped the check for quotas that have > been > requested at mount time but have subsequently been turned off. This results > in a panic when accessing m_quotainfo which has been freed. > > This patch adds the check originally made by xfs_qm_syncall() to > xfs_qm_sync() Hmm. We do the same check just a few lines below, but inbetween we access ->m_quotainfo to take the lock. I was under the impression that's the only safe way to check anyway, but ->m_quotainfo might not actually be present. It might me better to move the lock into xfs_mount directly, but it's embedded into a xfs_dqhash and there's some complex mess with gazillions of macros around it. So I suspect restoring it to the original state might be good enough. From owner-xfs@oss.sgi.com Thu Oct 18 12:11:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 12:11:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_40,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 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.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9IJBT7s004911 for ; Thu, 18 Oct 2007 12:11:32 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1Iia01-0006hB-MZ for ; Thu, 18 Oct 2007 19:21:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18199.42033.260371.275119@base.ty.sabi.co.UK> Date: Thu, 18 Oct 2007 19:21: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: {WHAT?} Slow seek in kernels >= 2.6.18 In-Reply-To: <4717156C.3030308@firma.seznam.cz> References: <4717156C.3030308@firma.seznam.cz> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13385 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 >>> On Thu, 18 Oct 2007 10:12:28 +0200, Anton A Vorobev >>> said: anton.vorobev> Hi! A question. We've got an application that anton.vorobev> runs about 30-40 minutes. After kernel upgrade anton.vorobev> from 2.6.17 branch, it runs about 3 hours. [ anton.vorobev> ... ] I'd check the elevator and its parameters more than XFS. From owner-xfs@oss.sgi.com Thu Oct 18 15:07:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 15:07:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9IM7Ef8002181 for ; Thu, 18 Oct 2007 15:07:18 -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 IAA05767 for ; Fri, 19 Oct 2007 08:07:16 +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 l9IM7FdD71357753 for ; Fri, 19 Oct 2007 08:07:16 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9IM7Eek71364650 for linux-xfs@oss.sgi.com; Fri, 19 Oct 2007 08:07:14 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 19 Oct 2007 08:07:14 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071018220714.GM995458@sgi.com> References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071018131116.GA11957@apartia.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13386 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 On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand wrote: > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > > > remove that file: > > > > > > sylla:/# rm /lost+found/3912672557 > > > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > > > > > sylla:/# ls -li /lost+found/3912672557 > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > > > Can you post the output of: > > > > # xfs_db -r -c "inode 3912672557" -c "p" > > Here: > > core.magic = 0x494e > core.mode = 0120777 > core.version = 1 > core.format = 1 (local) > core.nlinkv1 = 1 ..... > core.immutable = 1 ^^^^^^^^^^^^^^^^^^ You can't remove this link until you remove the immutable flag. # xfs_io -r -c "chattr -i" /lost+found/3912672557 as root should do the trick. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 18 15:24:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 15:24:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9IMO4Hw005618 for ; Thu, 18 Oct 2007 15:24:08 -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 IAA06262; Fri, 19 Oct 2007 08:24:01 +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 l9IMNxdD71339146; Fri, 19 Oct 2007 08:24:00 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9IMNvuh71316028; Fri, 19 Oct 2007 08:23:57 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 19 Oct 2007 08:23:57 +1000 From: David Chinner To: Mario Kadastik Cc: xfs@oss.sgi.com Subject: Re: raw vs XFS sequential write and system load Message-ID: <20071018222357.GN995458@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-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13387 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 On Thu, Oct 18, 2007 at 12:50:44PM +0200, Mario Kadastik wrote: > Hello, > > I have a slight problem. Namely we have 4 systems with each having 2x > 3ware 9550SX cards in them each with hardware RAID5. Everything is > running the latest FW etc. The systems have at least 3GB of memory > and at least 2 CPU-s (one has 4GB and 4 cpu-s). Before going any further, what kernel are you using and what's the output of xfs_info of the filesytsem you are testing? FWIW, high iowait = high load average. High iowait is generally an indicator of an overloaded disk subsystem. You tests to the raw device only used a single stream, so it's unlikely to show any of the issues you're complaining about when running tens of parallel streams.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 18 17:49:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 17:50:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J0nsxO030023 for ; Thu, 18 Oct 2007 17:49:56 -0700 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 KAA09796; Fri, 19 Oct 2007 10:49:52 +1000 Message-ID: <4717FF91.5010902@sgi.com> Date: Fri, 19 Oct 2007 10:51:29 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: xfs-dev CC: xfs mailing list Subject: Re: Review: Make xfs_bulkstat() to report unlinked but referenced inodes References: <4715A22D.1070409@sgi.com> In-Reply-To: <4715A22D.1070409@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13388 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 ping! I ran XFS QA with this patch and didn't see any regressions and I (and Judith in US) have verified the expected behavior - xfs_bulkstat() now reports referenced inodes with link count of zero. Regards, Vlad Vlad Apostolov wrote: > We need xfs_bulkstat() to report inode stat for inodes with > link count zero but reference count non zero. > > The fix here: > > http://oss.sgi.com/archives/xfs/2007-09/msg00266.html > > changed this behavior and made xfs_bulkstat() to filter all > unlinked inodes including those that are not destroyed yet but > held by reference. > > The attached patch returns back to the original behavior by > marking the on-disk inode buffer "dirty" when di_mode is cleared > (at that time both inode link and reference counter are zero). > > Regards, > Vlad From owner-xfs@oss.sgi.com Thu Oct 18 17:57:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 17:57:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J0vQ8T031657 for ; Thu, 18 Oct 2007 17:57:29 -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 KAA10029; Fri, 19 Oct 2007 10:57:24 +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 l9J0vNdD71167641; Fri, 19 Oct 2007 10:57:24 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9J0vMqA71406206; Fri, 19 Oct 2007 10:57:22 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 19 Oct 2007 10:57:22 +1000 From: David Chinner To: Vlad Apostolov Cc: xfs-dev , xfs mailing list Subject: Re: Review: Make xfs_bulkstat() to report unlinked but referenced inodes Message-ID: <20071019005722.GO995458@sgi.com> References: <4715A22D.1070409@sgi.com> <4717FF91.5010902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4717FF91.5010902@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13389 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 On Fri, Oct 19, 2007 at 10:51:29AM +1000, Vlad Apostolov wrote: > ping! > > I ran XFS QA with this patch and didn't see any regressions and > I (and Judith in US) have verified the expected behavior - xfs_bulkstat() > now reports referenced inodes with link count of zero. Looks fine, Vlad - all I was waiting for was the test results. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 18 18:23:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 18:23:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J1NLnq003701 for ; Thu, 18 Oct 2007 18:23:23 -0700 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 LAA10655; Fri, 19 Oct 2007 11:23:20 +1000 Message-ID: <47180769.6070200@sgi.com> Date: Fri, 19 Oct 2007 11:24:57 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: xfs mailing list Subject: TAKE 972004 - Make xfs_bulkstat() to report unlinked but referenced inodes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13390 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 Make xfs_bulkstat() to report unlinked but referenced inodes We need xfs_bulkstat() to report inode stat for inodes with link count zero but reference count non zero. The fix here: changed this behavior and made xfs_bulkstat() to filter all unlinked inodes including those that are not destroyed yet but held by reference. The attached patch returns back to the original behavior by marking the on-disk inode buffer "dirty" when di_mode is cleared (at that time both inode link and reference counter are zero). Date: Fri Oct 19 11:21:26 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs1 Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29914a fs/xfs/xfs_itable.c - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h - pv 972004, rv dgc - Make xfs_bulkstat() to report unlinked but referenced inodes fs/xfs/xfs_inode.c - 1.484 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.484&r2=text&tr2=1.483&f=h - pv 972004, rv dgc - Make xfs_bulkstat() to report unlinked but referenced inodes From owner-xfs@oss.sgi.com Thu Oct 18 18:27:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 18:27:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J1RRgn004695 for ; Thu, 18 Oct 2007 18:27:29 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10764; Fri, 19 Oct 2007 11:27:15 +1000 Message-ID: <47180922.4040709@sgi.com> Date: Fri, 19 Oct 2007 11:32:18 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christoph Hellwig CC: David Chinner , xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock References: <470C8F5B.90705@sgi.com> <20071010093451.GA7655@infradead.org> <20071010112505.GH23367404@sgi.com> <20071018154649.GA16837@infradead.org> In-Reply-To: <20071018154649.GA16837@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13391 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Wed, Oct 10, 2007 at 09:25:06PM +1000, David Chinner wrote: >>> Where are these set up in the first time? AFAICS the buffer only written >>> out by xfs_unmountfs_writesb, xfs_syncsub and xfs_trans_log_buf, and all >>> these should only ever happen after log recovery has finished. >> It can also be written by xfsbufd when it has been bdwrite() >> or as a result of log tail pushing. > > Hmm, true. > >> Because the superblock buffer is XBF_FS_MANAGED, it does not get >> torn down when it is clean and has no references, so the XBF_ASYNC >> flag never gets cleared unless the fs specifically clears it. If the >> superblock is then not recovered out of any further transactions >> during recovery after xfsbufd flushed it, the XBF_ASYNC flag remains >> set for the re-read that is issued in xlog_do_recover() and we >> hang..... > > Makes sense as an explanation. I still don't really like patch, maybe > we should always clear the ASYNC flag in the b_iodone callback? > That sounds like a good idea. Or get rid of the XBF_FS_MANAGED special case and get a new fresh buffer each time. From owner-xfs@oss.sgi.com Thu Oct 18 19:14:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 19:14:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J2E7lQ010975 for ; Thu, 18 Oct 2007 19:14:11 -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 MAA12128; Fri, 19 Oct 2007 12:14:07 +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 l9J2E6dD71408917; Fri, 19 Oct 2007 12:14:06 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9J2E3Rh71495806; Fri, 19 Oct 2007 12:14:03 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 19 Oct 2007 12:14:03 +1000 From: David Chinner To: Lachlan McIlroy Cc: Christoph Hellwig , David Chinner , xfs-dev , xfs-oss Subject: Re: review: use correct buffer flags when reading superblock Message-ID: <20071019021403.GQ995458@sgi.com> References: <470C8F5B.90705@sgi.com> <20071010093451.GA7655@infradead.org> <20071010112505.GH23367404@sgi.com> <20071018154649.GA16837@infradead.org> <47180922.4040709@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47180922.4040709@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13392 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 On Fri, Oct 19, 2007 at 11:32:18AM +1000, Lachlan McIlroy wrote: > Christoph Hellwig wrote: > >On Wed, Oct 10, 2007 at 09:25:06PM +1000, David Chinner wrote: > >>Because the superblock buffer is XBF_FS_MANAGED, it does not get > >>torn down when it is clean and has no references, so the XBF_ASYNC > >>flag never gets cleared unless the fs specifically clears it. If the > >>superblock is then not recovered out of any further transactions > >>during recovery after xfsbufd flushed it, the XBF_ASYNC flag remains > >>set for the re-read that is issued in xlog_do_recover() and we > >>hang..... > > > >Makes sense as an explanation. I still don't really like patch, maybe > >we should always clear the ASYNC flag in the b_iodone callback? > > That sounds like a good idea. Makes no real difference - you just have to be careful where the ASYNC flag is cleared because it is used throughout the io completion code.... > Or get rid of the XBF_FS_MANAGED special > case and get a new fresh buffer each time. I don't think we want to do that. It will add substantial overhead because the superblock is the single most used buffer in the filesysem. It's typically gained during transaction commit, at which time we really, really want to get it quickly and this is known to be a performance limiting bottleneck..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Oct 18 21:54:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 21:54:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from mailsvr02.vanleeuwen.co.id ([203.120.24.35]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J4sKrU004910 for ; Thu, 18 Oct 2007 21:54:24 -0700 Message-ID: Date: Fri, 19 Oct 2007 11:58:20 +0800 From: mailer-daemon@mailsvr02.vanleeuwen.co.id To: xfs@oss.sgi.com Subject: Undeliverable: [Possible SPAM] Returned mail: Data format error X-hMailServer-LoopCount: 1 X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13393 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mailer-daemon@mailsvr02.vanleeuwen.co.id Precedence: bulk X-list: xfs Your message did not reach some or all of the intended recipients. Sent: Fri, 19 Oct 2007 05:48:59 -0700 Subject: [Possible SPAM] Returned mail: Data format error The following recipient(s) could not be reached: business@continental.co.id Error Type: SMTP Error Description: Inbox is full Additional information: The recipients inbox is full. hMailServer From owner-xfs@oss.sgi.com Thu Oct 18 23:13:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 18 Oct 2007 23:13:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cernmxlb.cern.ch (cernmx07.cern.ch [137.138.166.171]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9J6DIPk031367 for ; Thu, 18 Oct 2007 23:13:20 -0700 DomainKey-Status: no signature - Generated by CERN IT/IS DomainKeys v1.0 Keywords: CERN SpamKiller Note: -51 Charset: west-latin X-Filter: CERNMX07 CERN MX v2.0 060921.0942 Release Received: from [128.141.130.228] ([128.141.130.228]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 08:12:12 +0200 In-Reply-To: <20071018222357.GN995458@sgi.com> References: <20071018222357.GN995458@sgi.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: Cc: xfs@oss.sgi.com From: Mario Kadastik Subject: Re: raw vs XFS sequential write and system load Date: Fri, 19 Oct 2007 08:12:16 +0200 To: David Chinner X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Oct 2007 06:12:12.0605 (UTC) FILETIME=[FD2A56D0:01C81216] X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 5825 X-archive-position: 13395 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mario.kadastik@cern.ch Precedence: bulk X-list: xfs >> I have a slight problem. Namely we have 4 systems with each having 2x >> 3ware 9550SX cards in them each with hardware RAID5. Everything is >> running the latest FW etc. The systems have at least 3GB of memory >> and at least 2 CPU-s (one has 4GB and 4 cpu-s). > > Before going any further, what kernel are you using and what's > the output of xfs_info of the filesytsem you are testing? Well I did manage to accidentally kill that specific box (did the heavy dd to a file on the root disk instead of the XFS mount (forgot to mount first), filling it and losing the system from net, so will have to wait for it to come back after someone locally can go and have a look). But I moved over to another box where I had freed up one RAID5 for testing purposes and a number of things came apparent: 1. on the original box I had been running 2.6.9 SMP which was the default shipped with Scientific Linux 4. With that kernel the single stream to raw device seemed to go without no io wait and everything seemed very nice, however the XFS performance was as I wrote, under par the very least. 2. before I lost the box I had rebooted it to 2.6.22.9 SMP as I had been reading around about XFS and found that 2.6.15+ kernels had a few updates which might be of interest, however I immediately found that 2.6.22.9 behaved absolutely different. For one thing the single stream write to raw disk no longer had 0% io wait, but instead around 40-50%. A quick look of the difference of the two kernels revealed for example that the /sys/block/sda/queue/nr_requests had gone from 8192 in 2.6.9 to 128 in 2.6.22.9. Going back to 8192 decreased the load of single stream write to raw disk io wait to 10% region, but not to 0. Soon after however I killed the system so had to stop the tests for a while. 3. On the new box with 4 cpu-s, 4 GB of memory and 12 drive RAID5 I was running 2.6.23 SMP with CONFIG_4KSTACKS disabled (one of our admins thought that could cure a few crashes we had seen before on the system due to high network load, don't know if it's relevant, but just in case mentioned). On this box I first also discovered horrible io wait with single stream write to raw device and again the nr_requests seemed to cure that to 10% level. However here I also found that XFS was performing exactly the same as the direct raw device. Also in the 5-10% region of io wait. Doing 2 parallel writes to the filesystem increased the io wait to 25%. Doing parallel read and write had the system at around 15-20% of io wait, the more concrete numbers for some of the tests I did: 1 w 0 r: 10% 2 w 0 r: 20% 3 w 0 r: 33% 4 w 0 r: 45% 5 w 0 r: 50% 3 w 3 r: 50-60% (system still ca 20% idle) 3 w 10 r: 50-80% (system ca 10% idle, over time system load increased to 14) the last one was already a more realistic scenario (8 RAID5-s, 3 writes per one is 24 writes, that's about the order of magnitude I'm aiming for, 80 reads is quite conservative still, likely is 120 accross the whole storage of 4 systems, though we will increase that number further to spread out the load even further). However I have been running the test on only one controller now while the other one was sitting idle, in reality both of them would be hit the same way at the same time. Now as I have only access to the new box I'll provide the XFS info for that one: meta-data=/dev/sdc isize=256 agcount=32, agsize=62941568 blks = sectsz=512 attr=0 data = bsize=4096 blocks=2014129920, imaxpct=25 = sunit=16 swidth=176 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy- count=0 realtime =none extsz=4096 blocks=0, rtextents=0 it was created with mkfs.xfs -d su=64k,sw=11 /dev/sdc to match the underlying RAID5 of 12 disks and stripe size 64k. > > FWIW, high iowait = high load average. High iowait is generally an > indicator of an overloaded disk subsystem. You tests to the raw > device only used a single stream, so it's unlikely to show any of > the issues you're complaining about when running tens of parallel > streams.... > Well I do understand that high io wait leads to high load over some time period. And I also do understand that high io wait indicates overloaded disk, however as the percentage of io wait seems to vary highly with what kernel is running and what the kernel settings are, then I think that the system should be able to cope with what I'm throwing at it. Now, my main concern is not the speed. As long as I get around 2-3MB/ s per file/stream read/written I'm happy AS LONG AS the system remains responsive. I mean Linux kernel must have a way to gear down network traffic (or in the case of dd then memory access) to suit the underlying system which is taking the hit. It's probably a question of tuning the kernel to act correctly, not try to do all at maximum speed, but to do it in a stable way. All of the above tests were still going at high speed, average read and write speeds in total were around 150-200MB/s however I'd be happy with 10% of that if it were to make the system more stable. It seems now that XFS may not be the big culprit here, but I do think that the kernel VM management is best tuned by people who do understand how XFS behaves to make sure that it can cope with something I'm hoping for it to do as well as tuning XFS itself to match the io patterns and underlying system. I do appreciate any help you could give me. Thanks in advance, Mario [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Oct 19 00:59:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 01:00:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J7xsL1023030 for ; Fri, 19 Oct 2007 00:59:57 -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 RAA20684; Fri, 19 Oct 2007 17:59:52 +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 l9J7xodD70620599; Fri, 19 Oct 2007 17:59:51 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9J7xn5371680591; Fri, 19 Oct 2007 17:59:49 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 19 Oct 2007 17:59:49 +1000 From: David Chinner To: Mario Kadastik Cc: xfs@oss.sgi.com Subject: Re: raw vs XFS sequential write and system load Message-ID: <20071019075949.GS995458@sgi.com> References: <20071018222357.GN995458@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13396 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 On Fri, Oct 19, 2007 at 08:12:16AM +0200, Mario Kadastik wrote: > >>I have a slight problem. Namely we have 4 systems with each having 2x > >>3ware 9550SX cards in them each with hardware RAID5. Everything is > >>running the latest FW etc. The systems have at least 3GB of memory > >>and at least 2 CPU-s (one has 4GB and 4 cpu-s). > > > >Before going any further, what kernel are you using and what's > >the output of xfs_info of the filesytsem you are testing? > > Well I did manage to accidentally kill that specific box (did the > heavy dd to a file on the root disk instead of the XFS mount (forgot > to mount first), filling it and losing the system from net, so will > have to wait for it to come back after someone locally can go and > have a look). But I moved over to another box where I had freed up > one RAID5 for testing purposes and a number of things came apparent: Oops :/ > 1. on the original box I had been running 2.6.9 SMP which was the > default shipped with Scientific Linux 4. With that kernel the single > stream to raw device seemed to go without no io wait and everything > seemed very nice, however the XFS performance was as I wrote, under > par the very least. Ah - 2.6.9. That explains the bad behaviour of XFS - it's locking all the system memory in the elevator because the depth is so large. i.e. throttle at 7/8 * 8192 requests, and each request will be 512k which means that we can have ~3.5GB of RAM locked in a single elevator queue before it will throttle. Effectively your config is running your machine out of available memory.... > 2. before I lost the box I had rebooted it to 2.6.22.9 SMP as I had > been reading around about XFS and found that 2.6.15+ kernels had a > few updates which might be of interest, however I immediately found > that 2.6.22.9 behaved absolutely different. Absolutely. We fixed all the problems w.r.t. queue depth and congestion, and we completely rewrote the write path.... > For one thing the single > stream write to raw disk no longer had 0% io wait, but instead around > 40-50%. A quick look of the difference of the two kernels revealed > for example that the /sys/block/sda/queue/nr_requests had gone from > 8192 in 2.6.9 to 128 in 2.6.22.9. Yup, it was set to something sane and the block device is throttling writes on device congestion. > Going back to 8192 decreased the > load of single stream write to raw disk io wait to 10% region, but > not to 0. Soon after however I killed the system so had to stop the > tests for a while. Yup, you probably had the OOM killer trigger because setting the queue depth that deep is a Bad Thing To Do. Effectively, you turned off all feedback from the I/o layer to the VM to say the drive has enough I/O now so please stop sending me more because all I'm doing is queing it. > 3. On the new box with 4 cpu-s, 4 GB of memory and 12 drive RAID5 I > was running 2.6.23 SMP with CONFIG_4KSTACKS disabled (one of our > admins thought that could cure a few crashes we had seen before on > the system due to high network load, don't know if it's relevant, but > just in case mentioned). On this box I first also discovered horrible > io wait with single stream write to raw device and again the > nr_requests seemed to cure that to 10% level. That's not a cure! that's asking for trouble. You're seeing high I/O wait because the system can feed data to the disks *much* faster than the disk can do the I/O and you're not consuming any CPU time. This is *not wrong*. XFS can feed disk subsystems many, many times faster than what you have - you will always see iowait time on this sort of system when using XFS. It's telling you the filesystem is far, far faster than your disk. ;) > However here I also > found that XFS was performing exactly the same as the direct raw > device. Also in the 5-10% region of io wait. Doing 2 parallel writes > to the filesystem increased the io wait to 25%. Doing parallel read > and write had the system at around 15-20% of io wait, the more > concrete numbers for some of the tests I did: > > 1 w 0 r: 10% > 2 w 0 r: 20% > 3 w 0 r: 33% > 4 w 0 r: 45% > 5 w 0 r: 50% > > 3 w 3 r: 50-60% (system still ca 20% idle) > 3 w 10 r: 50-80% (system ca 10% idle, over time system load increased > to 14) Now change thenr_request back to 128 and run the test again. What happens to your iowait? What happens to responsiveness? > Now as I have only access to the new box I'll provide the XFS info > for that one: > meta-data=/dev/sdc isize=256 agcount=32, > agsize=62941568 blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=2014129920, > imaxpct=25 > = sunit=16 swidth=176 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks, lazy- > count=0 > realtime =none extsz=4096 blocks=0, rtextents=0 > > it was created with mkfs.xfs -d su=64k,sw=11 /dev/sdc to match the > underlying RAID5 of 12 disks and stripe size 64k. Add v2 logs, log stripe unit of 64k. > Now, my main concern is not the speed. As long as I get around 2-3MB/ > s per file/stream read/written I'm happy AS LONG AS the system > remains responsive. I mean Linux kernel must have a way to gear down > network traffic (or in the case of dd then memory access) to suit the > underlying system which is taking the hit. It *does*. It's the elevator queue depth! By setting it back to 8192 you turned off the mechanism linux uses to maintain responsiveness under heavy I/O load. > It's probably a question > of tuning the kernel to act correctly, not try to do all at maximum > speed, but to do it in a stable way. By default it should do the right thing. You should not have to tweak anything at all. You're tweaking is causing the unstableness in the recent kernels. Use the defaults and your system should remain responsive under any I/o load you throw at it. High iowait time and/or high load average is *not* an indication of a problem, just that your system is under load and you're not cpu bound. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Oct 19 01:30:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 01:30:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9J8UM3N000837 for ; Fri, 19 Oct 2007 01:30:26 -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 SAA21433; Fri, 19 Oct 2007 18:30:19 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 6F53058C38F1; Fri, 19 Oct 2007 18:30:19 +1000 (EST) Date: Fri, 19 Oct 2007 18:30:19 +1000 To: torvalds@linux-foundation.org Cc: tes@sgi.com, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc1 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071019083019.6F53058C38F1@chook.melbourne.sgi.com> From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13397 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 Hi Linus, A couple of Christoph patches for XFS ... A fid one for nfs exports which akpm is waiting for. Thanks. Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_export.c | 6 +++--- fs/xfs/linux-2.6/xfs_export.h | 6 +++--- fs/xfs/linux-2.6/xfs_ioctl.c | 24 ++++++++++++------------ fs/xfs/xfs_dmops.c | 21 ++++----------------- fs/xfs/xfs_fs.h | 29 ++++++----------------------- fs/xfs/xfs_qmops.c | 22 +++++++--------------- fs/xfs/xfs_vfsops.c | 9 ++++----- fs/xfs/xfs_vfsops.h | 4 ++-- fs/xfs/xfs_vnodeops.c | 13 ++----------- fs/xfs/xfs_vnodeops.h | 2 +- 10 files changed, 44 insertions(+), 92 deletions(-) through these commits: commit c6143911a7e0f8abef0319c801eb36718f57dfde Author: Christoph Hellwig Date: Fri Sep 14 15:22:37 2007 +1000 [XFS] cleanup fid types mess Currently XFs has three different fid types: struct fid, struct xfs_fid and struct xfs_fid2 with hte latter two beeing identicaly and the first one beeing the same size but an unstructured array with the same size. This patch consolidates all this to alway uuse struct xfs_fid. This patch is required for an upcoming patch series from me that revamps the nfs exporting code and introduces a Linux-wide struct fid. SGI-PV: 970336 SGI-Modid: xfs-linux-melb:xfs-kern:29651a Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit c8fcfac5a257f8a04f7ba3d397dedccffef19be2 Author: Christoph Hellwig Date: Fri Oct 19 16:57:01 2007 +1000 [XFS] fixups after behavior removal merge into mainline git Fixup for lack of dmapi support and no quota module support. SGI-PV: 969985 Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin From owner-xfs@oss.sgi.com Fri Oct 19 03:10:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 03:10:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9JAA8fP015451 for ; Fri, 19 Oct 2007 03:10:10 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 621A6300E040 for ; Fri, 19 Oct 2007 12:10:09 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj61s8qKV9ir for ; Fri, 19 Oct 2007 12:10:09 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 3F2A1300E37B for ; Fri, 19 Oct 2007 12:10:09 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id ADA5AF08E6B1F for ; Fri, 19 Oct 2007 12:10:08 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 8C7C8255DDC2; Fri, 19 Oct 2007 12:10:08 +0200 (CEST) Date: Fri, 19 Oct 2007 12:10:08 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071019101008.GA28175@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> <20071018220714.GM995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071018220714.GM995458@sgi.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13398 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Fri, Oct 19, 2007 at 08:07:14AM +1000, David Chinner wrote: > On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand wrote: > > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: > > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > > > > remove that file: > > > > > > > > sylla:/# rm /lost+found/3912672557 > > > > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > > > > > > > sylla:/# ls -li /lost+found/3912672557 > > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > > > > > Can you post the output of: > > > > > > # xfs_db -r -c "inode 3912672557" -c "p" > > > > Here: > > > > core.magic = 0x494e > > core.mode = 0120777 > > core.version = 1 > > core.format = 1 (local) > > core.nlinkv1 = 1 > ..... > > core.immutable = 1 > ^^^^^^^^^^^^^^^^^^ > > You can't remove this link until you remove the immutable flag. > > # xfs_io -r -c "chattr -i" /lost+found/3912672557 sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557 /lost+found/3912672557: No such file or directory Tough cookie this one :) From owner-xfs@oss.sgi.com Fri Oct 19 03:11:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 03:11:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, J_CHICKENPOX_43,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cernmxlb.cern.ch (cernmx08.cern.ch [137.138.166.172]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9JABauw015817 for ; Fri, 19 Oct 2007 03:11:39 -0700 DomainKey-Status: no signature - Generated by CERN IT/IS DomainKeys v1.0 Keywords: CERN SpamKiller Note: -51 Charset: west-latin X-Filter: CERNMX08 CERN MX v2.0 060921.0942 Release Received: from [128.141.224.55] ([128.141.224.55]) by cernmxlb.cern.ch with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Oct 2007 12:11:32 +0200 In-Reply-To: <20071019075949.GS995458@sgi.com> References: <20071018222357.GN995458@sgi.com> <20071019075949.GS995458@sgi.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: Cc: xfs@oss.sgi.com From: Mario Kadastik Subject: Re: raw vs XFS sequential write and system load Date: Fri, 19 Oct 2007 12:11:37 +0200 To: David Chinner X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Oct 2007 10:11:32.0943 (UTC) FILETIME=[6C9805F0:01C81238] X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 5337 X-archive-position: 13399 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mario.kadastik@cern.ch Precedence: bulk X-list: xfs > Ah - 2.6.9. That explains the bad behaviour of XFS - it's locking all > the system memory in the elevator because the depth is so large. > i.e. throttle at 7/8 * 8192 requests, and each request will be > 512k which means that we can have ~3.5GB of RAM locked in a single > elevator queue before it will throttle. Effectively your config > is running your machine out of available memory.... Ok, that explains a few things ... >> However here I also >> found that XFS was performing exactly the same as the direct raw >> device. Also in the 5-10% region of io wait. Doing 2 parallel writes >> to the filesystem increased the io wait to 25%. Doing parallel read >> and write had the system at around 15-20% of io wait, the more >> concrete numbers for some of the tests I did: >> >> 1 w 0 r: 10% >> 2 w 0 r: 20% >> 3 w 0 r: 33% >> 4 w 0 r: 45% >> 5 w 0 r: 50% >> >> 3 w 3 r: 50-60% (system still ca 20% idle) >> 3 w 10 r: 50-80% (system ca 10% idle, over time system load increased >> to 14) > > Now change thenr_request back to 128 and run the test again. What > happens to your iowait? What happens to responsiveness? 1 w 0 r: 25-50% and the bo of vmstat is extremely fluctuating 2 w 0 r: 60-90% and fluctuations are big 3 w 0 r: 80-100% 4 w 0 r: 90+ % 5 w 0 r: 95+ % 3 w 3 r: 90% most of the time there is no cpu idle % 3 w 10 r: 95%, nothing idle 8 w 10 r: 95%, nothing idle however the speeds seem to be quite stable in and out in the read +write tests around 50-70MB/s. You can see the system behaviour as I ramped up the tests here: http://monitor.hep.kbfi.ee/?c=Jupiter% 20SE&h=europa.hep.kbfi.ee&m=&r=hour&s=descending&hc=4 It was running in the end 8 w 10 r and the load kept at about 26 with cpus being in io wait. The disk rates aren't visible, but for an example here is some vmstat output when the test was running for quite some time already: procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 26 144 516584 344 3378396 0 0 77760 37764 1859 3353 0 5 0 95 1 25 144 526844 348 3356420 0 0 77888 69652 2177 4728 0 7 0 93 0 27 144 438660 348 3450708 0 0 55296 36580 1270 2487 0 4 0 96 0 26 144 467444 348 3419976 0 0 71616 66988 1870 3856 0 7 0 93 3 27 144 534780 348 3362948 0 0 59392 45628 1374 3380 0 5 0 95 0 27 144 545440 344 3349692 0 0 96256 57316 2462 3736 0 7 0 93 0 26 144 438876 348 3464304 0 0 73664 38608 1798 2038 0 3 0 97 10 20 144 480852 348 3410584 0 0 61568 53908 1549 3455 0 5 0 95 0 26 144 530496 348 3356732 0 0 61376 57240 1620 4370 0 6 0 95 0 23 144 582324 348 3302928 0 0 64000 42036 1433 3808 0 4 0 96 8 18 144 493092 348 3401184 0 0 49728 55193 1502 2784 0 4 0 96 0 26 144 513676 444 3375716 0 0 60832 73583 2033 4772 3 6 0 91 0 26 144 460332 444 3437160 0 0 49024 46160 1434 2225 0 4 0 96 so around 60MB/s reads and 50MB/s writes were ongoing in the system at the time. The main question now is wether this can be kept up stably. To test this I'd have to migrate data back to the new XFS (3.1TB of data) and wait and see. The system was responsive and if the load remains flat out, then I guess it is not such a big problem. The 3ware recommended value for 9550SX I think is 512 for the nr_request, so I tried that as well (changing live during the test) and the result was that io wait remaind around 93% (so dropped a few %), but the speed did increase to around 80-90MB/s on reads and around 70MB/s on writes. The system load itself remained at the same level. I'll let it run in the background for a longer period to see how things behave. >> it was created with mkfs.xfs -d su=64k,sw=11 /dev/sdc to match the >> underlying RAID5 of 12 disks and stripe size 64k. > > Add v2 logs, log stripe unit of 64k. Did that. > It *does*. It's the elevator queue depth! By setting it back to 8192 > you turned off the mechanism linux uses to maintain responsiveness > under heavy I/O load. Ok, 8192 is probably way too high, but I guess the 512 that was something I remember from 3ware should be about right? >> It's probably a question >> of tuning the kernel to act correctly, not try to do all at maximum >> speed, but to do it in a stable way. > > By default it should do the right thing. You should not have to > tweak anything at all. You're tweaking is causing the unstableness > in the recent kernels. Use the defaults and your system should > remain responsive under any I/o load you throw at it. High iowait > time and/or high load average is *not* an indication of a problem, > just that your system is under load and you're not cpu bound. Well my question is wether or not one needs to tune also the VM management (dirty ratio etc) considering the high amount of data transfers. I haven't added network to the mesh yet until I put the new optimized system online for use and see how it performs. I guess having 8 pdflush -s in uninterruptible sleep can also cause problems and could maybe be handled better somehow? Thanks a lot for the answers, Mario [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Oct 19 11:09:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 11:09:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9JI9oHA026195 for ; Fri, 19 Oct 2007 11:09:53 -0700 Received: from liberator.sandeen.net (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 07DFC18013828; Fri, 19 Oct 2007 13:09:52 -0500 (CDT) Message-ID: <4718F2EF.9050808@sandeen.net> Date: Fri, 19 Oct 2007 13:09:51 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: xfs-oss Subject: Re: [PATCH] xfs: implement fallocate V2 References: <20070713184125.GA12156@amitarora.in.ibm.com> <20070716053751.GN12413810@sgi.com> In-Reply-To: <20070716053751.GN12413810@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13400 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 David Chinner wrote: > Initial implementation of ->fallocate for XFS. > > Version 2: > > o Make allocation and setting the file size atomic. > o Drop deallocate/punch functionality > o use mode field appropriately to determine if size needs changing. > Dave, I don't see this in CVS or in git. Did it get lost and/or abandoned? -Eric From owner-xfs@oss.sgi.com Fri Oct 19 16:08:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 19 Oct 2007 16:08:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9JN8O3X023057 for ; Fri, 19 Oct 2007 16:08:25 -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 JAA12107; Sat, 20 Oct 2007 09:08:18 +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 l9JN8GdD72699470; Sat, 20 Oct 2007 09:08:17 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9JN8FDS70919556; Sat, 20 Oct 2007 09:08:15 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 20 Oct 2007 09:08:15 +1000 From: David Chinner To: Eric Sandeen Cc: David Chinner , xfs-oss Subject: Re: [PATCH] xfs: implement fallocate V2 Message-ID: <20071019230815.GK66820511@sgi.com> References: <20070713184125.GA12156@amitarora.in.ibm.com> <20070716053751.GN12413810@sgi.com> <4718F2EF.9050808@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4718F2EF.9050808@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4545/Wed Oct 17 14:05:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13401 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 On Fri, Oct 19, 2007 at 01:09:51PM -0500, Eric Sandeen wrote: > David Chinner wrote: > > Initial implementation of ->fallocate for XFS. > > > > Version 2: > > > > o Make allocation and setting the file size atomic. > > o Drop deallocate/punch functionality > > o use mode field appropriately to determine if size needs changing. > > > > Dave, I don't see this in CVS or in git. Did it get lost and/or abandoned? lost. I don't think I got a review of it, and I got swamped in other stuff at about the same time.... I'll look at it monday. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sat Oct 20 18:12:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 20 Oct 2007 18:12:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SUBJ_FORWARDED autolearn=no version=3.3.0-r574664 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9L1CfAt027356 for ; Sat, 20 Oct 2007 18:12:42 -0700 Received: by py-out-1112.google.com with SMTP id u77so1814198pyb for ; Sat, 20 Oct 2007 18:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ogAv5nv5qJok3lAuy8EIlh2x1SxEsTOszuVVzVKAaK4=; b=kkfgVK9Z2O90KoBJTl/uxyNgxnUYhWgWLKctgAQcmOA0oCp9fhNjwt3tu6wYXEXYpPhy7UApEfPMNHhHQxPIxOPR9TLByepAm03mcPm50VoaahUkVEDC5pvVHx+UVN98jBr6XWhtRf5n5jNOCtX3UPOtX818c2BBl69Q0ZaO1KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lRpT3dSxfRF7w1mReKenVES3kHY1xQ+fRuB7yi0neb06G7BgD92HzC9OAhAJeshVEY/kti9vQDyn2h7ySZup7GWrlkxb4N5fJtSz1aPjTdIAZSRHyTkEycphg3DKvVf29ZUkxMxvmMCaHEPRRcC90Tv9RyBR05p6D4ON2ozDhEg= Received: by 10.35.82.16 with SMTP id j16mr4072276pyl.1192928728141; Sat, 20 Oct 2007 18:05:28 -0700 (PDT) Received: by 10.35.71.6 with HTTP; Sat, 20 Oct 2007 18:05:27 -0700 (PDT) Message-ID: <6e0c99d0710201805k7ac77df0secce68307a76ca15@mail.gmail.com> Date: Sat, 20 Oct 2007 21:05:27 -0400 From: "Greg Martyn" To: xfs@oss.sgi.com Subject: Fwd: Ecartis command results: appsub xfs greg.martyn@gmail.com 471AA1B0:62C8.1:ksf In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13402 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: greg.martyn@gmail.com Precedence: bulk X-list: xfs is this a serious message? :-p ---------- Forwarded message ---------- From: Ecartis Date: Oct 20, 2007 9:02 PM Subject: Ecartis command results: appsub xfs greg.martyn@gmail.com 471AA1B0:62C8.1:ksf To: greg.martyn@gmail.com List context changed to 'xfs' by following command. >> appsub xfs greg.martyn@gmail.com 471AA1B0:62C8.1:ksf Unable to process request due to filesystem error. --- Ecartis v1.0.0 - job execution complete. From owner-xfs@oss.sgi.com Sat Oct 20 18:28:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 20 Oct 2007 18:28:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9L1SfDi029408 for ; Sat, 20 Oct 2007 18:28:43 -0700 Received: by py-out-1112.google.com with SMTP id u77so1818272pyb for ; Sat, 20 Oct 2007 18:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Na9s47S+ko3l5feKLk8TBhPUucl/yjJS4onx0MoOoXg=; b=C7ORgAi87Cq7xhq1bXQHGW3mJ787lfMH1LIAUmTIGpoUWNAwilojr9hbPOuXIOnsTBSWBCXMzn3iFI2MHjoCF9SqALnYgoi/eu3QeNh91rC9sH5UyNOP6nFe69VFFu6MRzR+JZmdIRIPWzPhZOY+oH9c2MSScM9qiDlBfsqEOrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tmXmNJ2jXoP2L9/rYHAD0V9f/I1o6cR6MYzOl+AVRQE+10RCzHs1ev4//gtknLIslVpGOGDmWjHmOyr84qlf67tj/4s7OTcernnxIp0F6Tu7s8c6B5IZyP++Cqce4X3rvFkWiLKCuZiARibkCiAhu9KWjTi+RopsQ42HdOAYLaE= Received: by 10.35.103.6 with SMTP id f6mr4080571pym.1192928534797; Sat, 20 Oct 2007 18:02:14 -0700 (PDT) Received: by 10.35.71.6 with HTTP; Sat, 20 Oct 2007 18:02:14 -0700 (PDT) Message-ID: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> Date: Sat, 20 Oct 2007 21:02:14 -0400 From: "Greg Martyn" To: xfs@oss.sgi.com Subject: mount: /dev/md0: can't read superblock MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13403 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: greg.martyn@gmail.com Precedence: bulk X-list: xfs Hi all, After running "xfs_fsr -v /home", I got a bunch of error messages saying that certain files (/home/.[three letters that i forgot]) couldn't be removed. After that, my system stopped working properly, so I restarted. Now: [root@localhost ~]# mount /dev/md0 /home/ mount: /dev/md0: can't read superblock uh oh. md0 is a raid5 that /proc/mdstat reports as working properly. [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# cat /etc/redhat-release Fedora release 7 (Moonshine) [root@localhost ~]# yum list xfsprogs xfsdump Loading "changelog" plugin Installed Packages xfsdump.x86_64 2.2.45-2.fc7 installed xfsprogs.i386 2.8.21-1.fc7 installed xfsprogs.x86_64 2.8.21-1.fc7 installed Any help is appreciated. Thanks, greg Here's dmesg when I try to mount: Filesystem "md0": Disabling barriers, not supported by the underlying device XFS mounting filesystem md0 Starting XFS recovery on filesystem: md0 (logdev: internal) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff88a394a3 Call Trace: [] :xfs:xfs_free_ag_extent+0x1a6/0x6b5 [] :xfs:xfs_free_extent+0xa9/0xc9 [] :xfs:xlog_recover_process_efi+0xfc/0x12f [] :xfs:xlog_recover_process_efis+0x4f/0x81 [] :xfs:xlog_recover_finish+0x19/0x9a [] :xfs:xfs_mountfs+0x830/0x94a [] set_blocksize+0x8c/0x99 [] :xfs:xfs_mount+0x317/0x39d [] :xfs:xfs_fs_fill_super+0x0/0x1aa [] :xfs:xfs_fs_fill_super+0x7e/0x1aa [] __down_write_nested+0x12/0x92 [] get_filesystem+0x12/0x35 [] sget+0x37f/0x391 [] set_bdev_super+0x0/0xf [] test_bdev_super+0x0/0xd [] get_sb_bdev+0x11d/0x16a [] vfs_kern_mount+0x93/0x11a [] do_kern_mount+0x43/0xdd [] do_mount+0x691/0x705 [] radix_tree_delete+0x1b4/0x1cc [] mntput_no_expire+0x1c/0x92 [] link_path_walk+0xce/0xe0 [] iput+0x42/0x7b [] do_path_lookup+0x1a3/0x21e [] getname+0x14c/0x1b2 [] zone_statistics+0x3f/0x60 [] __alloc_pages+0x72/0x2d4 [] sys_mount+0x8a/0xcd [] tracesys+0xd5/0xda XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff88a394a3 Call Trace: [] :xfs:xfs_free_ag_extent+0x1a6/0x6b5 [] :xfs:xfs_free_extent+0xa9/0xc9 [] :xfs:xfs_trans_log_efd_extent+0x1c/0x4b [] :xfs:xlog_recover_process_efi+0xfc/0x12f [] :xfs:xlog_recover_process_efis+0x4f/0x81 [] :xfs:xlog_recover_finish+0x19/0x9a [] :xfs:xfs_mountfs+0x830/0x94a [] set_blocksize+0x8c/0x99 [] :xfs:xfs_mount+0x317/0x39d [] :xfs:xfs_fs_fill_super+0x0/0x1aa [] :xfs:xfs_fs_fill_super+0x7e/0x1aa [] __down_write_nested+0x12/0x92 [] get_filesystem+0x12/0x35 [] sget+0x37f/0x391 [] set_bdev_super+0x0/0xf [] test_bdev_super+0x0/0xd [] get_sb_bdev+0x11d/0x16a [] vfs_kern_mount+0x93/0x11a [] do_kern_mount+0x43/0xdd [] do_mount+0x691/0x705 [] radix_tree_delete+0x1b4/0x1cc [] mntput_no_expire+0x1c/0x92 [] link_path_walk+0xce/0xe0 [] iput+0x42/0x7b [] do_path_lookup+0x1a3/0x21e [] getname+0x14c/0x1b2 [] zone_statistics+0x3f/0x60 [] __alloc_pages+0x72/0x2d4 [] sys_mount+0x8a/0xcd [] tracesys+0xd5/0xda XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff88a394a3 Call Trace: [] :xfs:xfs_free_ag_extent+0x1a6/0x6b5 [] :xfs:xfs_free_extent+0xa9/0xc9 [] :xfs:xfs_bmap_finish+0xee/0x167 [] :xfs:xfs_itruncate_finish+0x1a0/0x2e5 [] :xfs:xfs_inactive+0x241/0x43f [] :xfs:xfs_fs_clear_inode+0xa5/0xed [] clear_inode+0xdd/0x134 [] generic_delete_inode+0xd8/0x136 [] :xfs:xlog_recover_process_iunlinks+0x1d1/0x2f2 [] :xfs:xlog_recover_finish+0x39/0x9a [] :xfs:xfs_mountfs+0x830/0x94a [] set_blocksize+0x8c/0x99 [] :xfs:xfs_mount+0x317/0x39d [] :xfs:xfs_fs_fill_super+0x0/0x1aa [] :xfs:xfs_fs_fill_super+0x7e/0x1aa [] __down_write_nested+0x12/0x92 [] get_filesystem+0x12/0x35 [] sget+0x37f/0x391 [] set_bdev_super+0x0/0xf [] test_bdev_super+0x0/0xd [] get_sb_bdev+0x11d/0x16a [] vfs_kern_mount+0x93/0x11a [] do_kern_mount+0x43/0xdd [] do_mount+0x691/0x705 [] radix_tree_delete+0x1b4/0x1cc [] mntput_no_expire+0x1c/0x92 [] link_path_walk+0xce/0xe0 [] iput+0x42/0x7b [] do_path_lookup+0x1a3/0x21e [] getname+0x14c/0x1b2 [] zone_statistics+0x3f/0x60 [] __alloc_pages+0x72/0x2d4 [] sys_mount+0x8a/0xcd [] tracesys+0xd5/0xda xfs_force_shutdown(md0,0x8) called from line 4258 of file fs/xfs/xfs_bmap.c. Return address = 0xffffffff88a42894 Filesystem "md0": Corruption of in-memory data detected. Shutting down filesystem: md0 Please umount the filesystem, and rectify the problem(s) Ending XFS recovery on filesystem: md0 (logdev: internal) SELinux: (dev md0, type xfs) getxattr errno 5 xfs_force_shutdown(md0,0x1) called from line 423 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88a7d715 xfs_force_shutdown(md0,0x1) called from line 423 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88a7d715 From owner-xfs@oss.sgi.com Sun Oct 21 01:12:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 01:12:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9L8CVc7021220 for ; Sun, 21 Oct 2007 01:12:34 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8344A1C000275; Sun, 21 Oct 2007 04:12:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 5F9A54019581; Sun, 21 Oct 2007 04:12:34 -0400 (EDT) Date: Sun, 21 Oct 2007 04:12:34 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Greg Martyn cc: xfs@oss.sgi.com Subject: Re: Fwd: Ecartis command results: appsub xfs greg.martyn@gmail.com 471AA1B0:62C8.1:ksf In-Reply-To: <6e0c99d0710201805k7ac77df0secce68307a76ca15@mail.gmail.com> Message-ID: References: <6e0c99d0710201805k7ac77df0secce68307a76ca15@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13404 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 Not a good message to see on a filesystem mailing list :( On Sat, 20 Oct 2007, Greg Martyn wrote: > is this a serious message? :-p > > ---------- Forwarded message ---------- > From: Ecartis > Date: Oct 20, 2007 9:02 PM > Subject: Ecartis command results: appsub xfs greg.martyn@gmail.com > 471AA1B0:62C8.1:ksf > To: greg.martyn@gmail.com > > > > List context changed to 'xfs' by following command. >>> appsub xfs greg.martyn@gmail.com 471AA1B0:62C8.1:ksf > Unable to process request due to filesystem error. > > --- > Ecartis v1.0.0 - job execution complete. > > From owner-xfs@oss.sgi.com Sun Oct 21 01:16:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 01:16:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9L8GpOx022278 for ; Sun, 21 Oct 2007 01:16:53 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 2011A1C000275; Sun, 21 Oct 2007 04:16:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 1D1D74019581 for ; Sun, 21 Oct 2007 04:16:54 -0400 (EDT) Date: Sun, 21 Oct 2007 04:16:54 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: filesystem/disk paper seems to like XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13405 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 http://moo.nac.uci.edu/~hjm/sb/ What they do not talk about is how bad JFS "supposedly" gets after 1-2 years of usage regarding fragmentation and how there is no defragmenting tool for JFS. Justin. From owner-xfs@oss.sgi.com Sun Oct 21 07:34:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 07:34:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 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.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9LEYI1N016377 for ; Sun, 21 Oct 2007 07:34:22 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1IjaZQ-00012s-Hj for ; Sun, 21 Oct 2007 14:10:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18203.20410.194973.842271@base.ty.sabi.co.UK> Date: Sun, 21 Oct 2007 14:10:18 +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: filesystem/disk paper seems to like XFS In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13406 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 >>> On Sun, 21 Oct 2007 04:16:54 -0400 (EDT), Justin Piszcz >>> said: jpiszcz> What they do not talk about is how bad JFS "supposedly" jpiszcz> gets after 1-2 years of usage regarding fragmentation I have quite a bit of experience of JFS slowdown caused by fragmentation as I use JFS for my root filesystem and after a few months of very intense updates and rewrites overall speed goes down by a factor of around 2.5 which seems to me to be fairly good (at least as compared to a slowdown of a factor of 7 with 'ext3'). I have little idea of how much XFS slows down with time, as I don't use it for my ''root'' filesystem, but it seems comparable to JFS. This is not awesome either, but somewhat understandable. Part of the reason is that filesystem competitive benchmarks that file system designers care about seem all about freshly loaded filesystems; also it is not easy to do absolutely equivalent updates... And the claim to fame for XFS is not steady performance across updates, it is high aggregate multi-process/multi-stream performance *on a freshly constructed* filesystem (well, I have seen impressive performance in such a case). jpiszcz> and how there is no defragmenting tool for JFS. I have thought about taking an existing attempt as a JFS defragmenter and completing it, but I have realized that in-place defragmentation is usually a very bad idea in almost all cases, both for performance and safety reasons, and copying and switching is the only sensible way. The argument is that in most cases it is unsafe to defragment in-place without prior backup, and the backup is a much faster way to ''straighten out'' the files anyhow. Of course this runs into the problem that one has to take the filesystem offline for some time to switch, but then current file systems are simply not designed (with the claimed exception of ZFS suitably configured) as VLDBs (''a VLDB is a database that is so large that it is impractical to take it offline to backup''), just consider the 'fsck' time/space problem. From owner-xfs@oss.sgi.com Sun Oct 21 07:34:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 07:34:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 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.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9LEYOmP016385 for ; Sun, 21 Oct 2007 07:34:26 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1IjbPI-00016Z-QK for ; Sun, 21 Oct 2007 15:03:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <18203.23627.917581.549441@base.ty.sabi.co.UK> Date: Sun, 21 Oct 2007 15:03:55 +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: filesystem/disk paper seems to like XFS In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Virus-Scanned: ClamAV 0.91.2/4546/Sat Oct 20 05:46:40 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9LEYSmP016403 X-archive-position: 13407 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 >>> On Sun, 21 Oct 2007 04:16:54 -0400 (EDT), Justin Piszcz >>> said: > http://moo.nac.uci.edu/~hjm/sb/ Thanks for pointing to these tests, but as to their merit there are quite a few details that to me seem somewhat unclear or naive. One of the most amusing is this: «All the cards performed very well - bandwidth on large writes on a 16-disk RAID6 array was measured at >2GB/s on a large memory system and up to ~800MB/s on a RAM-constrained system.» So we have 14 data disks each of which has a raw top (outer tracks only) speed of around 60MB/s for a total of 840MB/s and these cards can instead write at over 2000MBs through a file systems? Hint: «on a large memory system» (and below «ability of writes to be partially cached») :-). Looks to me that the test is a complicated way to do 'hpdarm -T' :-). Even the 800MB/s for the «RAM-constrained system» seems a bit optimistic, as it is followed by: «Large reads were slower, reflecting the ability of writes to be partially cached, but were still measured at up to 570MB/s on a 16-disk RAID6.» While to my skeptical eye the «large memory system» test is about wholly cached writes, the the reported 800MB/s on RAID6 writes seems affected only by partial caching, but still rather significantly so, as it is rather very unlikely that write speed can exceed read speed on a RAID6 (assuming read speeds are reasonable and the reported ones are). Indeed unless perfectly aligned and sized writes are done (which is harder the wider the RAID6 is) write speeds will be much lower than read speeds. Therefore one of the conclusions: «The variable that contributed most to better performance was amount of system RAM. The more motherboard RAM your storage device has, the faster it will perform in almost all circumstances.» seems to me somewhat optimistic, unless «The Storage Brick» is to be renamed «The Page Cache Brick» :-). It would be interesting to see more details on the experimental setup, for example whether the test filesystems were unmounted between test phases (something that is forgotten by many), RAID creation parameters (chunk size, interleaving), filesystem creation parameters (alignment, stride) but I cannot access (insufficient permissions) the test script... Also, there is no mention of choice of elevator and flush parameters, which can have a very large impact on performance. From owner-xfs@oss.sgi.com Sun Oct 21 16:27:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 16:28:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9LNRqsI010243 for ; Sun, 21 Oct 2007 16:27:55 -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 JAA24077; Mon, 22 Oct 2007 09:27:46 +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 l9LNRjdD75778196; Mon, 22 Oct 2007 09:27:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9LNRhir75815876; Mon, 22 Oct 2007 09:27:43 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 22 Oct 2007 09:27:43 +1000 From: David Chinner To: Greg Martyn Cc: xfs@oss.sgi.com Subject: Re: mount: /dev/md0: can't read superblock Message-ID: <20071021232743.GU995458@sgi.com> References: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13408 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 On Sat, Oct 20, 2007 at 09:02:14PM -0400, Greg Martyn wrote: > Hi all, > After running "xfs_fsr -v /home", I got a bunch of error messages > saying that certain files (/home/.[three letters that i forgot]) > couldn't be removed. After that, my system stopped working properly, > so I restarted. Now: A corrupted freespace btree, by the look of it. What errors occurred you syslog when the system started playing up? I/O errors? Corruption errors? xfs_repair will probably be the only thing you can do here to correct the problem.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 21 16:50:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 16:51:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9LNormE013378 for ; Sun, 21 Oct 2007 16:50:57 -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 JAA24484 for ; Mon, 22 Oct 2007 09:50: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 l9LNordD74589954 for ; Mon, 22 Oct 2007 09:50:54 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9LNoqla75666509 for linux-xfs@oss.sgi.com; Mon, 22 Oct 2007 09:50:52 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 22 Oct 2007 09:50:52 +1000 From: David Chinner To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071021235052.GV995458@sgi.com> References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> <20071018220714.GM995458@sgi.com> <20071019101008.GA28175@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071019101008.GA28175@apartia.fr> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13409 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 On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote: > On Fri, Oct 19, 2007 at 08:07:14AM +1000, David Chinner wrote: > > On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand wrote: > > > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: > > > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > > > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > > > > > remove that file: > > > > > > > > > > sylla:/# rm /lost+found/3912672557 > > > > > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > > > > > > > > > sylla:/# ls -li /lost+found/3912672557 > > > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > > > > > > > Can you post the output of: > > > > > > > > # xfs_db -r -c "inode 3912672557" -c "p" > > > > > > Here: > > > > > > core.magic = 0x494e > > > core.mode = 0120777 > > > core.version = 1 > > > core.format = 1 (local) > > > core.nlinkv1 = 1 > > ..... > > > core.immutable = 1 > > ^^^^^^^^^^^^^^^^^^ > > > > You can't remove this link until you remove the immutable flag. > > > > # xfs_io -r -c "chattr -i" /lost+found/3912672557 > > sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557 > /lost+found/3912672557: No such file or directory Strange. This implies that lookup can't find inode # 3912672557. We know it is there... How many other files in the directory? Can you get the inode number for the lost+found directory and dump that with xfs_db (as per above)? Also, what happens if you "touch /lost+found/unix.7.gz" and try again? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 21 17:24:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 17:24:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9M0OhE8017633 for ; Sun, 21 Oct 2007 17:24:45 -0700 Received: from liberator.sandeen.net (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 1732A18013828; Sun, 21 Oct 2007 19:24:45 -0500 (CDT) Message-ID: <471BEDCD.3040104@sandeen.net> Date: Sun, 21 Oct 2007 19:24:45 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Greg Martyn CC: xfs@oss.sgi.com Subject: Re: mount: /dev/md0: can't read superblock References: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> In-Reply-To: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13410 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 Greg Martyn wrote: > Hi all, > After running "xfs_fsr -v /home", I got a bunch of error messages > saying that certain files (/home/.[three letters that i forgot]) > couldn't be removed. After that, my system stopped working properly, > so I restarted. Now: > > [root@localhost ~]# mount /dev/md0 /home/ > mount: /dev/md0: can't read superblock > > uh oh. dmesg says it's corrupted. You should probably run repair on it. But being raid, if something went wrong w/ the raid, that could make it worse... run xfs_repair -n and see what it *would* fix. -Eric From owner-xfs@oss.sgi.com Sun Oct 21 17:42:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 17:43:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9M0gMAS019900 for ; Sun, 21 Oct 2007 17:42:24 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA25674; Mon, 22 Oct 2007 10:42:19 +1000 Date: Mon, 22 Oct 2007 10:42:25 +1000 To: "David Chinner" , linux-xfs@oss.sgi.com, "Louis-David Mitterrand" Subject: Re: can't remove dir From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> <20071018220714.GM995458@sgi.com> <20071019101008.GA28175@apartia.fr> <20071021235052.GV995458@sgi.com> Message-ID: In-Reply-To: <20071021235052.GV995458@sgi.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l9M0gQAS019913 X-archive-position: 13411 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 22 Oct 2007 09:50:52 +1000, David Chinner wrote: > On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote: >> On Fri, Oct 19, 2007 at 08:07:14AM +1000, David Chinner wrote: >> > On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand >> wrote: >> > > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: >> > > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand >> wrote: >> > > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I >> can't >> > > > > remove that file: >> > > > > >> > > > > sylla:/# rm /lost+found/3912672557 >> > > > > rm: cannot remove `/lost+found/3912672557': Operation not >> permitted >> > > > > >> > > > > sylla:/# ls -li /lost+found/3912672557 >> > > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 >> /lost+found/3912672557 -> unix.7.gz >> > > > >> > > > Can you post the output of: >> > > > >> > > > # xfs_db -r -c "inode 3912672557" -c "p" >> > > >> > > Here: >> > > >> > > core.magic = 0x494e >> > > core.mode = 0120777 >> > > core.version = 1 >> > > core.format = 1 (local) >> > > core.nlinkv1 = 1 >> > ..... >> > > core.immutable = 1 >> > ^^^^^^^^^^^^^^^^^^ >> > >> > You can't remove this link until you remove the immutable flag. >> > >> > # xfs_io -r -c "chattr -i" /lost+found/3912672557 >> >> sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557 >> /lost+found/3912672557: No such file or directory > > Strange. This implies that lookup can't find inode # 3912672557. > We know it is there... > > How many other files in the directory? Can you get the inode number > for the lost+found directory and dump that with xfs_db (as per above)? > > Also, what happens if you "touch /lost+found/unix.7.gz" and try again? > > Cheers, > > Dave. Being a symbolic link, xfs_io follows them rather than operates on them directory. This will probably require xfs_db magic with the unmounted filesystem: # xfs_db -x -c "inode 3912672557" -c "write core.immutable 0" Barry. From owner-xfs@oss.sgi.com Sun Oct 21 17:53:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 17:53:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9M0r6xl021392 for ; Sun, 21 Oct 2007 17:53:09 -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 KAA25912; Mon, 22 Oct 2007 10:53:02 +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 l9M0r0dD75733312; Mon, 22 Oct 2007 10:53:01 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9M0qwCu74846736; Mon, 22 Oct 2007 10:52:58 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 22 Oct 2007 10:52:58 +1000 From: David Chinner To: Eric Sandeen Cc: Greg Martyn , xfs@oss.sgi.com Subject: Re: mount: /dev/md0: can't read superblock Message-ID: <20071022005258.GX995458@sgi.com> References: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> <471BEDCD.3040104@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471BEDCD.3040104@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13412 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 On Sun, Oct 21, 2007 at 07:24:45PM -0500, Eric Sandeen wrote: > Greg Martyn wrote: > > Hi all, > > After running "xfs_fsr -v /home", I got a bunch of error messages > > saying that certain files (/home/.[three letters that i forgot]) > > couldn't be removed. After that, my system stopped working properly, > > so I restarted. Now: > > > > [root@localhost ~]# mount /dev/md0 /home/ > > mount: /dev/md0: can't read superblock > > > > uh oh. > > dmesg says it's corrupted. > > You should probably run repair on it. But being raid, if something went > wrong w/ the raid, that could make it worse... run xfs_repair -n and see > what it *would* fix. xfs_repair does not check everything in the filesystem - some things it simply rebuilds - like the free space btrees. you want to run xfs_check to determine if the free space btrees are corrupt on disk or not.... ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 21 18:17:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 18:17:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9M1HZ8e024212 for ; Sun, 21 Oct 2007 18:17:38 -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 LAA26698; Mon, 22 Oct 2007 11:17:32 +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 l9M1HVdD75897851; Mon, 22 Oct 2007 11:17:31 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9M1HTdO75832845; Mon, 22 Oct 2007 11:17:29 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 22 Oct 2007 11:17:29 +1000 From: David Chinner To: Barry Naujok Cc: David Chinner , linux-xfs@oss.sgi.com, Louis-David Mitterrand Subject: Re: can't remove dir Message-ID: <20071022011729.GY995458@sgi.com> References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> <20071018220714.GM995458@sgi.com> <20071019101008.GA28175@apartia.fr> <20071021235052.GV995458@sgi.com> 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-Virus-Scanned: ClamAV 0.91.2/4554/Sun Oct 21 13:17:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13413 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 On Mon, Oct 22, 2007 at 10:42:25AM +1000, Barry Naujok wrote: > On Mon, 22 Oct 2007 09:50:52 +1000, David Chinner wrote: > >On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote: > >>sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557 > >>/lost+found/3912672557: No such file or directory > > > >Strange. This implies that lookup can't find inode # 3912672557. > >We know it is there... > > > >How many other files in the directory? Can you get the inode number > >for the lost+found directory and dump that with xfs_db (as per above)? > > > >Also, what happens if you "touch /lost+found/unix.7.gz" and try again? > > Being a symbolic link, xfs_io follows them rather than operates on > them directory. Actually, I tested that before posting. If the symlink is dangling, then the symlink gets the attributes attached to it: # ls -l /mnt/scratch/ total 0 lrwxrwxrwx 1 root root 22 Oct 22 11:09 foo -> /mnt/scratch/unix.7.gz # ls -l /mnt/scratch/unix.7.gz /bin/ls: /mnt/scratch/unix.7.gz: No such file or directory # xfs_io -f -r -c "lsattr" /mnt/scratch/foo -------------- /mnt/scratch/foo # xfs_io -f -c "chattr +i" /mnt/scratch/foo # xfs_io -f -r -c "lsattr" /mnt/scratch/foo --i----------- /mnt/scratch/foo # umount /mnt/scratch # mount !$ mount /mnt/scratch # xfs_io -f -r -c "lsattr" /mnt/scratch/foo --i----------- /mnt/scratch/foo # xfs_io -f -c "chattr -i" /mnt/scratch/foo -r # xfs_io -f -r -c "lsattr" /mnt/scratch/foo -------------- /mnt/scratch/foo # Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Oct 21 20:47:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 20:47:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9M3lXpv004396 for ; Sun, 21 Oct 2007 20:47:34 -0700 Received: by py-out-1112.google.com with SMTP id u77so2301826pyb for ; Sun, 21 Oct 2007 20:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8oHQ5TYnjc+B0wtXDvCKU43FN3dzTaoyuzhN3b5CM2Y=; b=UfveOv6mZtlbwdtiPYo6c+e+tTIJXhpxl/c2os0Xsm48fRyhs1E7TbuyCKeA/jpoaM1XEcOi1w81ABynfZ6GeKyofVLT1ZXM43dmUGt/rFK5kmv79IeML+cpVOJdZyGavFrhALpBAphp8qYP6CRqxMigwE53ZMub+r11dkxkwb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g0+JOISNM8x7T2aDG3Iz1I8bpawZUE0nBZ2y2fbRx/zb3gHWfGBN4z6TwsSIXulYc8RodO+SIKjJ9yBvTqY9HuWJxEABEzh6HULpDSY5Qm1VW78Nxf7iGAU7YoAPTbNyB5y/L85/6W/MGK+OSHKVCMrRigHUte9HYnTuLw1ja7M= Received: by 10.35.41.12 with SMTP id t12mr5616342pyj.1193024855721; Sun, 21 Oct 2007 20:47:35 -0700 (PDT) Received: by 10.35.71.6 with HTTP; Sun, 21 Oct 2007 20:47:35 -0700 (PDT) Message-ID: <6e0c99d0710212047r684d90d5wc6c0a009e0568edd@mail.gmail.com> Date: Sun, 21 Oct 2007 23:47:35 -0400 From: "Greg Martyn" To: "David Chinner" Subject: Re: mount: /dev/md0: can't read superblock Cc: "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <20071022005258.GX995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6e0c99d0710201802v2f41577dv38281b936a2389bf@mail.gmail.com> <471BEDCD.3040104@sandeen.net> <20071022005258.GX995458@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/4557/Sun Oct 21 19:25:44 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13414 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: greg.martyn@gmail.com Precedence: bulk X-list: xfs Thank you Eric and David. xfs_repair repaired the filesystem. I forgot to save the output of xfs_fsr (in case you were curious about what went wrong), but everything seems to be working fine again. I just won't be defragging again any time soon ;-) Thanks, greg On 10/21/07, David Chinner wrote: > On Sun, Oct 21, 2007 at 07:24:45PM -0500, Eric Sandeen wrote: > > Greg Martyn wrote: > > > Hi all, > > > After running "xfs_fsr -v /home", I got a bunch of error messages > > > saying that certain files (/home/.[three letters that i forgot]) > > > couldn't be removed. After that, my system stopped working properly, > > > so I restarted. Now: > > > > > > [root@localhost ~]# mount /dev/md0 /home/ > > > mount: /dev/md0: can't read superblock > > > > > > uh oh. > > > > dmesg says it's corrupted. > > > > You should probably run repair on it. But being raid, if something went > > wrong w/ the raid, that could make it worse... run xfs_repair -n and see > > what it *would* fix. > > xfs_repair does not check everything in the filesystem - some things it > simply rebuilds - like the free space btrees. you want to run xfs_check > to determine if the free space btrees are corrupt on disk or not.... ;) > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > From owner-xfs@oss.sgi.com Sun Oct 21 22:53:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 22:53:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9M5rbTY023391 for ; Sun, 21 Oct 2007 22:53:39 -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 PAA02928; Mon, 22 Oct 2007 15:53:35 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id D3D3558C38F1; Mon, 22 Oct 2007 15:53:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 907752 - Fix build for FreeBSD Message-Id: <20071022055334.D3D3558C38F1@chook.melbourne.sgi.com> Date: Mon, 22 Oct 2007 15:53:34 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 21:02:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13415 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Date: Mon Oct 22 15:53:10 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: rodrigc@crodrigues.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29935a xfsprogs/libxfs/freebsd.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/freebsd.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Fix build for FreeBSD From owner-xfs@oss.sgi.com Sun Oct 21 22:56:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 21 Oct 2007 22:56:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9M5un5p024198 for ; Sun, 21 Oct 2007 22:56: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 PAA02974; Mon, 22 Oct 2007 15:56:48 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 4EE6458C38F1; Mon, 22 Oct 2007 15:56:48 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 907752 - Fix attr man pages Message-Id: <20071022055648.4EE6458C38F1@chook.melbourne.sgi.com> Date: Mon, 22 Oct 2007 15:56:48 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 21:02:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13416 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Date: Mon Oct 22 15:56:28 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: rrt@sc3d.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29936a attr/man/man1/attr.1 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man1/attr.1.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h attr/man/man5/attr.5 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man5/attr.5.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - Fix attr man pages From owner-xfs@oss.sgi.com Mon Oct 22 00:06:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 22 Oct 2007 00:06:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47,SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9M74ONI009116 for ; Mon, 22 Oct 2007 00:06:27 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 65735302312F for ; Mon, 22 Oct 2007 09:04:26 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 21:02:57 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtH1ZbM-quuj for ; Mon, 22 Oct 2007 09:04:26 +0200 (CEST) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id 14C343000407 for ; Mon, 22 Oct 2007 09:04:26 +0200 (CEST) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 4E28DF0AF2F09 for ; Mon, 22 Oct 2007 09:04:25 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 37F54255DDC2; Mon, 22 Oct 2007 09:04:25 +0200 (CEST) Date: Mon, 22 Oct 2007 09:04:25 +0200 From: Louis-David Mitterrand To: linux-xfs@oss.sgi.com Subject: Re: can't remove dir Message-ID: <20071022070425.GA15091@apartia.fr> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20070914080926.GA30150@apartia.fr> <46EA9741.6060303@sandeen.net> <20071017161504.GA13077@apartia.fr> <20071017212434.GB995458@sgi.com> <20071018131116.GA11957@apartia.fr> <20071018220714.GM995458@sgi.com> <20071019101008.GA28175@apartia.fr> <20071021235052.GV995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071021235052.GV995458@sgi.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13417 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs On Mon, Oct 22, 2007 at 09:50:52AM +1000, David Chinner wrote: > On Fri, Oct 19, 2007 at 12:10:08PM +0200, Louis-David Mitterrand wrote: > > On Fri, Oct 19, 2007 at 08:07:14AM +1000, David Chinner wrote: > > > On Thu, Oct 18, 2007 at 03:11:16PM +0200, Louis-David Mitterrand wrote: > > > > On Thu, Oct 18, 2007 at 07:24:39AM +1000, David Chinner wrote: > > > > > On Wed, Oct 17, 2007 at 06:15:04PM +0200, Louis-David Mitterrand wrote: > > > > > > Using a 2.6.23 kernel and after a clean xfs_repair-2.9.4 run I can't > > > > > > remove that file: > > > > > > > > > > > > sylla:/# rm /lost+found/3912672557 > > > > > > rm: cannot remove `/lost+found/3912672557': Operation not permitted > > > > > > > > > > > > sylla:/# ls -li /lost+found/3912672557 > > > > > > 3912672557 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 /lost+found/3912672557 -> unix.7.gz > > > > > > > > > > Can you post the output of: > > > > > > > > > > # xfs_db -r -c "inode 3912672557" -c "p" > > > > > > > > Here: > > > > > > > > core.magic = 0x494e > > > > core.mode = 0120777 > > > > core.version = 1 > > > > core.format = 1 (local) > > > > core.nlinkv1 = 1 > > > ..... > > > > core.immutable = 1 > > > ^^^^^^^^^^^^^^^^^^ > > > > > > You can't remove this link until you remove the immutable flag. > > > > > > # xfs_io -r -c "chattr -i" /lost+found/3912672557 > > > > sylla:~# xfs_io -r -c "chattr -i" /lost+found/3912672557 > > /lost+found/3912672557: No such file or directory > > Strange. This implies that lookup can't find inode # 3912672557. > We know it is there... > > How many other files in the directory? Can you get the inode number > for the lost+found directory and dump that with xfs_db (as per above)? > > Also, what happens if you "touch /lost+found/unix.7.gz" and try again? sylla:/lost+found# touch /lost+found/unix.7.gz sylla:/lost+found# l total 0 lrwxrwxrwx 1 root root 9 2006-04-09 19:10 3912672557 -> unix.7.gz -rw-r--r-- 1 root root 0 2007-10-22 09:02 unix.7.gz sylla:/lost+found# xfs_io -r -c "chattr -i" /lost+found/3912672557 sylla:/lost+found# rm 3912672557 rm: remove symbolic link `3912672557'? y rm: cannot remove `3912672557': Operation not permitted From owner-xfs@oss.sgi.com Mon Oct 22 02:59:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 22 Oct 2007 02:59:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=ham version=3.3.0-r574664 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9M9xLbp005643 for ; Mon, 22 Oct 2007 02:59:24 -0700 Received: by wr-out-0506.google.com with SMTP id c48so785209wra for ; Mon, 22 Oct 2007 02:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=pE7lli83tPTrvr+rnGN/sZOsbh2lKmLr/zSOio5U5j4=; b=h4xwGNS7L59YpvEpCZjHWf81/45kI1fZf7rCP9hrCUMVYflhr66UfT/H1vhFLwuezCN/DKOwSrpdHUCqCGpn/MiNw7GkhqSNhYJGLFF1duAr3nEtB/drU/u6oSlRQtSHhMtNkSNEKmMhQoRdL1RBcWRDsPmsMlNqsUeMF1npc2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=stkIqnjn6NRt3885eHUw8elLcTIeeCOAsfdcgSrCJHudZu6YeBqpXlhzTO/W2EJfi3eAZYJsfN1vT/hwdo6eagLR9CTyoTqgmUNrP6EKYV2yk4rINCvlCed+tY8ruVvS7voE+x7oH6kG2lTNIknCWsd7wrQIaTdfvPvS96l+g/U= Received: by 10.142.47.6 with SMTP id u6mr1117800wfu.1193045521382; Mon, 22 Oct 2007 02:32:01 -0700 (PDT) Received: by 10.142.72.5 with HTTP; Mon, 22 Oct 2007 02:32:01 -0700 (PDT) Message-ID: <495eb0390710220232n419353bagfc8b0f879fa5e4a2@mail.gmail.com> Date: Mon, 22 Oct 2007 11:32:01 +0200 From: "Gideon Stupp" To: xfs@oss.sgi.com Subject: [PATCH] support static linking for xfsprogs. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: ClamAV 0.91.2/4559/Sun Oct 21 21:02:57 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13418 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gideon.stupp@gmail.com Precedence: bulk X-list: xfs Fix the make files to test --enable-shared and link accordingly. You get some annoying warnings when linked statically, but they all seem to come from known issues related to how glibc handles nsswitch.conf. Signed-off-by: Gideon Stupp Index: xfsprogs/copy/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/copy/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- xfsprogs/copy/Makefile 30 Jun 2006 14:38:12 -0000 1.4 +++ xfsprogs/copy/Makefile 22 Oct 2007 08:46:25 -0000 @@ -11,7 +11,13 @@ LLDLIBS = $(LIBXFS) $(LIBUUID) $(LIBPTHREAD) $(LIBRT) LTDEPENDENCIES = $(LIBXFS) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + default: $(LTCOMMAND) Index: xfsprogs/db/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/db/Makefile,v retrieving revision 1.18 diff -u -r1.18 Makefile --- xfsprogs/db/Makefile 7 Sep 2007 06:12:37 -0000 1.18 +++ xfsprogs/db/Makefile 22 Oct 2007 08:46:25 -0000 @@ -18,7 +18,13 @@ LSRCFILES = xfs_admin.sh xfs_check.sh xfs_ncheck.sh xfs_metadump.sh LLDLIBS = $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBXLOG) -LLDFLAGS += -static + +ifeq ($(ENABLE_SHARED),yes) +LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + ifeq ($(ENABLE_READLINE),yes) LLDLIBS += $(LIBREADLINE) $(LIBTERMCAP) Index: xfsprogs/growfs/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/growfs/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile --- xfsprogs/growfs/Makefile 7 Sep 2007 06:12:37 -0000 1.15 +++ xfsprogs/growfs/Makefile 22 Oct 2007 08:46:25 -0000 @@ -11,7 +11,13 @@ LLDLIBS = $(LIBXFS) $(LIBXCMD) $(LIBUUID) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBXCMD) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + LSRCFILES = xfs_info.sh default: $(LTCOMMAND) Index: xfsprogs/io/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/io/Makefile,v retrieving revision 1.19 diff -u -r1.19 Makefile --- xfsprogs/io/Makefile 17 Jun 2006 06:12:23 -0000 1.19 +++ xfsprogs/io/Makefile 22 Oct 2007 08:46:25 -0000 @@ -14,7 +14,13 @@ LLDLIBS = $(LIBXCMD) $(LIBHANDLE) LTDEPENDENCIES = $(LIBXCMD) $(LIBHANDLE) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + ifeq ($(HAVE_FADVISE),yes) CFILES += fadvise.c Index: xfsprogs/logprint/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/logprint/Makefile,v retrieving revision 1.14 diff -u -r1.14 Makefile --- xfsprogs/logprint/Makefile 7 Sep 2007 06:12:37 -0000 1.14 +++ xfsprogs/logprint/Makefile 22 Oct 2007 08:46:25 -0000 @@ -14,7 +14,13 @@ LLDLIBS = $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBXLOG) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + default: $(LTCOMMAND) Index: xfsprogs/mdrestore/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/mdrestore/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- xfsprogs/mdrestore/Makefile 7 Sep 2007 06:12:37 -0000 1.2 +++ xfsprogs/mdrestore/Makefile 22 Oct 2007 08:46:26 -0000 @@ -10,7 +10,13 @@ LLDLIBS = $(LIBXFS) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + default: $(LTCOMMAND) Index: xfsprogs/mkfs/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/mkfs/Makefile,v retrieving revision 1.18 diff -u -r1.18 Makefile --- xfsprogs/mkfs/Makefile 7 Sep 2007 06:12:37 -0000 1.18 +++ xfsprogs/mkfs/Makefile 22 Oct 2007 08:46:26 -0000 @@ -13,7 +13,12 @@ LLDLIBS = $(LIBXFS) $(LIBUUID) $(LIBDISK) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBDISK) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif LSRCFILES = $(FSTYP).c LDIRT = $(FSTYP) Index: xfsprogs/quota/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/quota/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- xfsprogs/quota/Makefile 11 Nov 2005 14:27:22 -0000 1.2 +++ xfsprogs/quota/Makefile 22 Oct 2007 08:46:26 -0000 @@ -16,7 +16,13 @@ LLDLIBS = $(LIBXCMD) LTDEPENDENCIES = $(LIBXCMD) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + ifeq ($(ENABLE_READLINE),yes) LLDLIBS += $(LIBREADLINE) $(LIBTERMCAP) Index: xfsprogs/repair/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/repair/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- xfsprogs/repair/Makefile 7 Sep 2007 06:12:37 -0000 1.20 +++ xfsprogs/repair/Makefile 22 Oct 2007 08:46:26 -0000 @@ -20,7 +20,13 @@ LLDLIBS = $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBXLOG) + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + default: $(LTCOMMAND) Index: xfsprogs/rtcp/Makefile =================================================================== RCS file: /cvs/xfs-cmds/xfsprogs/rtcp/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- xfsprogs/rtcp/Makefile 11 Nov 2005 14:27:22 -0000 1.8 +++ xfsprogs/rtcp/Makefile 22 Oct 2007 08:46:26 -0000 @@ -7,7 +7,13 @@ LTCOMMAND = xfs_rtcp CFILES = xfs_rtcp.c + +ifeq ($(ENABLE_SHARED),yes) LLDFLAGS = -static +else +LLDFLAGS = -all-static +endif + default: $(LTCOMMAND) From owner-xfs@oss.sgi.com Mon Oct 22 13:02:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 22 Oct 2007 21:38:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from daybreaker.counterpop.net (daybreaker.counterpop.net [216.129.104.218]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9MK2uEC018505 for ; Mon, 22 Oct 2007 13:02:59 -0700 Received: from [10.2.0.62] (nat-ext.sfo2.imeem.net [208.72.33.90]) by daybreaker.counterpop.net (Postfix) with ESMTP id 8F8439C4003 for ; Mon, 22 Oct 2007 12:03:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: xfs@oss.sgi.com From: Allan Hsu Subject: problems subscribing to this list. Date: Mon, 22 Oct 2007 12:03:50 -0700 X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV 0.91.2/4564/Mon Oct 22 10:59:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13420 X-Approved-By: donaldd@sgi.com X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: allan@counterpop.net Precedence: bulk X-list: xfs Sorry to spam the list with this, but I'm not sure who else to contact. I've been trying to subscribe to this list for a couple weeks, but I keep getting errors like this: List context changed to 'xfs' by following command. >> appsub xfs allan@counterpop.net 471CF171:4034.1:ksf >> Unable to process request due to filesystem error. --- Ecartis v1.0.0 - job execution complete. -Allan -- Allan Hsu I feel it all. From owner-xfs@oss.sgi.com Mon Oct 22 21:53:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 22 Oct 2007 21:53:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9N4rkct010370 for ; Mon, 22 Oct 2007 21:53:49 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06968; Tue, 23 Oct 2007 14:53:42 +1000 Message-ID: <471D7E55.9020103@sgi.com> Date: Tue, 23 Oct 2007 14:53:41 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Allan Hsu CC: xfs@oss.sgi.com Subject: Re: problems subscribing to this list. References: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> In-Reply-To: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4568/Mon Oct 22 21:23:16 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13421 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Allan Hsu wrote: > Sorry to spam the list with this, but I'm not sure who else to contact. > I've been trying to subscribe to this list for a couple weeks, but I > keep getting errors like this: > > List context changed to 'xfs' by following command. > >>> appsub xfs allan@counterpop.net 471CF171:4034.1:ksf >>> > Unable to process request due to filesystem error. > > --- > Ecartis v1.0.0 - job execution complete. > > -Allan > Hi Allan, I'll manually add you to the list while we try to figure this out. I cant see anything obvious is in the logs, and nothing filesystem specific. I suspect its an error specific to ecartis... _sigh_ Don From owner-xfs@oss.sgi.com Tue Oct 23 00:51:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 00:51:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9N7pE23005581 for ; Tue, 23 Oct 2007 00:51:17 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 RAA11338; Tue, 23 Oct 2007 17:51:16 +1000 Date: Tue, 23 Oct 2007 17:53:06 +1000 To: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Subject: [RFC 0/2] Case-insensitive filename lookup for XFS From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4569/Mon Oct 22 22:39:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13422 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Following is the initial test version of case-insensitive support for XFS in Linux. It implements case-insensitivity utilising a Unicode case folding table stored on disk generated from http://www.unicode.org/Public/UNIDATA/CaseFolding.txt As the filesystem stores names as Unicode (UTF-8), the "nls" mount option has been added to support systems not utilising UTF-8 natively. If the nls mount option is not used, it will use the default NLS defined in the kernel's config. To allow case-insensitivity to be a mount option rather than a mkfs option, the hashes stored on disk are always case-folded. This is indicated by the new "unicode" bit in the superblock. This bit also associated with the presence of the case-folding table on disk. With the case-folding table on disk, it allows us to upgrade the table in the future while retaining backwards and forwards compatibility. It also allows special case tables such as Turkic case which is supported in this patch set. The case-insensitive support also installs a couple of dentry_operations for the XFS inodes: hash and compare. Currently, there is a couple of outstanding issues with the dentry cache interaction: - The first lookup if case-mismatched will continue to have the mismatched case in the cache. Not really sure if this is an issue or not. If it is an issue, how should I resolve it? - As above, but with a non-existing lookup, then creating the file with a different case, the first failed lookup will define the case used. I have partially resolved this with a memcpy if the two lengths are the same. How do I fix this if the lengths are different? (TODO's show the location of this problem.) Other TODOs: - support for case-insensitve extended attributes as a separate mount option. - Other xfsprogs updates: xfs_repair, xfs_db From owner-xfs@oss.sgi.com Tue Oct 23 00:51:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 00:51:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14, J_CHICKENPOX_43,J_CHICKENPOX_47,J_CHICKENPOX_63,J_CHICKENPOX_72, J_CHICKENPOX_73,J_CHICKENPOX_75,J_CHICKENPOX_83 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9N7pKu0005601 for ; Tue, 23 Oct 2007 00:51:22 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 RAA11345; Tue, 23 Oct 2007 17:51:22 +1000 Date: Tue, 23 Oct 2007 17:53:12 +1000 To: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Subject: [RFC 2/2] Case-insensitive XFS - mkfs.xfs From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4569/Mon Oct 22 22:39:55 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l9N7pQu0005622 X-archive-position: 13424 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs include/xfs_sb.h | 27 +- libxfs/xfs_mount.c | 2 mkfs/Makefile | 2 mkfs/casefoldtable.c | 608 +++++++++++++++++++++++++++++++++++++++++++++++++++ mkfs/proto.c | 158 +++++++++++++ mkfs/xfs_mkfs.c | 93 ++++--- mkfs/xfs_mkfs.h | 24 +- 7 files changed, 866 insertions(+), 48 deletions(-) =========================================================================== xfsprogs/include/xfs_sb.h =========================================================================== --- a/xfsprogs/include/xfs_sb.h 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/include/xfs_sb.h 2007-10-23 16:56:07.765557256 +1000 @@ -46,10 +46,12 @@ struct xfs_mount; #define XFS_SB_VERSION_SECTORBIT 0x0800 #define XFS_SB_VERSION_EXTFLGBIT 0x1000 #define XFS_SB_VERSION_DIRV2BIT 0x2000 +#define XFS_SB_VERSION_OLDCIBIT 0x4000 #define XFS_SB_VERSION_MOREBITSBIT 0x8000 #define XFS_SB_VERSION_OKSASHFBITS \ (XFS_SB_VERSION_EXTFLGBIT | \ - XFS_SB_VERSION_DIRV2BIT) + XFS_SB_VERSION_DIRV2BIT | \ + XFS_SB_VERSION_OLDCIBIT) #define XFS_SB_VERSION_OKREALFBITS \ (XFS_SB_VERSION_ATTRBIT | \ XFS_SB_VERSION_NLINKBIT | \ @@ -82,13 +84,12 @@ struct xfs_mount; #define XFS_SB_VERSION2_DONOTUSEBIT2 0x00000004 #define XFS_SB_VERSION2_ATTR2BIT 0x00000008 /* Inline attr rework */ #define XFS_SB_VERSION2_PARENTBIT 0x00000010 /* Parent pointers */ -#define XFS_SB_VERSION2_SASHFBITS 0xff000000 /* Mask: features that - require changing - PROM and SASH */ +#define XFS_SB_VERSION2_UNICODEBIT 0x00000020 /* Unicode names */ #define XFS_SB_VERSION2_OKREALFBITS \ - (XFS_SB_VERSION2_ATTR2BIT | \ - XFS_SB_VERSION2_LAZYSBCOUNTBIT) + (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \ + XFS_SB_VERSION2_ATTR2BIT | \ + XFS_SB_VERSION2_UNICODEBIT) #define XFS_SB_VERSION2_OKSASHFBITS \ (0) #define XFS_SB_VERSION2_OKREALBITS \ @@ -151,6 +152,8 @@ typedef struct xfs_sb __uint16_t sb_logsectsize; /* sector size for the log, bytes */ __uint32_t sb_logsunit; /* stripe unit size for the log */ __uint32_t sb_features2; /* additional feature bits */ + __uint32_t sb_bad_features2; /* unusable space */ + xfs_ino_t sb_cftino; /* unicode case folding table inode */ } xfs_sb_t; /* @@ -169,7 +172,7 @@ typedef enum { XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN, XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG, XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT, - XFS_SBS_FEATURES2, + XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2, XFS_SBS_CFTINO, XFS_SBS_FIELDCOUNT } xfs_sb_field_t; @@ -194,13 +197,15 @@ typedef enum { #define XFS_SB_IFREE XFS_SB_MVAL(IFREE) #define XFS_SB_FDBLOCKS XFS_SB_MVAL(FDBLOCKS) #define XFS_SB_FEATURES2 XFS_SB_MVAL(FEATURES2) +#define XFS_SB_CFTINO XFS_SB_MVAL(CFTINO) #define XFS_SB_NUM_BITS ((int)XFS_SBS_FIELDCOUNT) #define XFS_SB_ALL_BITS ((1LL << XFS_SB_NUM_BITS) - 1) #define XFS_SB_MOD_BITS \ (XFS_SB_UUID | XFS_SB_ROOTINO | XFS_SB_RBMINO | XFS_SB_RSUMINO | \ XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO | XFS_SB_GQUOTINO | \ XFS_SB_QFLAGS | XFS_SB_SHARED_VN | XFS_SB_UNIT | XFS_SB_WIDTH | \ - XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2) + XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2 | \ + XFS_SB_CFTINO) /* @@ -455,6 +460,12 @@ static inline void xfs_sb_version_addatt ((sbp)->sb_features2 | XFS_SB_VERSION2_ATTR2BIT))); } +static inline int xfs_sb_version_hasunicode(xfs_sb_t *sbp) +{ + return (xfs_sb_version_hasmorebits(sbp) && \ + ((sbp)->sb_features2 & XFS_SB_VERSION2_UNICODEBIT)); +} + /* * end of superblock version macros */ =========================================================================== xfsprogs/libxfs/xfs_mount.c =========================================================================== --- a/xfsprogs/libxfs/xfs_mount.c 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/libxfs/xfs_mount.c 2007-10-23 16:52:26.438099100 +1000 @@ -140,6 +140,8 @@ static struct { { offsetof(xfs_sb_t, sb_logsectsize),0 }, { offsetof(xfs_sb_t, sb_logsunit), 0 }, { offsetof(xfs_sb_t, sb_features2), 0 }, + { offsetof(xfs_sb_t, sb_bad_features2), 0 }, + { offsetof(xfs_sb_t, sb_cftino), 0 }, { sizeof(xfs_sb_t), 0 } }; =========================================================================== xfsprogs/mkfs/Makefile =========================================================================== --- a/xfsprogs/mkfs/Makefile 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/mkfs/Makefile 2007-10-18 18:53:25.109349805 +1000 @@ -9,7 +9,7 @@ LTCOMMAND = mkfs.xfs FSTYP = fstyp HFILES = xfs_mkfs.h -CFILES = maxtrres.c proto.c xfs_mkfs.c +CFILES = casefoldtable.c maxtrres.c proto.c xfs_mkfs.c LLDLIBS = $(LIBXFS) $(LIBUUID) $(LIBDISK) $(LIBRT) $(LIBPTHREAD) LTDEPENDENCIES = $(LIBXFS) $(LIBDISK) =========================================================================== xfsprogs/mkfs/casefoldtable.c =========================================================================== --- a/xfsprogs/mkfs/casefoldtable.c 2006-06-17 00:58:24.000000000 +1000 +++ b/xfsprogs/mkfs/casefoldtable.c 2007-10-19 15:43:57.196235967 +1000 @@ -0,0 +1,608 @@ +/* + * Unicode case folding table automatically generated from + * http://www.unicode.org/Public/UNIDATA/CaseFolding.txt + * + * Characters that map to 0xe000 to 0xe3fff are indexes to the double + * character sequence in xfs_case_fold_double_table. 0xe400 to 0xe7ff + * map to the triple sequences in xfs_case_fold_triple_table. + */ + +#include + +__uint16_t xfs_case_fold_table[15 * 256] = { + + /* Most-significant-byte index table */ + + 0x0100, 0x0200, 0x0300, 0x0400, 0x0500, 0x0600, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0700, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0800, 0x0900, + 0x0000, 0x0a00, 0x0000, 0x0000, 0x0b00, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0c00, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, + 0x0000, 0x0000, 0x0000, 0x0d00, 0x0000, 0x0000, 0x0000, 0x0e00, + + /* Characters U+0000 to U+00FF */ + + 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, + 0x0008, 0x0009, 0x000a, 0x000b, 0x000c, 0x000d, 0x000e, 0x000f, + 0x0010, 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, 0x0016, 0x0017, + 0x0018, 0x0019, 0x001a, 0x001b, 0x001c, 0x001d, 0x001e, 0x001f, + 0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, + 0x0028, 0x0029, 0x002a, 0x002b, 0x002c, 0x002d, 0x002e, 0x002f, + 0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037, + 0x0038, 0x0039, 0x003a, 0x003b, 0x003c, 0x003d, 0x003e, 0x003f, + 0x0040, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, + 0x0068, 0x0069, 0x006a, 0x006b, 0x006c, 0x006d, 0x006e, 0x006f, + 0x0070, 0x0071, 0x0072, 0x0073, 0x0074, 0x0075, 0x0076, 0x0077, + 0x0078, 0x0079, 0x007a, 0x005b, 0x005c, 0x005d, 0x005e, 0x005f, + 0x0060, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, + 0x0068, 0x0069, 0x006a, 0x006b, 0x006c, 0x006d, 0x006e, 0x006f, + 0x0070, 0x0071, 0x0072, 0x0073, 0x0074, 0x0075, 0x0076, 0x0077, + 0x0078, 0x0079, 0x007a, 0x007b, 0x007c, 0x007d, 0x007e, 0x007f, + 0x0080, 0x0081, 0x0082, 0x0083, 0x0084, 0x0085, 0x0086, 0x0087, + 0x0088, 0x0089, 0x008a, 0x008b, 0x008c, 0x008d, 0x008e, 0x008f, + 0x0090, 0x0091, 0x0092, 0x0093, 0x0094, 0x0095, 0x0096, 0x0097, + 0x0098, 0x0099, 0x009a, 0x009b, 0x009c, 0x009d, 0x009e, 0x009f, + 0x00a0, 0x00a1, 0x00a2, 0x00a3, 0x00a4, 0x00a5, 0x00a6, 0x00a7, + 0x00a8, 0x00a9, 0x00aa, 0x00ab, 0x00ac, 0x00ad, 0x00ae, 0x00af, + 0x00b0, 0x00b1, 0x00b2, 0x00b3, 0x00b4, 0x03bc, 0x00b6, 0x00b7, + 0x00b8, 0x00b9, 0x00ba, 0x00bb, 0x00bc, 0x00bd, 0x00be, 0x00bf, + 0x00e0, 0x00e1, 0x00e2, 0x00e3, 0x00e4, 0x00e5, 0x00e6, 0x00e7, + 0x00e8, 0x00e9, 0x00ea, 0x00eb, 0x00ec, 0x00ed, 0x00ee, 0x00ef, + 0x00f0, 0x00f1, 0x00f2, 0x00f3, 0x00f4, 0x00f5, 0x00f6, 0x00d7, + 0x00f8, 0x00f9, 0x00fa, 0x00fb, 0x00fc, 0x00fd, 0x00fe, 0xe000, + 0x00e0, 0x00e1, 0x00e2, 0x00e3, 0x00e4, 0x00e5, 0x00e6, 0x00e7, + 0x00e8, 0x00e9, 0x00ea, 0x00eb, 0x00ec, 0x00ed, 0x00ee, 0x00ef, + 0x00f0, 0x00f1, 0x00f2, 0x00f3, 0x00f4, 0x00f5, 0x00f6, 0x00f7, + 0x00f8, 0x00f9, 0x00fa, 0x00fb, 0x00fc, 0x00fd, 0x00fe, 0x00ff, + + /* Characters U+0100 to U+01FF */ + + 0x0101, 0x0101, 0x0103, 0x0103, 0x0105, 0x0105, 0x0107, 0x0107, + 0x0109, 0x0109, 0x010b, 0x010b, 0x010d, 0x010d, 0x010f, 0x010f, + 0x0111, 0x0111, 0x0113, 0x0113, 0x0115, 0x0115, 0x0117, 0x0117, + 0x0119, 0x0119, 0x011b, 0x011b, 0x011d, 0x011d, 0x011f, 0x011f, + 0x0121, 0x0121, 0x0123, 0x0123, 0x0125, 0x0125, 0x0127, 0x0127, + 0x0129, 0x0129, 0x012b, 0x012b, 0x012d, 0x012d, 0x012f, 0x012f, + 0xe001, 0x0131, 0x0133, 0x0133, 0x0135, 0x0135, 0x0137, 0x0137, + 0x0138, 0x013a, 0x013a, 0x013c, 0x013c, 0x013e, 0x013e, 0x0140, + 0x0140, 0x0142, 0x0142, 0x0144, 0x0144, 0x0146, 0x0146, 0x0148, + 0x0148, 0xe002, 0x014b, 0x014b, 0x014d, 0x014d, 0x014f, 0x014f, + 0x0151, 0x0151, 0x0153, 0x0153, 0x0155, 0x0155, 0x0157, 0x0157, + 0x0159, 0x0159, 0x015b, 0x015b, 0x015d, 0x015d, 0x015f, 0x015f, + 0x0161, 0x0161, 0x0163, 0x0163, 0x0165, 0x0165, 0x0167, 0x0167, + 0x0169, 0x0169, 0x016b, 0x016b, 0x016d, 0x016d, 0x016f, 0x016f, + 0x0171, 0x0171, 0x0173, 0x0173, 0x0175, 0x0175, 0x0177, 0x0177, + 0x00ff, 0x017a, 0x017a, 0x017c, 0x017c, 0x017e, 0x017e, 0x0073, + 0x0180, 0x0253, 0x0183, 0x0183, 0x0185, 0x0185, 0x0254, 0x0188, + 0x0188, 0x0256, 0x0257, 0x018c, 0x018c, 0x018d, 0x01dd, 0x0259, + 0x025b, 0x0192, 0x0192, 0x0260, 0x0263, 0x0195, 0x0269, 0x0268, + 0x0199, 0x0199, 0x019a, 0x019b, 0x026f, 0x0272, 0x019e, 0x0275, + 0x01a1, 0x01a1, 0x01a3, 0x01a3, 0x01a5, 0x01a5, 0x0280, 0x01a8, + 0x01a8, 0x0283, 0x01aa, 0x01ab, 0x01ad, 0x01ad, 0x0288, 0x01b0, + 0x01b0, 0x028a, 0x028b, 0x01b4, 0x01b4, 0x01b6, 0x01b6, 0x0292, + 0x01b9, 0x01b9, 0x01ba, 0x01bb, 0x01bd, 0x01bd, 0x01be, 0x01bf, + 0x01c0, 0x01c1, 0x01c2, 0x01c3, 0x01c6, 0x01c6, 0x01c6, 0x01c9, + 0x01c9, 0x01c9, 0x01cc, 0x01cc, 0x01cc, 0x01ce, 0x01ce, 0x01d0, + 0x01d0, 0x01d2, 0x01d2, 0x01d4, 0x01d4, 0x01d6, 0x01d6, 0x01d8, + 0x01d8, 0x01da, 0x01da, 0x01dc, 0x01dc, 0x01dd, 0x01df, 0x01df, + 0x01e1, 0x01e1, 0x01e3, 0x01e3, 0x01e5, 0x01e5, 0x01e7, 0x01e7, + 0x01e9, 0x01e9, 0x01eb, 0x01eb, 0x01ed, 0x01ed, 0x01ef, 0x01ef, + 0xe003, 0x01f3, 0x01f3, 0x01f3, 0x01f5, 0x01f5, 0x0195, 0x01bf, + 0x01f9, 0x01f9, 0x01fb, 0x01fb, 0x01fd, 0x01fd, 0x01ff, 0x01ff, + + /* Characters U+0200 to U+02FF */ + + 0x0201, 0x0201, 0x0203, 0x0203, 0x0205, 0x0205, 0x0207, 0x0207, + 0x0209, 0x0209, 0x020b, 0x020b, 0x020d, 0x020d, 0x020f, 0x020f, + 0x0211, 0x0211, 0x0213, 0x0213, 0x0215, 0x0215, 0x0217, 0x0217, + 0x0219, 0x0219, 0x021b, 0x021b, 0x021d, 0x021d, 0x021f, 0x021f, + 0x019e, 0x0221, 0x0223, 0x0223, 0x0225, 0x0225, 0x0227, 0x0227, + 0x0229, 0x0229, 0x022b, 0x022b, 0x022d, 0x022d, 0x022f, 0x022f, + 0x0231, 0x0231, 0x0233, 0x0233, 0x0234, 0x0235, 0x0236, 0x0237, + 0x0238, 0x0239, 0x2c65, 0x023c, 0x023c, 0x019a, 0x2c66, 0x023f, + 0x0240, 0x0242, 0x0242, 0x0180, 0x0289, 0x028c, 0x0247, 0x0247, + 0x0249, 0x0249, 0x024b, 0x024b, 0x024d, 0x024d, 0x024f, 0x024f, + 0x0250, 0x0251, 0x0252, 0x0253, 0x0254, 0x0255, 0x0256, 0x0257, + 0x0258, 0x0259, 0x025a, 0x025b, 0x025c, 0x025d, 0x025e, 0x025f, + 0x0260, 0x0261, 0x0262, 0x0263, 0x0264, 0x0265, 0x0266, 0x0267, + 0x0268, 0x0269, 0x026a, 0x026b, 0x026c, 0x026d, 0x026e, 0x026f, + 0x0270, 0x0271, 0x0272, 0x0273, 0x0274, 0x0275, 0x0276, 0x0277, + 0x0278, 0x0279, 0x027a, 0x027b, 0x027c, 0x027d, 0x027e, 0x027f, + 0x0280, 0x0281, 0x0282, 0x0283, 0x0284, 0x0285, 0x0286, 0x0287, + 0x0288, 0x0289, 0x028a, 0x028b, 0x028c, 0x028d, 0x028e, 0x028f, + 0x0290, 0x0291, 0x0292, 0x0293, 0x0294, 0x0295, 0x0296, 0x0297, + 0x0298, 0x0299, 0x029a, 0x029b, 0x029c, 0x029d, 0x029e, 0x029f, + 0x02a0, 0x02a1, 0x02a2, 0x02a3, 0x02a4, 0x02a5, 0x02a6, 0x02a7, + 0x02a8, 0x02a9, 0x02aa, 0x02ab, 0x02ac, 0x02ad, 0x02ae, 0x02af, + 0x02b0, 0x02b1, 0x02b2, 0x02b3, 0x02b4, 0x02b5, 0x02b6, 0x02b7, + 0x02b8, 0x02b9, 0x02ba, 0x02bb, 0x02bc, 0x02bd, 0x02be, 0x02bf, + 0x02c0, 0x02c1, 0x02c2, 0x02c3, 0x02c4, 0x02c5, 0x02c6, 0x02c7, + 0x02c8, 0x02c9, 0x02ca, 0x02cb, 0x02cc, 0x02cd, 0x02ce, 0x02cf, + 0x02d0, 0x02d1, 0x02d2, 0x02d3, 0x02d4, 0x02d5, 0x02d6, 0x02d7, + 0x02d8, 0x02d9, 0x02da, 0x02db, 0x02dc, 0x02dd, 0x02de, 0x02df, + 0x02e0, 0x02e1, 0x02e2, 0x02e3, 0x02e4, 0x02e5, 0x02e6, 0x02e7, + 0x02e8, 0x02e9, 0x02ea, 0x02eb, 0x02ec, 0x02ed, 0x02ee, 0x02ef, + 0x02f0, 0x02f1, 0x02f2, 0x02f3, 0x02f4, 0x02f5, 0x02f6, 0x02f7, + 0x02f8, 0x02f9, 0x02fa, 0x02fb, 0x02fc, 0x02fd, 0x02fe, 0x02ff, + + /* Characters U+0300 to U+03FF */ + + 0x0300, 0x0301, 0x0302, 0x0303, 0x0304, 0x0305, 0x0306, 0x0307, + 0x0308, 0x0309, 0x030a, 0x030b, 0x030c, 0x030d, 0x030e, 0x030f, + 0x0310, 0x0311, 0x0312, 0x0313, 0x0314, 0x0315, 0x0316, 0x0317, + 0x0318, 0x0319, 0x031a, 0x031b, 0x031c, 0x031d, 0x031e, 0x031f, + 0x0320, 0x0321, 0x0322, 0x0323, 0x0324, 0x0325, 0x0326, 0x0327, + 0x0328, 0x0329, 0x032a, 0x032b, 0x032c, 0x032d, 0x032e, 0x032f, + 0x0330, 0x0331, 0x0332, 0x0333, 0x0334, 0x0335, 0x0336, 0x0337, + 0x0338, 0x0339, 0x033a, 0x033b, 0x033c, 0x033d, 0x033e, 0x033f, + 0x0340, 0x0341, 0x0342, 0x0343, 0x0344, 0x03b9, 0x0346, 0x0347, + 0x0348, 0x0349, 0x034a, 0x034b, 0x034c, 0x034d, 0x034e, 0x034f, + 0x0350, 0x0351, 0x0352, 0x0353, 0x0354, 0x0355, 0x0356, 0x0357, + 0x0358, 0x0359, 0x035a, 0x035b, 0x035c, 0x035d, 0x035e, 0x035f, + 0x0360, 0x0361, 0x0362, 0x0363, 0x0364, 0x0365, 0x0366, 0x0367, + 0x0368, 0x0369, 0x036a, 0x036b, 0x036c, 0x036d, 0x036e, 0x036f, + 0x0370, 0x0371, 0x0372, 0x0373, 0x0374, 0x0375, 0x0376, 0x0377, + 0x0378, 0x0379, 0x037a, 0x037b, 0x037c, 0x037d, 0x037e, 0x037f, + 0x0380, 0x0381, 0x0382, 0x0383, 0x0384, 0x0385, 0x03ac, 0x0387, + 0x03ad, 0x03ae, 0x03af, 0x038b, 0x03cc, 0x038d, 0x03cd, 0x03ce, + 0xe400, 0x03b1, 0x03b2, 0x03b3, 0x03b4, 0x03b5, 0x03b6, 0x03b7, + 0x03b8, 0x03b9, 0x03ba, 0x03bb, 0x03bc, 0x03bd, 0x03be, 0x03bf, + 0x03c0, 0x03c1, 0x03a2, 0x03c3, 0x03c4, 0x03c5, 0x03c6, 0x03c7, + 0x03c8, 0x03c9, 0x03ca, 0x03cb, 0x03ac, 0x03ad, 0x03ae, 0x03af, + 0xe401, 0x03b1, 0x03b2, 0x03b3, 0x03b4, 0x03b5, 0x03b6, 0x03b7, + 0x03b8, 0x03b9, 0x03ba, 0x03bb, 0x03bc, 0x03bd, 0x03be, 0x03bf, + 0x03c0, 0x03c1, 0x03c3, 0x03c3, 0x03c4, 0x03c5, 0x03c6, 0x03c7, + 0x03c8, 0x03c9, 0x03ca, 0x03cb, 0x03cc, 0x03cd, 0x03ce, 0x03cf, + 0x03b2, 0x03b8, 0x03d2, 0x03d3, 0x03d4, 0x03c6, 0x03c0, 0x03d7, + 0x03d9, 0x03d9, 0x03db, 0x03db, 0x03dd, 0x03dd, 0x03df, 0x03df, + 0x03e1, 0x03e1, 0x03e3, 0x03e3, 0x03e5, 0x03e5, 0x03e7, 0x03e7, + 0x03e9, 0x03e9, 0x03eb, 0x03eb, 0x03ed, 0x03ed, 0x03ef, 0x03ef, + 0x03ba, 0x03c1, 0x03f2, 0x03f3, 0x03b8, 0x03b5, 0x03f6, 0x03f8, + 0x03f8, 0x03f2, 0x03fb, 0x03fb, 0x03fc, 0x037b, 0x037c, 0x037d, + + /* Characters U+0400 to U+04FF */ + + 0x0450, 0x0451, 0x0452, 0x0453, 0x0454, 0x0455, 0x0456, 0x0457, + 0x0458, 0x0459, 0x045a, 0x045b, 0x045c, 0x045d, 0x045e, 0x045f, + 0x0430, 0x0431, 0x0432, 0x0433, 0x0434, 0x0435, 0x0436, 0x0437, + 0x0438, 0x0439, 0x043a, 0x043b, 0x043c, 0x043d, 0x043e, 0x043f, + 0x0440, 0x0441, 0x0442, 0x0443, 0x0444, 0x0445, 0x0446, 0x0447, + 0x0448, 0x0449, 0x044a, 0x044b, 0x044c, 0x044d, 0x044e, 0x044f, + 0x0430, 0x0431, 0x0432, 0x0433, 0x0434, 0x0435, 0x0436, 0x0437, + 0x0438, 0x0439, 0x043a, 0x043b, 0x043c, 0x043d, 0x043e, 0x043f, + 0x0440, 0x0441, 0x0442, 0x0443, 0x0444, 0x0445, 0x0446, 0x0447, + 0x0448, 0x0449, 0x044a, 0x044b, 0x044c, 0x044d, 0x044e, 0x044f, + 0x0450, 0x0451, 0x0452, 0x0453, 0x0454, 0x0455, 0x0456, 0x0457, + 0x0458, 0x0459, 0x045a, 0x045b, 0x045c, 0x045d, 0x045e, 0x045f, + 0x0461, 0x0461, 0x0463, 0x0463, 0x0465, 0x0465, 0x0467, 0x0467, + 0x0469, 0x0469, 0x046b, 0x046b, 0x046d, 0x046d, 0x046f, 0x046f, + 0x0471, 0x0471, 0x0473, 0x0473, 0x0475, 0x0475, 0x0477, 0x0477, + 0x0479, 0x0479, 0x047b, 0x047b, 0x047d, 0x047d, 0x047f, 0x047f, + 0x0481, 0x0481, 0x0482, 0x0483, 0x0484, 0x0485, 0x0486, 0x0487, + 0x0488, 0x0489, 0x048b, 0x048b, 0x048d, 0x048d, 0x048f, 0x048f, + 0x0491, 0x0491, 0x0493, 0x0493, 0x0495, 0x0495, 0x0497, 0x0497, + 0x0499, 0x0499, 0x049b, 0x049b, 0x049d, 0x049d, 0x049f, 0x049f, + 0x04a1, 0x04a1, 0x04a3, 0x04a3, 0x04a5, 0x04a5, 0x04a7, 0x04a7, + 0x04a9, 0x04a9, 0x04ab, 0x04ab, 0x04ad, 0x04ad, 0x04af, 0x04af, + 0x04b1, 0x04b1, 0x04b3, 0x04b3, 0x04b5, 0x04b5, 0x04b7, 0x04b7, + 0x04b9, 0x04b9, 0x04bb, 0x04bb, 0x04bd, 0x04bd, 0x04bf, 0x04bf, + 0x04cf, 0x04c2, 0x04c2, 0x04c4, 0x04c4, 0x04c6, 0x04c6, 0x04c8, + 0x04c8, 0x04ca, 0x04ca, 0x04cc, 0x04cc, 0x04ce, 0x04ce, 0x04cf, + 0x04d1, 0x04d1, 0x04d3, 0x04d3, 0x04d5, 0x04d5, 0x04d7, 0x04d7, + 0x04d9, 0x04d9, 0x04db, 0x04db, 0x04dd, 0x04dd, 0x04df, 0x04df, + 0x04e1, 0x04e1, 0x04e3, 0x04e3, 0x04e5, 0x04e5, 0x04e7, 0x04e7, + 0x04e9, 0x04e9, 0x04eb, 0x04eb, 0x04ed, 0x04ed, 0x04ef, 0x04ef, + 0x04f1, 0x04f1, 0x04f3, 0x04f3, 0x04f5, 0x04f5, 0x04f7, 0x04f7, + 0x04f9, 0x04f9, 0x04fb, 0x04fb, 0x04fd, 0x04fd, 0x04ff, 0x04ff, + + /* Characters U+0500 to U+05FF */ + + 0x0501, 0x0501, 0x0503, 0x0503, 0x0505, 0x0505, 0x0507, 0x0507, + 0x0509, 0x0509, 0x050b, 0x050b, 0x050d, 0x050d, 0x050f, 0x050f, + 0x0511, 0x0511, 0x0513, 0x0513, 0x0514, 0x0515, 0x0516, 0x0517, + 0x0518, 0x0519, 0x051a, 0x051b, 0x051c, 0x051d, 0x051e, 0x051f, + 0x0520, 0x0521, 0x0522, 0x0523, 0x0524, 0x0525, 0x0526, 0x0527, + 0x0528, 0x0529, 0x052a, 0x052b, 0x052c, 0x052d, 0x052e, 0x052f, + 0x0530, 0x0561, 0x0562, 0x0563, 0x0564, 0x0565, 0x0566, 0x0567, + 0x0568, 0x0569, 0x056a, 0x056b, 0x056c, 0x056d, 0x056e, 0x056f, + 0x0570, 0x0571, 0x0572, 0x0573, 0x0574, 0x0575, 0x0576, 0x0577, + 0x0578, 0x0579, 0x057a, 0x057b, 0x057c, 0x057d, 0x057e, 0x057f, + 0x0580, 0x0581, 0x0582, 0x0583, 0x0584, 0x0585, 0x0586, 0x0557, + 0x0558, 0x0559, 0x055a, 0x055b, 0x055c, 0x055d, 0x055e, 0x055f, + 0x0560, 0x0561, 0x0562, 0x0563, 0x0564, 0x0565, 0x0566, 0x0567, + 0x0568, 0x0569, 0x056a, 0x056b, 0x056c, 0x056d, 0x056e, 0x056f, + 0x0570, 0x0571, 0x0572, 0x0573, 0x0574, 0x0575, 0x0576, 0x0577, + 0x0578, 0x0579, 0x057a, 0x057b, 0x057c, 0x057d, 0x057e, 0x057f, + 0x0580, 0x0581, 0x0582, 0x0583, 0x0584, 0x0585, 0x0586, 0xe004, + 0x0588, 0x0589, 0x058a, 0x058b, 0x058c, 0x058d, 0x058e, 0x058f, + 0x0590, 0x0591, 0x0592, 0x0593, 0x0594, 0x0595, 0x0596, 0x0597, + 0x0598, 0x0599, 0x059a, 0x059b, 0x059c, 0x059d, 0x059e, 0x059f, + 0x05a0, 0x05a1, 0x05a2, 0x05a3, 0x05a4, 0x05a5, 0x05a6, 0x05a7, + 0x05a8, 0x05a9, 0x05aa, 0x05ab, 0x05ac, 0x05ad, 0x05ae, 0x05af, + 0x05b0, 0x05b1, 0x05b2, 0x05b3, 0x05b4, 0x05b5, 0x05b6, 0x05b7, + 0x05b8, 0x05b9, 0x05ba, 0x05bb, 0x05bc, 0x05bd, 0x05be, 0x05bf, + 0x05c0, 0x05c1, 0x05c2, 0x05c3, 0x05c4, 0x05c5, 0x05c6, 0x05c7, + 0x05c8, 0x05c9, 0x05ca, 0x05cb, 0x05cc, 0x05cd, 0x05ce, 0x05cf, + 0x05d0, 0x05d1, 0x05d2, 0x05d3, 0x05d4, 0x05d5, 0x05d6, 0x05d7, + 0x05d8, 0x05d9, 0x05da, 0x05db, 0x05dc, 0x05dd, 0x05de, 0x05df, + 0x05e0, 0x05e1, 0x05e2, 0x05e3, 0x05e4, 0x05e5, 0x05e6, 0x05e7, + 0x05e8, 0x05e9, 0x05ea, 0x05eb, 0x05ec, 0x05ed, 0x05ee, 0x05ef, + 0x05f0, 0x05f1, 0x05f2, 0x05f3, 0x05f4, 0x05f5, 0x05f6, 0x05f7, + 0x05f8, 0x05f9, 0x05fa, 0x05fb, 0x05fc, 0x05fd, 0x05fe, 0x05ff, + + /* Characters U+1000 to U+10FF */ + + 0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007, + 0x1008, 0x1009, 0x100a, 0x100b, 0x100c, 0x100d, 0x100e, 0x100f, + 0x1010, 0x1011, 0x1012, 0x1013, 0x1014, 0x1015, 0x1016, 0x1017, + 0x1018, 0x1019, 0x101a, 0x101b, 0x101c, 0x101d, 0x101e, 0x101f, + 0x1020, 0x1021, 0x1022, 0x1023, 0x1024, 0x1025, 0x1026, 0x1027, + 0x1028, 0x1029, 0x102a, 0x102b, 0x102c, 0x102d, 0x102e, 0x102f, + 0x1030, 0x1031, 0x1032, 0x1033, 0x1034, 0x1035, 0x1036, 0x1037, + 0x1038, 0x1039, 0x103a, 0x103b, 0x103c, 0x103d, 0x103e, 0x103f, + 0x1040, 0x1041, 0x1042, 0x1043, 0x1044, 0x1045, 0x1046, 0x1047, + 0x1048, 0x1049, 0x104a, 0x104b, 0x104c, 0x104d, 0x104e, 0x104f, + 0x1050, 0x1051, 0x1052, 0x1053, 0x1054, 0x1055, 0x1056, 0x1057, + 0x1058, 0x1059, 0x105a, 0x105b, 0x105c, 0x105d, 0x105e, 0x105f, + 0x1060, 0x1061, 0x1062, 0x1063, 0x1064, 0x1065, 0x1066, 0x1067, + 0x1068, 0x1069, 0x106a, 0x106b, 0x106c, 0x106d, 0x106e, 0x106f, + 0x1070, 0x1071, 0x1072, 0x1073, 0x1074, 0x1075, 0x1076, 0x1077, + 0x1078, 0x1079, 0x107a, 0x107b, 0x107c, 0x107d, 0x107e, 0x107f, + 0x1080, 0x1081, 0x1082, 0x1083, 0x1084, 0x1085, 0x1086, 0x1087, + 0x1088, 0x1089, 0x108a, 0x108b, 0x108c, 0x108d, 0x108e, 0x108f, + 0x1090, 0x1091, 0x1092, 0x1093, 0x1094, 0x1095, 0x1096, 0x1097, + 0x1098, 0x1099, 0x109a, 0x109b, 0x109c, 0x109d, 0x109e, 0x109f, + 0x2d00, 0x2d01, 0x2d02, 0x2d03, 0x2d04, 0x2d05, 0x2d06, 0x2d07, + 0x2d08, 0x2d09, 0x2d0a, 0x2d0b, 0x2d0c, 0x2d0d, 0x2d0e, 0x2d0f, + 0x2d10, 0x2d11, 0x2d12, 0x2d13, 0x2d14, 0x2d15, 0x2d16, 0x2d17, + 0x2d18, 0x2d19, 0x2d1a, 0x2d1b, 0x2d1c, 0x2d1d, 0x2d1e, 0x2d1f, + 0x2d20, 0x2d21, 0x2d22, 0x2d23, 0x2d24, 0x2d25, 0x10c6, 0x10c7, + 0x10c8, 0x10c9, 0x10ca, 0x10cb, 0x10cc, 0x10cd, 0x10ce, 0x10cf, + 0x10d0, 0x10d1, 0x10d2, 0x10d3, 0x10d4, 0x10d5, 0x10d6, 0x10d7, + 0x10d8, 0x10d9, 0x10da, 0x10db, 0x10dc, 0x10dd, 0x10de, 0x10df, + 0x10e0, 0x10e1, 0x10e2, 0x10e3, 0x10e4, 0x10e5, 0x10e6, 0x10e7, + 0x10e8, 0x10e9, 0x10ea, 0x10eb, 0x10ec, 0x10ed, 0x10ee, 0x10ef, + 0x10f0, 0x10f1, 0x10f2, 0x10f3, 0x10f4, 0x10f5, 0x10f6, 0x10f7, + 0x10f8, 0x10f9, 0x10fa, 0x10fb, 0x10fc, 0x10fd, 0x10fe, 0x10ff, + + /* Characters U+1E00 to U+1EFF */ + + 0x1e01, 0x1e01, 0x1e03, 0x1e03, 0x1e05, 0x1e05, 0x1e07, 0x1e07, + 0x1e09, 0x1e09, 0x1e0b, 0x1e0b, 0x1e0d, 0x1e0d, 0x1e0f, 0x1e0f, + 0x1e11, 0x1e11, 0x1e13, 0x1e13, 0x1e15, 0x1e15, 0x1e17, 0x1e17, + 0x1e19, 0x1e19, 0x1e1b, 0x1e1b, 0x1e1d, 0x1e1d, 0x1e1f, 0x1e1f, + 0x1e21, 0x1e21, 0x1e23, 0x1e23, 0x1e25, 0x1e25, 0x1e27, 0x1e27, + 0x1e29, 0x1e29, 0x1e2b, 0x1e2b, 0x1e2d, 0x1e2d, 0x1e2f, 0x1e2f, + 0x1e31, 0x1e31, 0x1e33, 0x1e33, 0x1e35, 0x1e35, 0x1e37, 0x1e37, + 0x1e39, 0x1e39, 0x1e3b, 0x1e3b, 0x1e3d, 0x1e3d, 0x1e3f, 0x1e3f, + 0x1e41, 0x1e41, 0x1e43, 0x1e43, 0x1e45, 0x1e45, 0x1e47, 0x1e47, + 0x1e49, 0x1e49, 0x1e4b, 0x1e4b, 0x1e4d, 0x1e4d, 0x1e4f, 0x1e4f, + 0x1e51, 0x1e51, 0x1e53, 0x1e53, 0x1e55, 0x1e55, 0x1e57, 0x1e57, + 0x1e59, 0x1e59, 0x1e5b, 0x1e5b, 0x1e5d, 0x1e5d, 0x1e5f, 0x1e5f, + 0x1e61, 0x1e61, 0x1e63, 0x1e63, 0x1e65, 0x1e65, 0x1e67, 0x1e67, + 0x1e69, 0x1e69, 0x1e6b, 0x1e6b, 0x1e6d, 0x1e6d, 0x1e6f, 0x1e6f, + 0x1e71, 0x1e71, 0x1e73, 0x1e73, 0x1e75, 0x1e75, 0x1e77, 0x1e77, + 0x1e79, 0x1e79, 0x1e7b, 0x1e7b, 0x1e7d, 0x1e7d, 0x1e7f, 0x1e7f, + 0x1e81, 0x1e81, 0x1e83, 0x1e83, 0x1e85, 0x1e85, 0x1e87, 0x1e87, + 0x1e89, 0x1e89, 0x1e8b, 0x1e8b, 0x1e8d, 0x1e8d, 0x1e8f, 0x1e8f, + 0x1e91, 0x1e91, 0x1e93, 0x1e93, 0x1e95, 0x1e95, 0xe005, 0xe006, + 0xe007, 0xe008, 0xe009, 0x1e61, 0x1e9c, 0x1e9d, 0x1e9e, 0x1e9f, + 0x1ea1, 0x1ea1, 0x1ea3, 0x1ea3, 0x1ea5, 0x1ea5, 0x1ea7, 0x1ea7, + 0x1ea9, 0x1ea9, 0x1eab, 0x1eab, 0x1ead, 0x1ead, 0x1eaf, 0x1eaf, + 0x1eb1, 0x1eb1, 0x1eb3, 0x1eb3, 0x1eb5, 0x1eb5, 0x1eb7, 0x1eb7, + 0x1eb9, 0x1eb9, 0x1ebb, 0x1ebb, 0x1ebd, 0x1ebd, 0x1ebf, 0x1ebf, + 0x1ec1, 0x1ec1, 0x1ec3, 0x1ec3, 0x1ec5, 0x1ec5, 0x1ec7, 0x1ec7, + 0x1ec9, 0x1ec9, 0x1ecb, 0x1ecb, 0x1ecd, 0x1ecd, 0x1ecf, 0x1ecf, + 0x1ed1, 0x1ed1, 0x1ed3, 0x1ed3, 0x1ed5, 0x1ed5, 0x1ed7, 0x1ed7, + 0x1ed9, 0x1ed9, 0x1edb, 0x1edb, 0x1edd, 0x1edd, 0x1edf, 0x1edf, + 0x1ee1, 0x1ee1, 0x1ee3, 0x1ee3, 0x1ee5, 0x1ee5, 0x1ee7, 0x1ee7, + 0x1ee9, 0x1ee9, 0x1eeb, 0x1eeb, 0x1eed, 0x1eed, 0x1eef, 0x1eef, + 0x1ef1, 0x1ef1, 0x1ef3, 0x1ef3, 0x1ef5, 0x1ef5, 0x1ef7, 0x1ef7, + 0x1ef9, 0x1ef9, 0x1efa, 0x1efb, 0x1efc, 0x1efd, 0x1efe, 0x1eff, + + /* Characters U+1F00 to U+1FFF */ + + 0x1f00, 0x1f01, 0x1f02, 0x1f03, 0x1f04, 0x1f05, 0x1f06, 0x1f07, + 0x1f00, 0x1f01, 0x1f02, 0x1f03, 0x1f04, 0x1f05, 0x1f06, 0x1f07, + 0x1f10, 0x1f11, 0x1f12, 0x1f13, 0x1f14, 0x1f15, 0x1f16, 0x1f17, + 0x1f10, 0x1f11, 0x1f12, 0x1f13, 0x1f14, 0x1f15, 0x1f1e, 0x1f1f, + 0x1f20, 0x1f21, 0x1f22, 0x1f23, 0x1f24, 0x1f25, 0x1f26, 0x1f27, + 0x1f20, 0x1f21, 0x1f22, 0x1f23, 0x1f24, 0x1f25, 0x1f26, 0x1f27, + 0x1f30, 0x1f31, 0x1f32, 0x1f33, 0x1f34, 0x1f35, 0x1f36, 0x1f37, + 0x1f30, 0x1f31, 0x1f32, 0x1f33, 0x1f34, 0x1f35, 0x1f36, 0x1f37, + 0x1f40, 0x1f41, 0x1f42, 0x1f43, 0x1f44, 0x1f45, 0x1f46, 0x1f47, + 0x1f40, 0x1f41, 0x1f42, 0x1f43, 0x1f44, 0x1f45, 0x1f4e, 0x1f4f, + 0xe00a, 0x1f51, 0xe402, 0x1f53, 0xe403, 0x1f55, 0xe404, 0x1f57, + 0x1f58, 0x1f51, 0x1f5a, 0x1f53, 0x1f5c, 0x1f55, 0x1f5e, 0x1f57, + 0x1f60, 0x1f61, 0x1f62, 0x1f63, 0x1f64, 0x1f65, 0x1f66, 0x1f67, + 0x1f60, 0x1f61, 0x1f62, 0x1f63, 0x1f64, 0x1f65, 0x1f66, 0x1f67, + 0x1f70, 0x1f71, 0x1f72, 0x1f73, 0x1f74, 0x1f75, 0x1f76, 0x1f77, + 0x1f78, 0x1f79, 0x1f7a, 0x1f7b, 0x1f7c, 0x1f7d, 0x1f7e, 0x1f7f, + 0xe00b, 0xe00c, 0xe00d, 0xe00e, 0xe00f, 0xe010, 0xe011, 0xe012, + 0xe013, 0xe014, 0xe015, 0xe016, 0xe017, 0xe018, 0xe019, 0xe01a, + 0xe01b, 0xe01c, 0xe01d, 0xe01e, 0xe01f, 0xe020, 0xe021, 0xe022, + 0xe023, 0xe024, 0xe025, 0xe026, 0xe027, 0xe028, 0xe029, 0xe02a, + 0xe02b, 0xe02c, 0xe02d, 0xe02e, 0xe02f, 0xe030, 0xe031, 0xe032, + 0xe033, 0xe034, 0xe035, 0xe036, 0xe037, 0xe038, 0xe039, 0xe03a, + 0x1fb0, 0x1fb1, 0xe03b, 0xe03c, 0xe03d, 0x1fb5, 0xe03e, 0xe405, + 0x1fb0, 0x1fb1, 0x1f70, 0x1f71, 0xe03f, 0x1fbd, 0x03b9, 0x1fbf, + 0x1fc0, 0x1fc1, 0xe040, 0xe041, 0xe042, 0x1fc5, 0xe043, 0xe406, + 0x1f72, 0x1f73, 0x1f74, 0x1f75, 0xe044, 0x1fcd, 0x1fce, 0x1fcf, + 0x1fd0, 0x1fd1, 0xe407, 0xe408, 0x1fd4, 0x1fd5, 0xe045, 0xe409, + 0x1fd0, 0x1fd1, 0x1f76, 0x1f77, 0x1fdc, 0x1fdd, 0x1fde, 0x1fdf, + 0x1fe0, 0x1fe1, 0xe40a, 0xe40b, 0xe046, 0x1fe5, 0xe047, 0xe40c, + 0x1fe0, 0x1fe1, 0x1f7a, 0x1f7b, 0x1fe5, 0x1fed, 0x1fee, 0x1fef, + 0x1ff0, 0x1ff1, 0xe048, 0xe049, 0xe04a, 0x1ff5, 0xe04b, 0xe40d, + 0x1f78, 0x1f79, 0x1f7c, 0x1f7d, 0xe04c, 0x1ffd, 0x1ffe, 0x1fff, + + /* Characters U+2100 to U+21FF */ + + 0x2100, 0x2101, 0x2102, 0x2103, 0x2104, 0x2105, 0x2106, 0x2107, + 0x2108, 0x2109, 0x210a, 0x210b, 0x210c, 0x210d, 0x210e, 0x210f, + 0x2110, 0x2111, 0x2112, 0x2113, 0x2114, 0x2115, 0x2116, 0x2117, + 0x2118, 0x2119, 0x211a, 0x211b, 0x211c, 0x211d, 0x211e, 0x211f, + 0x2120, 0x2121, 0x2122, 0x2123, 0x2124, 0x2125, 0x03c9, 0x2127, + 0x2128, 0x2129, 0x006b, 0x00e5, 0x212c, 0x212d, 0x212e, 0x212f, + 0x2130, 0x2131, 0x214e, 0x2133, 0x2134, 0x2135, 0x2136, 0x2137, + 0x2138, 0x2139, 0x213a, 0x213b, 0x213c, 0x213d, 0x213e, 0x213f, + 0x2140, 0x2141, 0x2142, 0x2143, 0x2144, 0x2145, 0x2146, 0x2147, + 0x2148, 0x2149, 0x214a, 0x214b, 0x214c, 0x214d, 0x214e, 0x214f, + 0x2150, 0x2151, 0x2152, 0x2153, 0x2154, 0x2155, 0x2156, 0x2157, + 0x2158, 0x2159, 0x215a, 0x215b, 0x215c, 0x215d, 0x215e, 0x215f, + 0x2170, 0x2171, 0x2172, 0x2173, 0x2174, 0x2175, 0x2176, 0x2177, + 0x2178, 0x2179, 0x217a, 0x217b, 0x217c, 0x217d, 0x217e, 0x217f, + 0x2170, 0x2171, 0x2172, 0x2173, 0x2174, 0x2175, 0x2176, 0x2177, + 0x2178, 0x2179, 0x217a, 0x217b, 0x217c, 0x217d, 0x217e, 0x217f, + 0x2180, 0x2181, 0x2182, 0x2184, 0x2184, 0x2185, 0x2186, 0x2187, + 0x2188, 0x2189, 0x218a, 0x218b, 0x218c, 0x218d, 0x218e, 0x218f, + 0x2190, 0x2191, 0x2192, 0x2193, 0x2194, 0x2195, 0x2196, 0x2197, + 0x2198, 0x2199, 0x219a, 0x219b, 0x219c, 0x219d, 0x219e, 0x219f, + 0x21a0, 0x21a1, 0x21a2, 0x21a3, 0x21a4, 0x21a5, 0x21a6, 0x21a7, + 0x21a8, 0x21a9, 0x21aa, 0x21ab, 0x21ac, 0x21ad, 0x21ae, 0x21af, + 0x21b0, 0x21b1, 0x21b2, 0x21b3, 0x21b4, 0x21b5, 0x21b6, 0x21b7, + 0x21b8, 0x21b9, 0x21ba, 0x21bb, 0x21bc, 0x21bd, 0x21be, 0x21bf, + 0x21c0, 0x21c1, 0x21c2, 0x21c3, 0x21c4, 0x21c5, 0x21c6, 0x21c7, + 0x21c8, 0x21c9, 0x21ca, 0x21cb, 0x21cc, 0x21cd, 0x21ce, 0x21cf, + 0x21d0, 0x21d1, 0x21d2, 0x21d3, 0x21d4, 0x21d5, 0x21d6, 0x21d7, + 0x21d8, 0x21d9, 0x21da, 0x21db, 0x21dc, 0x21dd, 0x21de, 0x21df, + 0x21e0, 0x21e1, 0x21e2, 0x21e3, 0x21e4, 0x21e5, 0x21e6, 0x21e7, + 0x21e8, 0x21e9, 0x21ea, 0x21eb, 0x21ec, 0x21ed, 0x21ee, 0x21ef, + 0x21f0, 0x21f1, 0x21f2, 0x21f3, 0x21f4, 0x21f5, 0x21f6, 0x21f7, + 0x21f8, 0x21f9, 0x21fa, 0x21fb, 0x21fc, 0x21fd, 0x21fe, 0x21ff, + + /* Characters U+2400 to U+24FF */ + + 0x2400, 0x2401, 0x2402, 0x2403, 0x2404, 0x2405, 0x2406, 0x2407, + 0x2408, 0x2409, 0x240a, 0x240b, 0x240c, 0x240d, 0x240e, 0x240f, + 0x2410, 0x2411, 0x2412, 0x2413, 0x2414, 0x2415, 0x2416, 0x2417, + 0x2418, 0x2419, 0x241a, 0x241b, 0x241c, 0x241d, 0x241e, 0x241f, + 0x2420, 0x2421, 0x2422, 0x2423, 0x2424, 0x2425, 0x2426, 0x2427, + 0x2428, 0x2429, 0x242a, 0x242b, 0x242c, 0x242d, 0x242e, 0x242f, + 0x2430, 0x2431, 0x2432, 0x2433, 0x2434, 0x2435, 0x2436, 0x2437, + 0x2438, 0x2439, 0x243a, 0x243b, 0x243c, 0x243d, 0x243e, 0x243f, + 0x2440, 0x2441, 0x2442, 0x2443, 0x2444, 0x2445, 0x2446, 0x2447, + 0x2448, 0x2449, 0x244a, 0x244b, 0x244c, 0x244d, 0x244e, 0x244f, + 0x2450, 0x2451, 0x2452, 0x2453, 0x2454, 0x2455, 0x2456, 0x2457, + 0x2458, 0x2459, 0x245a, 0x245b, 0x245c, 0x245d, 0x245e, 0x245f, + 0x2460, 0x2461, 0x2462, 0x2463, 0x2464, 0x2465, 0x2466, 0x2467, + 0x2468, 0x2469, 0x246a, 0x246b, 0x246c, 0x246d, 0x246e, 0x246f, + 0x2470, 0x2471, 0x2472, 0x2473, 0x2474, 0x2475, 0x2476, 0x2477, + 0x2478, 0x2479, 0x247a, 0x247b, 0x247c, 0x247d, 0x247e, 0x247f, + 0x2480, 0x2481, 0x2482, 0x2483, 0x2484, 0x2485, 0x2486, 0x2487, + 0x2488, 0x2489, 0x248a, 0x248b, 0x248c, 0x248d, 0x248e, 0x248f, + 0x2490, 0x2491, 0x2492, 0x2493, 0x2494, 0x2495, 0x2496, 0x2497, + 0x2498, 0x2499, 0x249a, 0x249b, 0x249c, 0x249d, 0x249e, 0x249f, + 0x24a0, 0x24a1, 0x24a2, 0x24a3, 0x24a4, 0x24a5, 0x24a6, 0x24a7, + 0x24a8, 0x24a9, 0x24aa, 0x24ab, 0x24ac, 0x24ad, 0x24ae, 0x24af, + 0x24b0, 0x24b1, 0x24b2, 0x24b3, 0x24b4, 0x24b5, 0x24d0, 0x24d1, + 0x24d2, 0x24d3, 0x24d4, 0x24d5, 0x24d6, 0x24d7, 0x24d8, 0x24d9, + 0x24da, 0x24db, 0x24dc, 0x24dd, 0x24de, 0x24df, 0x24e0, 0x24e1, + 0x24e2, 0x24e3, 0x24e4, 0x24e5, 0x24e6, 0x24e7, 0x24e8, 0x24e9, + 0x24d0, 0x24d1, 0x24d2, 0x24d3, 0x24d4, 0x24d5, 0x24d6, 0x24d7, + 0x24d8, 0x24d9, 0x24da, 0x24db, 0x24dc, 0x24dd, 0x24de, 0x24df, + 0x24e0, 0x24e1, 0x24e2, 0x24e3, 0x24e4, 0x24e5, 0x24e6, 0x24e7, + 0x24e8, 0x24e9, 0x24ea, 0x24eb, 0x24ec, 0x24ed, 0x24ee, 0x24ef, + 0x24f0, 0x24f1, 0x24f2, 0x24f3, 0x24f4, 0x24f5, 0x24f6, 0x24f7, + 0x24f8, 0x24f9, 0x24fa, 0x24fb, 0x24fc, 0x24fd, 0x24fe, 0x24ff, + + /* Characters U+2C00 to U+2CFF */ + + 0x2c30, 0x2c31, 0x2c32, 0x2c33, 0x2c34, 0x2c35, 0x2c36, 0x2c37, + 0x2c38, 0x2c39, 0x2c3a, 0x2c3b, 0x2c3c, 0x2c3d, 0x2c3e, 0x2c3f, + 0x2c40, 0x2c41, 0x2c42, 0x2c43, 0x2c44, 0x2c45, 0x2c46, 0x2c47, + 0x2c48, 0x2c49, 0x2c4a, 0x2c4b, 0x2c4c, 0x2c4d, 0x2c4e, 0x2c4f, + 0x2c50, 0x2c51, 0x2c52, 0x2c53, 0x2c54, 0x2c55, 0x2c56, 0x2c57, + 0x2c58, 0x2c59, 0x2c5a, 0x2c5b, 0x2c5c, 0x2c5d, 0x2c5e, 0x2c2f, + 0x2c30, 0x2c31, 0x2c32, 0x2c33, 0x2c34, 0x2c35, 0x2c36, 0x2c37, + 0x2c38, 0x2c39, 0x2c3a, 0x2c3b, 0x2c3c, 0x2c3d, 0x2c3e, 0x2c3f, + 0x2c40, 0x2c41, 0x2c42, 0x2c43, 0x2c44, 0x2c45, 0x2c46, 0x2c47, + 0x2c48, 0x2c49, 0x2c4a, 0x2c4b, 0x2c4c, 0x2c4d, 0x2c4e, 0x2c4f, + 0x2c50, 0x2c51, 0x2c52, 0x2c53, 0x2c54, 0x2c55, 0x2c56, 0x2c57, + 0x2c58, 0x2c59, 0x2c5a, 0x2c5b, 0x2c5c, 0x2c5d, 0x2c5e, 0x2c5f, + 0x2c61, 0x2c61, 0x026b, 0x1d7d, 0x027d, 0x2c65, 0x2c66, 0x2c68, + 0x2c68, 0x2c6a, 0x2c6a, 0x2c6c, 0x2c6c, 0x2c6d, 0x2c6e, 0x2c6f, + 0x2c70, 0x2c71, 0x2c72, 0x2c73, 0x2c74, 0x2c76, 0x2c76, 0x2c77, + 0x2c78, 0x2c79, 0x2c7a, 0x2c7b, 0x2c7c, 0x2c7d, 0x2c7e, 0x2c7f, + 0x2c81, 0x2c81, 0x2c83, 0x2c83, 0x2c85, 0x2c85, 0x2c87, 0x2c87, + 0x2c89, 0x2c89, 0x2c8b, 0x2c8b, 0x2c8d, 0x2c8d, 0x2c8f, 0x2c8f, + 0x2c91, 0x2c91, 0x2c93, 0x2c93, 0x2c95, 0x2c95, 0x2c97, 0x2c97, + 0x2c99, 0x2c99, 0x2c9b, 0x2c9b, 0x2c9d, 0x2c9d, 0x2c9f, 0x2c9f, + 0x2ca1, 0x2ca1, 0x2ca3, 0x2ca3, 0x2ca5, 0x2ca5, 0x2ca7, 0x2ca7, + 0x2ca9, 0x2ca9, 0x2cab, 0x2cab, 0x2cad, 0x2cad, 0x2caf, 0x2caf, + 0x2cb1, 0x2cb1, 0x2cb3, 0x2cb3, 0x2cb5, 0x2cb5, 0x2cb7, 0x2cb7, + 0x2cb9, 0x2cb9, 0x2cbb, 0x2cbb, 0x2cbd, 0x2cbd, 0x2cbf, 0x2cbf, + 0x2cc1, 0x2cc1, 0x2cc3, 0x2cc3, 0x2cc5, 0x2cc5, 0x2cc7, 0x2cc7, + 0x2cc9, 0x2cc9, 0x2ccb, 0x2ccb, 0x2ccd, 0x2ccd, 0x2ccf, 0x2ccf, + 0x2cd1, 0x2cd1, 0x2cd3, 0x2cd3, 0x2cd5, 0x2cd5, 0x2cd7, 0x2cd7, + 0x2cd9, 0x2cd9, 0x2cdb, 0x2cdb, 0x2cdd, 0x2cdd, 0x2cdf, 0x2cdf, + 0x2ce1, 0x2ce1, 0x2ce3, 0x2ce3, 0x2ce4, 0x2ce5, 0x2ce6, 0x2ce7, + 0x2ce8, 0x2ce9, 0x2cea, 0x2ceb, 0x2cec, 0x2ced, 0x2cee, 0x2cef, + 0x2cf0, 0x2cf1, 0x2cf2, 0x2cf3, 0x2cf4, 0x2cf5, 0x2cf6, 0x2cf7, + 0x2cf8, 0x2cf9, 0x2cfa, 0x2cfb, 0x2cfc, 0x2cfd, 0x2cfe, 0x2cff, + + /* Characters U+FB00 to U+FBFF */ + + 0xe04d, 0xe04e, 0xe04f, 0xe40e, 0xe40f, 0xe050, 0xe051, 0xfb07, + 0xfb08, 0xfb09, 0xfb0a, 0xfb0b, 0xfb0c, 0xfb0d, 0xfb0e, 0xfb0f, + 0xfb10, 0xfb11, 0xfb12, 0xe052, 0xe053, 0xe054, 0xe055, 0xe056, + 0xfb18, 0xfb19, 0xfb1a, 0xfb1b, 0xfb1c, 0xfb1d, 0xfb1e, 0xfb1f, + 0xfb20, 0xfb21, 0xfb22, 0xfb23, 0xfb24, 0xfb25, 0xfb26, 0xfb27, + 0xfb28, 0xfb29, 0xfb2a, 0xfb2b, 0xfb2c, 0xfb2d, 0xfb2e, 0xfb2f, + 0xfb30, 0xfb31, 0xfb32, 0xfb33, 0xfb34, 0xfb35, 0xfb36, 0xfb37, + 0xfb38, 0xfb39, 0xfb3a, 0xfb3b, 0xfb3c, 0xfb3d, 0xfb3e, 0xfb3f, + 0xfb40, 0xfb41, 0xfb42, 0xfb43, 0xfb44, 0xfb45, 0xfb46, 0xfb47, + 0xfb48, 0xfb49, 0xfb4a, 0xfb4b, 0xfb4c, 0xfb4d, 0xfb4e, 0xfb4f, + 0xfb50, 0xfb51, 0xfb52, 0xfb53, 0xfb54, 0xfb55, 0xfb56, 0xfb57, + 0xfb58, 0xfb59, 0xfb5a, 0xfb5b, 0xfb5c, 0xfb5d, 0xfb5e, 0xfb5f, + 0xfb60, 0xfb61, 0xfb62, 0xfb63, 0xfb64, 0xfb65, 0xfb66, 0xfb67, + 0xfb68, 0xfb69, 0xfb6a, 0xfb6b, 0xfb6c, 0xfb6d, 0xfb6e, 0xfb6f, + 0xfb70, 0xfb71, 0xfb72, 0xfb73, 0xfb74, 0xfb75, 0xfb76, 0xfb77, + 0xfb78, 0xfb79, 0xfb7a, 0xfb7b, 0xfb7c, 0xfb7d, 0xfb7e, 0xfb7f, + 0xfb80, 0xfb81, 0xfb82, 0xfb83, 0xfb84, 0xfb85, 0xfb86, 0xfb87, + 0xfb88, 0xfb89, 0xfb8a, 0xfb8b, 0xfb8c, 0xfb8d, 0xfb8e, 0xfb8f, + 0xfb90, 0xfb91, 0xfb92, 0xfb93, 0xfb94, 0xfb95, 0xfb96, 0xfb97, + 0xfb98, 0xfb99, 0xfb9a, 0xfb9b, 0xfb9c, 0xfb9d, 0xfb9e, 0xfb9f, + 0xfba0, 0xfba1, 0xfba2, 0xfba3, 0xfba4, 0xfba5, 0xfba6, 0xfba7, + 0xfba8, 0xfba9, 0xfbaa, 0xfbab, 0xfbac, 0xfbad, 0xfbae, 0xfbaf, + 0xfbb0, 0xfbb1, 0xfbb2, 0xfbb3, 0xfbb4, 0xfbb5, 0xfbb6, 0xfbb7, + 0xfbb8, 0xfbb9, 0xfbba, 0xfbbb, 0xfbbc, 0xfbbd, 0xfbbe, 0xfbbf, + 0xfbc0, 0xfbc1, 0xfbc2, 0xfbc3, 0xfbc4, 0xfbc5, 0xfbc6, 0xfbc7, + 0xfbc8, 0xfbc9, 0xfbca, 0xfbcb, 0xfbcc, 0xfbcd, 0xfbce, 0xfbcf, + 0xfbd0, 0xfbd1, 0xfbd2, 0xfbd3, 0xfbd4, 0xfbd5, 0xfbd6, 0xfbd7, + 0xfbd8, 0xfbd9, 0xfbda, 0xfbdb, 0xfbdc, 0xfbdd, 0xfbde, 0xfbdf, + 0xfbe0, 0xfbe1, 0xfbe2, 0xfbe3, 0xfbe4, 0xfbe5, 0xfbe6, 0xfbe7, + 0xfbe8, 0xfbe9, 0xfbea, 0xfbeb, 0xfbec, 0xfbed, 0xfbee, 0xfbef, + 0xfbf0, 0xfbf1, 0xfbf2, 0xfbf3, 0xfbf4, 0xfbf5, 0xfbf6, 0xfbf7, + 0xfbf8, 0xfbf9, 0xfbfa, 0xfbfb, 0xfbfc, 0xfbfd, 0xfbfe, 0xfbff, + + /* Characters U+FF00 to U+FFFF */ + + 0xff00, 0xff01, 0xff02, 0xff03, 0xff04, 0xff05, 0xff06, 0xff07, + 0xff08, 0xff09, 0xff0a, 0xff0b, 0xff0c, 0xff0d, 0xff0e, 0xff0f, + 0xff10, 0xff11, 0xff12, 0xff13, 0xff14, 0xff15, 0xff16, 0xff17, + 0xff18, 0xff19, 0xff1a, 0xff1b, 0xff1c, 0xff1d, 0xff1e, 0xff1f, + 0xff20, 0xff41, 0xff42, 0xff43, 0xff44, 0xff45, 0xff46, 0xff47, + 0xff48, 0xff49, 0xff4a, 0xff4b, 0xff4c, 0xff4d, 0xff4e, 0xff4f, + 0xff50, 0xff51, 0xff52, 0xff53, 0xff54, 0xff55, 0xff56, 0xff57, + 0xff58, 0xff59, 0xff5a, 0xff3b, 0xff3c, 0xff3d, 0xff3e, 0xff3f, + 0xff40, 0xff41, 0xff42, 0xff43, 0xff44, 0xff45, 0xff46, 0xff47, + 0xff48, 0xff49, 0xff4a, 0xff4b, 0xff4c, 0xff4d, 0xff4e, 0xff4f, + 0xff50, 0xff51, 0xff52, 0xff53, 0xff54, 0xff55, 0xff56, 0xff57, + 0xff58, 0xff59, 0xff5a, 0xff5b, 0xff5c, 0xff5d, 0xff5e, 0xff5f, + 0xff60, 0xff61, 0xff62, 0xff63, 0xff64, 0xff65, 0xff66, 0xff67, + 0xff68, 0xff69, 0xff6a, 0xff6b, 0xff6c, 0xff6d, 0xff6e, 0xff6f, + 0xff70, 0xff71, 0xff72, 0xff73, 0xff74, 0xff75, 0xff76, 0xff77, + 0xff78, 0xff79, 0xff7a, 0xff7b, 0xff7c, 0xff7d, 0xff7e, 0xff7f, + 0xff80, 0xff81, 0xff82, 0xff83, 0xff84, 0xff85, 0xff86, 0xff87, + 0xff88, 0xff89, 0xff8a, 0xff8b, 0xff8c, 0xff8d, 0xff8e, 0xff8f, + 0xff90, 0xff91, 0xff92, 0xff93, 0xff94, 0xff95, 0xff96, 0xff97, + 0xff98, 0xff99, 0xff9a, 0xff9b, 0xff9c, 0xff9d, 0xff9e, 0xff9f, + 0xffa0, 0xffa1, 0xffa2, 0xffa3, 0xffa4, 0xffa5, 0xffa6, 0xffa7, + 0xffa8, 0xffa9, 0xffaa, 0xffab, 0xffac, 0xffad, 0xffae, 0xffaf, + 0xffb0, 0xffb1, 0xffb2, 0xffb3, 0xffb4, 0xffb5, 0xffb6, 0xffb7, + 0xffb8, 0xffb9, 0xffba, 0xffbb, 0xffbc, 0xffbd, 0xffbe, 0xffbf, + 0xffc0, 0xffc1, 0xffc2, 0xffc3, 0xffc4, 0xffc5, 0xffc6, 0xffc7, + 0xffc8, 0xffc9, 0xffca, 0xffcb, 0xffcc, 0xffcd, 0xffce, 0xffcf, + 0xffd0, 0xffd1, 0xffd2, 0xffd3, 0xffd4, 0xffd5, 0xffd6, 0xffd7, + 0xffd8, 0xffd9, 0xffda, 0xffdb, 0xffdc, 0xffdd, 0xffde, 0xffdf, + 0xffe0, 0xffe1, 0xffe2, 0xffe3, 0xffe4, 0xffe5, 0xffe6, 0xffe7, + 0xffe8, 0xffe9, 0xffea, 0xffeb, 0xffec, 0xffed, 0xffee, 0xffef, + 0xfff0, 0xfff1, 0xfff2, 0xfff3, 0xfff4, 0xfff5, 0xfff6, 0xfff7, + 0xfff8, 0xfff9, 0xfffa, 0xfffb, 0xfffc, 0xfffd, 0xfffe, 0xffff, +}; + +__uint16_t xfs_case_fold_double_table[87][2] = { + /* U+00DF */ {0x0073, 0x0073}, /* U+0130 */ {0x0069, 0x0307}, + /* U+0149 */ {0x02bc, 0x006e}, /* U+01F0 */ {0x006a, 0x030c}, + /* U+0587 */ {0x0565, 0x0582}, /* U+1E96 */ {0x0068, 0x0331}, + /* U+1E97 */ {0x0074, 0x0308}, /* U+1E98 */ {0x0077, 0x030a}, + /* U+1E99 */ {0x0079, 0x030a}, /* U+1E9A */ {0x0061, 0x02be}, + /* U+1F50 */ {0x03c5, 0x0313}, /* U+1F80 */ {0x1f00, 0x03b9}, + /* U+1F81 */ {0x1f01, 0x03b9}, /* U+1F82 */ {0x1f02, 0x03b9}, + /* U+1F83 */ {0x1f03, 0x03b9}, /* U+1F84 */ {0x1f04, 0x03b9}, + /* U+1F85 */ {0x1f05, 0x03b9}, /* U+1F86 */ {0x1f06, 0x03b9}, + /* U+1F87 */ {0x1f07, 0x03b9}, /* U+1F88 */ {0x1f00, 0x03b9}, + /* U+1F89 */ {0x1f01, 0x03b9}, /* U+1F8A */ {0x1f02, 0x03b9}, + /* U+1F8B */ {0x1f03, 0x03b9}, /* U+1F8C */ {0x1f04, 0x03b9}, + /* U+1F8D */ {0x1f05, 0x03b9}, /* U+1F8E */ {0x1f06, 0x03b9}, + /* U+1F8F */ {0x1f07, 0x03b9}, /* U+1F90 */ {0x1f20, 0x03b9}, + /* U+1F91 */ {0x1f21, 0x03b9}, /* U+1F92 */ {0x1f22, 0x03b9}, + /* U+1F93 */ {0x1f23, 0x03b9}, /* U+1F94 */ {0x1f24, 0x03b9}, + /* U+1F95 */ {0x1f25, 0x03b9}, /* U+1F96 */ {0x1f26, 0x03b9}, + /* U+1F97 */ {0x1f27, 0x03b9}, /* U+1F98 */ {0x1f20, 0x03b9}, + /* U+1F99 */ {0x1f21, 0x03b9}, /* U+1F9A */ {0x1f22, 0x03b9}, + /* U+1F9B */ {0x1f23, 0x03b9}, /* U+1F9C */ {0x1f24, 0x03b9}, + /* U+1F9D */ {0x1f25, 0x03b9}, /* U+1F9E */ {0x1f26, 0x03b9}, + /* U+1F9F */ {0x1f27, 0x03b9}, /* U+1FA0 */ {0x1f60, 0x03b9}, + /* U+1FA1 */ {0x1f61, 0x03b9}, /* U+1FA2 */ {0x1f62, 0x03b9}, + /* U+1FA3 */ {0x1f63, 0x03b9}, /* U+1FA4 */ {0x1f64, 0x03b9}, + /* U+1FA5 */ {0x1f65, 0x03b9}, /* U+1FA6 */ {0x1f66, 0x03b9}, + /* U+1FA7 */ {0x1f67, 0x03b9}, /* U+1FA8 */ {0x1f60, 0x03b9}, + /* U+1FA9 */ {0x1f61, 0x03b9}, /* U+1FAA */ {0x1f62, 0x03b9}, + /* U+1FAB */ {0x1f63, 0x03b9}, /* U+1FAC */ {0x1f64, 0x03b9}, + /* U+1FAD */ {0x1f65, 0x03b9}, /* U+1FAE */ {0x1f66, 0x03b9}, + /* U+1FAF */ {0x1f67, 0x03b9}, /* U+1FB2 */ {0x1f70, 0x03b9}, + /* U+1FB3 */ {0x03b1, 0x03b9}, /* U+1FB4 */ {0x03ac, 0x03b9}, + /* U+1FB6 */ {0x03b1, 0x0342}, /* U+1FBC */ {0x03b1, 0x03b9}, + /* U+1FC2 */ {0x1f74, 0x03b9}, /* U+1FC3 */ {0x03b7, 0x03b9}, + /* U+1FC4 */ {0x03ae, 0x03b9}, /* U+1FC6 */ {0x03b7, 0x0342}, + /* U+1FCC */ {0x03b7, 0x03b9}, /* U+1FD6 */ {0x03b9, 0x0342}, + /* U+1FE4 */ {0x03c1, 0x0313}, /* U+1FE6 */ {0x03c5, 0x0342}, + /* U+1FF2 */ {0x1f7c, 0x03b9}, /* U+1FF3 */ {0x03c9, 0x03b9}, + /* U+1FF4 */ {0x03ce, 0x03b9}, /* U+1FF6 */ {0x03c9, 0x0342}, + /* U+1FFC */ {0x03c9, 0x03b9}, /* U+FB00 */ {0x0066, 0x0066}, + /* U+FB01 */ {0x0066, 0x0069}, /* U+FB02 */ {0x0066, 0x006c}, + /* U+FB05 */ {0x0073, 0x0074}, /* U+FB06 */ {0x0073, 0x0074}, + /* U+FB13 */ {0x0574, 0x0576}, /* U+FB14 */ {0x0574, 0x0565}, + /* U+FB15 */ {0x0574, 0x056b}, /* U+FB16 */ {0x057e, 0x0576}, + /* U+FB17 */ {0x0574, 0x056d}, +}; + +__uint16_t xfs_case_fold_triple_table[16][3] = { + /* U+0390 */ {0x03b9, 0x0308, 0x0301}, + /* U+03B0 */ {0x03c5, 0x0308, 0x0301}, + /* U+1F52 */ {0x03c5, 0x0313, 0x0300}, + /* U+1F54 */ {0x03c5, 0x0313, 0x0301}, + /* U+1F56 */ {0x03c5, 0x0313, 0x0342}, + /* U+1FB7 */ {0x03b1, 0x0342, 0x03b9}, + /* U+1FC7 */ {0x03b7, 0x0342, 0x03b9}, + /* U+1FD2 */ {0x03b9, 0x0308, 0x0300}, + /* U+1FD3 */ {0x03b9, 0x0308, 0x0301}, + /* U+1FD7 */ {0x03b9, 0x0308, 0x0342}, + /* U+1FE2 */ {0x03c5, 0x0308, 0x0300}, + /* U+1FE3 */ {0x03c5, 0x0308, 0x0301}, + /* U+1FE7 */ {0x03c5, 0x0308, 0x0342}, + /* U+1FF7 */ {0x03c9, 0x0342, 0x03b9}, + /* U+FB03 */ {0x0066, 0x0066, 0x0069}, + /* U+FB04 */ {0x0066, 0x0066, 0x006c}, +}; + +__uint16_t xfs_case_fold_turkic_adjust[2][2] = { + {0x0049, 0x0131}, {0x0130, 0x0069}, +}; =========================================================================== xfsprogs/mkfs/proto.c =========================================================================== --- a/xfsprogs/mkfs/proto.c 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/mkfs/proto.c 2007-10-23 17:11:02.878088068 +1000 @@ -32,6 +32,7 @@ static int newfile(xfs_trans_t *tp, xfs_ xfs_fsblock_t *first, int dolocal, int logit, char *buf, int len); static char *newregfile(char **pp, int *len); static void rtinit(xfs_mount_t *mp); +static void cftinit(xfs_mount_t *mp); static long filesize(int fd); /* @@ -570,11 +571,13 @@ parseproto( libxfs_trans_ihold(tp, ip); libxfs_trans_commit(tp, 0, NULL); /* - * RT initialization. Do this here to ensure that - * the RT inodes get placed after the root inode. + * RT & CFT initialization. Do this here to ensure that + * the RT & CFT inodes get placed after the root inode. */ - if (isroot) + if (isroot) { rtinit(mp); + cftinit(mp); + } tp = NULL; for (;;) { name = getstr(pp); @@ -762,6 +765,155 @@ rtinit( } } +/* + * Allocate unicode case folding table + */ + +#define NUM_CFT 3 + +extern __uint16_t xfs_case_fold_table[15 * 256]; +extern __uint16_t xfs_case_fold_double_table[87][2]; +extern __uint16_t xfs_case_fold_triple_table[16][3]; +extern __uint16_t xfs_case_fold_turkic_adjust[2][2]; + +#ifndef ARRAY_SIZE +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) +#endif + +static void +cftinit( + xfs_mount_t *mp) +{ + int i; + xfs_dcft_t *table; + int table_size; + __be16 *cfc; + xfs_trans_t *tp; + xfs_inode_t *cftip; + struct cred creds; + struct fsxattr fsxattrs; + xfs_dfiloff_t bno; + int committed; + xfs_bmbt_irec_t *ep; + int error; + xfs_fsblock_t first; + xfs_bmap_free_t flist; + xfs_bmbt_irec_t map[XFS_BMAP_MAX_NMAP]; + xfs_extlen_t nblocks; + int nmap; + char *p; + xfs_buf_t *bp; + + if (!xfs_sb_version_hasunicode(&mp->m_sb)) + return; + + /* + * setup on-disk table in a memory buffer + */ + table_size = sizeof(xfs_dcft_t) + sizeof(__be32) * (NUM_CFT - 1) + + sizeof(xfs_case_fold_table) + + sizeof(xfs_case_fold_double_table) + + sizeof(xfs_case_fold_triple_table); + nblocks = XFS_B_TO_FSB(mp, table_size); + table = calloc(1, XFS_FSB_TO_B(mp, nblocks)); + table->magic = cpu_to_be32(XFS_CFT_MAGIC); + table->flags = 0; + table->num_tables = cpu_to_be32(NUM_CFT); + table->table_offset[0] = cpu_to_be32(sizeof(xfs_dcft_t) + + sizeof(__be32) * (NUM_CFT - 1)); + table->table_offset[1] = cpu_to_be32(sizeof(xfs_dcft_t) + + sizeof(__be32) * (NUM_CFT - 1) + + sizeof(xfs_case_fold_table)); + table->table_offset[2] = cpu_to_be32(sizeof(xfs_dcft_t) + + sizeof(__be32) * (NUM_CFT - 1) + + sizeof(xfs_case_fold_table) + + sizeof(xfs_case_fold_double_table)); + /* if user wants turkic case folding, adjust table first */ + if (mp->m_flags & LIBXFS_MOUNT_FLAG_TURKIC_CASE) { + table->flags |= cpu_to_be32(XFS_CFT_FLAG_TURKIC); + for (i = 0; i < ARRAY_SIZE(xfs_case_fold_turkic_adjust); i++) { + __uint16_t tmp = xfs_case_fold_table[ + xfs_case_fold_turkic_adjust[i][0] >> 8]; + xfs_case_fold_table[tmp + + (xfs_case_fold_turkic_adjust[i][0] & 0xff)] = + xfs_case_fold_turkic_adjust[i][1]; + } + } + cfc = XFS_DCFT_PTR(table, 0); + for (i = 0; i < ARRAY_SIZE(xfs_case_fold_table); i++) + *cfc++ = cpu_to_be16(xfs_case_fold_table[i]); + ASSERT(cfc == XFS_DCFT_PTR(table, 1)); + for (i = 0; i < ARRAY_SIZE(xfs_case_fold_double_table); i++) { + *cfc++ = cpu_to_be16(xfs_case_fold_double_table[i][0]); + *cfc++ = cpu_to_be16(xfs_case_fold_double_table[i][1]); + } + ASSERT(cfc == XFS_DCFT_PTR(table, 2)); + for (i = 0; i < ARRAY_SIZE(xfs_case_fold_triple_table); i++) { + *cfc++ = cpu_to_be16(xfs_case_fold_triple_table[i][0]); + *cfc++ = cpu_to_be16(xfs_case_fold_triple_table[i][1]); + *cfc++ = cpu_to_be16(xfs_case_fold_triple_table[i][2]); + } + + /* + * allocate the inode + */ + tp = libxfs_trans_alloc(mp, 0); + i = libxfs_trans_reserve(tp, MKFS_BLOCKRES_INODE, 0, 0, 0, 0); + if (i) + res_failed(i); + bzero(&creds, sizeof(creds)); + bzero(&fsxattrs, sizeof(fsxattrs)); + error = libxfs_inode_alloc(&tp, NULL, S_IFREG, 1, 0, + &creds, &fsxattrs, &cftip); + if (error) + fail(_("Case folding table inode allocation failed"), error); + mp->m_sb.sb_cftino = cftip->i_ino; + cftip->i_d.di_size = table_size; + libxfs_trans_log_inode(tp, cftip, XFS_ILOG_CORE); + libxfs_mod_sb(tp, XFS_SB_CFTINO); + libxfs_trans_ihold(tp, cftip); + libxfs_trans_commit(tp, 0, NULL); + + /* + * write case table to inode + */ + tp = libxfs_trans_alloc(mp, 0); + i = libxfs_trans_reserve(tp, + nblocks + (XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) - 1), + 0, 0, 0, 0); + if (i) + res_failed(i); + libxfs_trans_ijoin(tp, cftip, 0); + bno = 0; + p = (char *)table; + XFS_BMAP_INIT(&flist, &first); + while (bno < nblocks) { + nmap = XFS_BMAP_MAX_NMAP; + error = libxfs_bmapi(tp, cftip, bno, + (xfs_extlen_t)(nblocks - bno), + XFS_BMAPI_WRITE, &first, nblocks, + map, &nmap, &flist); + if (error) + fail(_("Allocation of the case folding table failed"), + error); + for (i = 0, ep = map; i < nmap; i++, ep++) { + bp = libxfs_getbuf(mp->m_dev, + XFS_FSB_TO_DADDR(mp, ep->br_startblock), + XFS_FSB_TO_BB(mp, ep->br_blockcount)); + memcpy(XFS_BUF_PTR(bp), p, XFS_BUF_SIZE(bp)); + libxfs_writebuf(bp, 0); + bno += ep->br_blockcount; + p += XFS_BUF_SIZE(bp); + } + } + error = libxfs_bmap_finish(&tp, &flist, first, &committed); + if (error) { + fail(_("Completion of the case folding table failed"), error); + } + libxfs_trans_commit(tp, 0, NULL); + +} + static long filesize( int fd) =========================================================================== xfsprogs/mkfs/xfs_mkfs.c =========================================================================== --- a/xfsprogs/mkfs/xfs_mkfs.c 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/mkfs/xfs_mkfs.c 2007-10-23 17:02:19.709586674 +1000 @@ -130,6 +130,8 @@ char *nopts[] = { "size", #define N_VERSION 2 "version", +#define N_UTF8 3 + "utf8", NULL, }; @@ -647,6 +649,8 @@ main( xfs_alloc_rec_t *nrec; int nsflag; int nvflag; + int nci; + int nutf8; int Nflag; char *p; char *protofile; @@ -671,12 +675,19 @@ main( int xlv_dsunit; int xlv_dswidth; int lazy_sb_counters; + char *locale; + int isturkiclocale; + progname = basename(argv[0]); - setlocale(LC_ALL, ""); + locale = setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); textdomain(PACKAGE); + isturkiclocale = strncasecmp(locale, "az_", 3) == 0 || + strncasecmp(locale, "aze_", 4) == 0 || + strncasecmp(locale, "tr_", 3) == 0 || + strncasecmp(locale, "tur_", 4) == 0; attrversion = 0; blflag = bsflag = slflag = ssflag = lslflag = lssflag = 0; blocklog = blocksize = 0; @@ -688,7 +699,7 @@ main( loginternal = 1; logversion = 1; logagno = logblocks = rtblocks = rtextblocks = 0; - Nflag = nlflag = nsflag = nvflag = 0; + Nflag = nlflag = nsflag = nvflag = nci = nutf8 = 0; dirblocklog = dirblocksize = dirversion = 0; qflag = 0; imaxpct = inodelog = inopblock = isize = 0; @@ -1213,11 +1224,28 @@ main( reqval('n', nopts, N_VERSION); if (nvflag) respec('n', nopts, N_VERSION); - dirversion = atoi(value); - if (dirversion < 1 || dirversion > 2) - illegal(value, "n version"); + dirversion = XFS_DFL_DIR_VERSION; + if (!strcmp(value, "ci")) { + nci = 1; /* old-style CI mode */ + } else { + if (atoi(value) != dirversion) + illegal(value, + "n version"); + } nvflag = 1; break; + case N_UTF8: + if (value) { + if (!strcmp(value, "turkic")) + nutf8 = 2; + else + if (!strcmp(value, "default")) + nutf8 = 1; + else + illegal(value, "n utf8"); + } else + nutf8 = isturkiclocale ? 2 : 1; + break; default: unknown('n', value); } @@ -1390,32 +1418,25 @@ main( } if (!nvflag) - dirversion = (nsflag || nlflag) ? 2 : XFS_DFL_DIR_VERSION; - switch (dirversion) { - case 1: - if ((nsflag || nlflag) && dirblocklog != blocklog) { + dirversion = XFS_DFL_DIR_VERSION; + if (nsflag || nlflag) { + if (dirblocksize < blocksize || + dirblocksize > XFS_MAX_BLOCKSIZE) { fprintf(stderr, _("illegal directory block size %d\n"), dirblocksize); usage(); } - break; - case 2: - if (nsflag || nlflag) { - if (dirblocksize < blocksize || - dirblocksize > XFS_MAX_BLOCKSIZE) { - fprintf(stderr, - _("illegal directory block size %d\n"), - dirblocksize); - usage(); - } - } else { - if (blocksize < (1 << XFS_MIN_REC_DIRSIZE)) - dirblocklog = XFS_MIN_REC_DIRSIZE; - else - dirblocklog = blocklog; - dirblocksize = 1 << dirblocklog; - } - break; + } else { + if (blocksize < (1 << XFS_MIN_REC_DIRSIZE)) + dirblocklog = XFS_MIN_REC_DIRSIZE; + else + dirblocklog = blocklog; + dirblocksize = 1 << dirblocklog; + } + if (nci && nutf8) { + fprintf(stderr, + _("both -n version=ci and utf8= specified, use one or the other\n")); + usage(); } if (daflag && dasize) { @@ -1991,7 +2012,7 @@ an AG size that is one stripe unit small " =%-22s sectsz=%-5u attr=%u\n" "data =%-22s bsize=%-6u blocks=%llu, imaxpct=%u\n" " =%-22s sunit=%-6u swidth=%u blks, unwritten=%u\n" - "naming =version %-14u bsize=%-6u\n" + "naming =version %-14s bsize=%-6u utf8=%s\n" "log =%-22s bsize=%-6d blocks=%lld, version=%d\n" " =%-22s sectsz=%-5u sunit=%d blks, lazy-count=%d\n" "realtime =%-22s extsz=%-6d blocks=%lld, rtextents=%lld\n"), @@ -2000,7 +2021,8 @@ an AG size that is one stripe unit small "", blocksize, (long long)dblocks, imflag ? imaxpct : XFS_DFL_IMAXIMUM_PCT, "", dsunit, dswidth, extent_flagging, - dirversion, dirversion == 1 ? blocksize : dirblocksize, + nci ? "ci" : "2" /*dirversion*/, dirblocksize, + nutf8 == 0 ? "none" : nutf8 == 2 ? "turkic" : "default", logfile, 1 << blocklog, (long long)logblocks, logversion, "", lsectorsize, lsunit, lazy_sb_counters, rtfile, rtextblocks << blocklog, @@ -2045,8 +2067,7 @@ an AG size that is one stripe unit small sbp->sb_qflags = 0; sbp->sb_unit = dsunit; sbp->sb_width = dswidth; - if (dirversion == 2) - sbp->sb_dirblklog = dirblocklog - blocklog; + sbp->sb_dirblklog = dirblocklog - blocklog; if (logversion == 2) { /* This is stored in bytes */ lsunit = (lsunit == 0) ? 1 : XFS_FSB_TO_B(mp, lsunit); sbp->sb_logsunit = lsunit; @@ -2064,12 +2085,14 @@ an AG size that is one stripe unit small sbp->sb_logsectlog = 0; sbp->sb_logsectsize = 0; } - sbp->sb_features2 = XFS_SB_VERSION2_MKFS(lazy_sb_counters, attrversion == 2, 0); + sbp->sb_features2 = XFS_SB_VERSION2_MKFS(lazy_sb_counters, + attrversion == 2, 0, nutf8 != 0); sbp->sb_versionnum = XFS_SB_VERSION_MKFS( iaflag, dsunit != 0, extent_flagging, dirversion == 2, logversion == 2, attrversion == 1, (sectorsize != BBSIZE || lsectorsize != BBSIZE), - sbp->sb_features2 != 0); + nci != 0, sbp->sb_features2 != 0); + sbp->sb_cftino = NULLFSINO; if (force_overwrite) zero_old_xfs_structures(&xi, sbp); @@ -2131,6 +2154,8 @@ an AG size that is one stripe unit small progname); exit(1); } + if (nutf8 == 2) + mp->m_flags |= LIBXFS_MOUNT_FLAG_TURKIC_CASE; for (agno = 0; agno < agcount; agno++) { /* @@ -2543,7 +2568,7 @@ usage( void ) sunit=value|su=num,sectlog=n|sectsize=num,\n\ lazy-count=0|1]\n\ /* label */ [-L label (maximum 12 characters)]\n\ -/* naming */ [-n log=n|size=num,version=n]\n\ +/* naming */ [-n log=n|size=num,version=n,utf8=none|default|turkic]\n\ /* prototype file */ [-p fname]\n\ /* quiet */ [-q]\n\ /* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx]\n\ =========================================================================== xfsprogs/mkfs/xfs_mkfs.h =========================================================================== --- a/xfsprogs/mkfs/xfs_mkfs.h 2007-10-23 17:14:16.000000000 +1000 +++ b/xfsprogs/mkfs/xfs_mkfs.h 2007-10-23 17:01:52.817055570 +1000 @@ -18,7 +18,7 @@ #ifndef __XFS_MKFS_H__ #define __XFS_MKFS_H__ -#define XFS_SB_VERSION_MKFS(ia,dia,extflag,dir2,log2,attr1,sflag,more) (\ +#define XFS_SB_VERSION_MKFS(ia,dia,extflag,dir2,log2,attr1,sflag,ci,more) (\ ((ia)||(dia)||(extflag)||(dir2)||(log2)||(attr1)||(sflag)||(more)) ? \ ( XFS_SB_VERSION_4 | \ ((ia) ? XFS_SB_VERSION_ALIGNBIT : 0) | \ @@ -28,13 +28,15 @@ ((log2) ? XFS_SB_VERSION_LOGV2BIT : 0) | \ ((attr1) ? XFS_SB_VERSION_ATTRBIT : 0) | \ ((sflag) ? XFS_SB_VERSION_SECTORBIT : 0) | \ + ((ci) ? XFS_SB_VERSION_OLDCIBIT : 0) | \ ((more) ? XFS_SB_VERSION_MOREBITSBIT : 0) | \ 0 ) : XFS_SB_VERSION_1 ) -#define XFS_SB_VERSION2_MKFS(lazycount, attr2, parent) (\ +#define XFS_SB_VERSION2_MKFS(lazycount, attr2, parent, unicode) (\ ((lazycount) ? XFS_SB_VERSION2_LAZYSBCOUNTBIT : 0) | \ ((attr2) ? XFS_SB_VERSION2_ATTR2BIT : 0) | \ ((parent) ? XFS_SB_VERSION2_PARENTBIT : 0) | \ + ((unicode) ? XFS_SB_VERSION2_UNICODEBIT : 0) | \ 0 ) #define XFS_DFL_BLOCKSIZE_LOG 12 /* 4096 byte blocks */ @@ -61,6 +63,24 @@ #define XFS_MAX_AGNUMBER ((xfs_agnumber_t)(NULLAGNUMBER - 1)) +/* casefoldtable.c/proto.c */ + +#define XFS_CFT_MAGIC 0x58434654 /* 'XCFT' */ + +typedef struct xfs_dcft { + __be32 magic; /* validity check */ + __be32 flags; + __be32 num_tables; /* single, double, etc */ + __be32 table_offset[1]; +} xfs_dcft_t; + +#define XFS_DCFT_PTR(t,n) (__be16*)(((char*)(t)) + \ + be32_to_cpu((t)->table_offset[n])) + +#define XFS_CFT_FLAG_TURKIC 0x00000001 + +#define LIBXFS_MOUNT_FLAG_TURKIC_CASE 0x1000 /* use turkic casefold table */ + /* xfs_mkfs.c */ extern void usage (void); From owner-xfs@oss.sgi.com Tue Oct 23 00:51:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 00:51:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_42,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_51, J_CHICKENPOX_53,J_CHICKENPOX_61,J_CHICKENPOX_62,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9N7pHQ8005590 for ; Tue, 23 Oct 2007 00:51:19 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 RAA11342; Tue, 23 Oct 2007 17:51:19 +1000 Date: Tue, 23 Oct 2007 17:53:10 +1000 To: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Subject: [RFC 1/2] Case-insensitive XFS - kernel patch From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4569/Mon Oct 22 22:39:55 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l9N7pMQ8005608 X-archive-position: 13423 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Makefile | 1 linux-2.6/xfs_iops.c | 89 ++++++++ linux-2.6/xfs_linux.h | 2 linux-2.6/xfs_super.c | 8 xfs_clnt.h | 5 xfs_da_btree.c | 20 + xfs_da_btree.h | 21 + xfs_dir2.c | 177 +++++++++++++--- xfs_dir2.h | 9 xfs_dir2_block.c | 30 +- xfs_dir2_data.c | 3 xfs_dir2_leaf.c | 19 + xfs_dir2_node.c | 5 xfs_dir2_sf.c | 35 ++- xfs_mount.c | 25 ++ xfs_mount.h | 8 xfs_sb.h | 33 ++- xfs_unicode.c | 547 ++++++++++++++++++++++++++++++++++++++++++++++++++ xfs_unicode.h | 75 ++++++ xfs_vfsops.c | 53 ++++ 20 files changed, 1100 insertions(+), 65 deletions(-) =========================================================================== fs/xfs/Makefile =========================================================================== --- a/fs/xfs/Makefile 2007-10-23 17:19:40.000000000 +1000 +++ b/fs/xfs/Makefile 2007-10-23 16:17:22.173903950 +1000 @@ -74,6 +74,7 @@ xfs-y += xfs_alloc.o \ xfs_trans_extfree.o \ xfs_trans_inode.o \ xfs_trans_item.o \ + xfs_unicode.o \ xfs_utils.o \ xfs_vfsops.o \ xfs_vnodeops.o \ =========================================================================== fs/xfs/linux-2.6/xfs_iops.c =========================================================================== --- a/fs/xfs/linux-2.6/xfs_iops.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_iops.c 2007-10-23 16:43:19.828562924 +1000 @@ -47,12 +47,17 @@ #include "xfs_buf_item.h" #include "xfs_utils.h" #include "xfs_vnodeops.h" +#include "xfs_da_btree.h" +#include "xfs_unicode.h" #include #include #include #include +struct dentry_operations xfs_dentry_operations; +struct dentry_operations xfs_nls_dentry_operations; + /* * Bring the atime in the XFS inode uptodate. * Used before logging the inode to disk or when the Linux inode goes away. @@ -369,10 +374,17 @@ xfs_vn_lookup( { bhv_vnode_t *cvp; int error; + struct xfs_mount *mp = XFS_I(dir)->i_mount; + struct dentry *result; if (dentry->d_name.len >= MAXNAMELEN) return ERR_PTR(-ENAMETOOLONG); + if (xfs_sb_version_hasunicode(&mp->m_sb) || + xfs_sb_version_hasoldci(&mp->m_sb)) + dentry->d_op = mp->m_nls ? &xfs_nls_dentry_operations : + &xfs_dentry_operations; + error = xfs_lookup(XFS_I(dir), dentry, &cvp); if (unlikely(error)) { if (unlikely(error != ENOENT)) @@ -381,7 +393,11 @@ xfs_vn_lookup( return NULL; } - return d_splice_alias(vn_to_inode(cvp), dentry); + result = d_splice_alias(vn_to_inode(cvp), dentry); + if (result) + result->d_op = dentry->d_op; + + return result; } STATIC int @@ -823,3 +839,74 @@ const struct inode_operations xfs_symlin .listxattr = xfs_vn_listxattr, .removexattr = xfs_vn_removexattr, }; + + +STATIC int +xfs_dentry_hash( + struct dentry *dir, + struct qstr *this) +{ + this->hash = xfs_dir_hashname(XFS_I(dir->d_inode), + this->name, this->len); + return 0; +} + +STATIC int +xfs_dentry_compare( + struct dentry *dir, + struct qstr *a, + struct qstr *b) +{ + int result = xfs_dir_compname(XFS_I(dir->d_inode), a->name, a->len, + b->name, b->len); + if (result == 0) { + if (a->len == b->len) + memcpy((unsigned char *)a->name, b->name, a->len); + else { + /* TODO: more complicated when name lengths differ */ + } + } + return result; +} + +STATIC int +xfs_nls_dentry_hash( + struct dentry *dir, + struct qstr *this) +{ + xfs_mount_t *mp = XFS_I(dir->d_inode)->i_mount; + + this->hash = xfs_nls_hash(mp->m_nls, mp->m_cft, this->name, this->len); + return 0; +} + +STATIC int +xfs_nls_dentry_compare( + struct dentry *dir, + struct qstr *a, + struct qstr *b) +{ + xfs_mount_t *mp = XFS_I(dir->d_inode)->i_mount; + int result = xfs_nls_casecmp(mp->m_nls, mp->m_cft, + a->name, a->len, b->name, b->len); + if (result == 0) { + if (a->len == b->len) + memcpy((unsigned char *)a->name, b->name, a->len); + else { + /* TODO: more complicated when name lengths differ */ + } + } + return result; +} + +struct dentry_operations xfs_dentry_operations = +{ + .d_hash = xfs_dentry_hash, + .d_compare = xfs_dentry_compare, +}; + +struct dentry_operations xfs_nls_dentry_operations = +{ + .d_hash = xfs_nls_dentry_hash, + .d_compare = xfs_nls_dentry_compare, +}; =========================================================================== fs/xfs/linux-2.6/xfs_linux.h =========================================================================== --- a/fs/xfs/linux-2.6/xfs_linux.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_linux.h 2007-10-10 15:16:26.698563845 +1000 @@ -75,6 +75,8 @@ #include #include #include +#include +#include #include #include =========================================================================== fs/xfs/linux-2.6/xfs_super.c =========================================================================== --- a/fs/xfs/linux-2.6/xfs_super.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_super.c 2007-10-23 16:43:46.017187812 +1000 @@ -50,6 +50,7 @@ #include "xfs_vnodeops.h" #include "xfs_vfsops.h" #include "xfs_version.h" +#include "xfs_unicode.h" #include #include @@ -65,6 +66,9 @@ static kmem_zone_t *xfs_vnode_zone; static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; +extern struct dentry_operations xfs_dentry_operations; +extern struct dentry_operations xfs_nls_dentry_operations; + STATIC struct xfs_mount_args * xfs_args_allocate( struct super_block *sb, @@ -871,6 +875,10 @@ xfs_fs_fill_super( error = EINVAL; goto fail_vnrele; } + if (xfs_sb_version_hasunicode(&mp->m_sb) || + xfs_sb_version_hasoldci(&mp->m_sb)) + sb->s_root->d_op = mp->m_nls ? &xfs_nls_dentry_operations : + &xfs_dentry_operations; mp->m_sync_work.w_syncer = xfs_sync_worker; mp->m_sync_work.w_mount = mp; =========================================================================== fs/xfs/xfs_clnt.h =========================================================================== --- a/fs/xfs/xfs_clnt.h 2007-10-23 17:19:40.000000000 +1000 +++ b/fs/xfs/xfs_clnt.h 2007-10-12 17:07:03.022094920 +1000 @@ -48,6 +48,7 @@ struct xfs_mount_args { char rtname[MAXNAMELEN+1]; /* realtime device filename */ char logname[MAXNAMELEN+1]; /* journal device filename */ char mtpt[MAXNAMELEN+1]; /* filesystem mount point */ + char nls[MAXNAMELEN+1]; /* NLS code page to use */ int sunit; /* stripe unit (BBs) */ int swidth; /* stripe width (BBs), multiple of sunit */ uchar_t iosizelog; /* log2 of the preferred I/O size */ @@ -100,5 +101,9 @@ struct xfs_mount_args { * I/O size in stat(2) */ #define XFSMNT2_FILESTREAMS 0x00000002 /* enable the filestreams * allocator */ +#define XFSMNT2_CILOOKUP 0x00000004 /* enable case-insensitive + * filename lookup */ +#define XFSMNT2_CIATTR 0x00000008 /* enable case-insensitive + * extended attrs */ #endif /* __XFS_CLNT_H__ */ =========================================================================== fs/xfs/xfs_da_btree.c =========================================================================== --- a/fs/xfs/xfs_da_btree.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_da_btree.c 2007-10-22 17:09:31.333665254 +1000 @@ -1530,6 +1530,26 @@ xfs_da_hashname(const uchar_t *name, int } } + +xfs_dahash_t +xfs_default_hashname(xfs_inode_t *inode, const uchar_t *name, int namelen) +{ + return xfs_da_hashname(name, namelen); +} + +int +xfs_default_compname(xfs_inode_t *inode, const uchar_t *name1, int len1, + const uchar_t *name2, int len2) +{ + return (len1 == len2) ? memcmp(name1, name2, len1) : + (len1 < len2) ? -1 : 1; +} + +const struct xfs_nameops xfs_default_nameops = { + .hashname = xfs_default_hashname, + .compname = xfs_default_compname +}; + /* * Add a block to the btree ahead of the file. * Return the new block number to the caller. =========================================================================== fs/xfs/xfs_da_btree.h =========================================================================== --- a/fs/xfs/xfs_da_btree.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_da_btree.h 2007-10-23 16:19:40.083993281 +1000 @@ -208,6 +208,27 @@ typedef struct xfs_da_state { *========================================================================*/ /* + * Name ops for directory and/or attr name operations + */ + +typedef xfs_dahash_t (*xfs_hashname_t)(struct xfs_inode *, + const uchar_t *, int); +typedef int (*xfs_compname_t)(struct xfs_inode *, const uchar_t *, int, + const uchar_t *, int); + +typedef struct xfs_nameops { + xfs_hashname_t hashname; + xfs_compname_t compname; +} xfs_nameops_t; + +extern const struct xfs_nameops xfs_default_nameops; + +xfs_dahash_t xfs_default_hashname(struct xfs_inode *inode, const uchar_t *name, + int namelen); +int xfs_default_compname(struct xfs_inode *inode, const uchar_t *name1, + int len1, const uchar_t *name2, int len2); + +/* * Routines used for growing the Btree. */ int xfs_da_node_create(xfs_da_args_t *args, xfs_dablk_t blkno, int level, =========================================================================== fs/xfs/xfs_dir2.c =========================================================================== --- a/fs/xfs/xfs_dir2.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2.c 2007-10-23 16:42:40.857585216 +1000 @@ -42,9 +42,71 @@ #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" +static xfs_dahash_t +xfs_ascii_ci_hashname( + xfs_inode_t *inode, + const uchar_t *name, + int namelen) +{ + xfs_dahash_t hash; + int i; + + for (i = 0, hash = 0; i < namelen; i++) + hash = tolower(name[i]) ^ rol32(hash, 7); + + return hash; +} + +static int +xfs_ascii_ci_compname( + xfs_inode_t *inode, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + return (len1 == len2) ? strncasecmp(name1, name2, len1) : len1 - len2; +} + +static xfs_dahash_t +xfs_unicode_ci_hashname( + xfs_inode_t *inode, + const uchar_t *name, + int namelen) +{ + return xfs_unicode_hash(inode->i_mount->m_cft, name, namelen); +} -void +static int +xfs_unicode_ci_compname( + xfs_inode_t *inode, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + return xfs_unicode_casecmp(inode->i_mount->m_cft, + name1, len1, name2, len2); +} + +static const struct xfs_nameops xfs_ascii_ci_nameops = { + .hashname = xfs_ascii_ci_hashname, + .compname = xfs_ascii_ci_compname, +}; + +static const struct xfs_nameops xfs_unicode_nameops = { + .hashname = xfs_unicode_ci_hashname, + .compname = xfs_default_compname, +}; + +static const struct xfs_nameops xfs_unicode_ci_nameops = { + .hashname = xfs_unicode_ci_hashname, + .compname = xfs_unicode_ci_compname, +}; + +int xfs_dir_mount( xfs_mount_t *mp) { @@ -63,6 +125,15 @@ xfs_dir_mount( (mp->m_dirblksize - (uint)sizeof(xfs_da_node_hdr_t)) / (uint)sizeof(xfs_da_node_entry_t); mp->m_dir_magicpct = (mp->m_dirblksize * 37) / 100; + + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + mp->m_dirnameops = (mp->m_flags & XFS_MOUNT_CI_LOOKUP) ? + &xfs_unicode_ci_nameops : &xfs_unicode_nameops; + } else + mp->m_dirnameops = (xfs_sb_version_hasoldci(&mp->m_sb)) ? + &xfs_ascii_ci_nameops : &xfs_default_nameops; + + return 0; } /* @@ -139,6 +210,50 @@ xfs_dir_init( } /* + * Set up the args with appropriate name and hash value + */ + +static int +xfs_dir_setup_name_and_hash( + xfs_da_args_t *args, + const char *name, + int namelen) +{ + char *uname; + + if (args->dp->i_mount->m_nls) { + uname = kmem_alloc(MAXNAMELEN, KM_SLEEP); + args->namelen = xfs_nls_to_unicode(args->dp->i_mount->m_nls, + name, namelen, uname, MAXNAMELEN); + if (args->namelen < 0) { + kmem_free(uname, MAXNAMELEN); + return -args->namelen; + } + args->name = uname; + } else { + if (xfs_sb_version_hasunicode(&args->dp->i_mount->m_sb)) { + int rval; + rval = xfs_unicode_validate(name, namelen); + if (rval < 0) + return -rval; + } + args->name = name; + args->namelen = namelen; + } + args->hashval = xfs_dir_hashname(args->dp, args->name, args->namelen); + return 0; +} + +static inline void +xfs_dir_cleanup_name( + xfs_da_args_t *args, + const uchar_t *name) +{ + if (args->name != name) + kmem_free((void *)args->name, MAXNAMELEN); +} + +/* Enter a name in a directory. */ int @@ -161,9 +276,6 @@ xfs_dir_createname( return rval; XFS_STATS_INC(xs_dir_create); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = inum; args.dp = dp; args.firstblock = first; @@ -173,19 +285,24 @@ xfs_dir_createname( args.trans = tp; args.justcheck = 0; args.addname = args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_addname(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_addname(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_addname(&args); else rval = xfs_dir2_node_addname(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -207,9 +324,6 @@ xfs_dir_lookup( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_lookup); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = 0; args.dp = dp; args.firstblock = NULL; @@ -219,15 +333,18 @@ xfs_dir_lookup( args.trans = tp; args.justcheck = args.addname = 0; args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_lookup(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_lookup(&args); else @@ -236,6 +353,8 @@ xfs_dir_lookup( rval = 0; if (rval == 0) *inum = args.inumber; +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -260,9 +379,6 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = ino; args.dp = dp; args.firstblock = first; @@ -271,19 +387,24 @@ xfs_dir_removename( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 0; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_removename(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_removename(&args); else rval = xfs_dir2_node_removename(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -344,9 +465,6 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = inum; args.dp = dp; args.firstblock = first; @@ -355,19 +473,24 @@ xfs_dir_replace( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 0; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_replace(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_replace(&args); else rval = xfs_dir2_node_replace(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -387,9 +510,6 @@ xfs_dir_canenter( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = 0; args.dp = dp; args.firstblock = NULL; @@ -398,19 +518,24 @@ xfs_dir_canenter( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_addname(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_addname(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_addname(&args); else rval = xfs_dir2_node_addname(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } =========================================================================== fs/xfs/xfs_dir2.h =========================================================================== --- a/fs/xfs/xfs_dir2.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2.h 2007-10-22 17:32:23.984399805 +1000 @@ -63,7 +63,7 @@ typedef xfs_off_t xfs_dir2_off_t; * Generic directory interface routines */ extern void xfs_dir_startup(void); -extern void xfs_dir_mount(struct xfs_mount *mp); +extern int xfs_dir_mount(struct xfs_mount *mp); extern int xfs_dir_isempty(struct xfs_inode *dp); extern int xfs_dir_init(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_inode *pdp); @@ -85,6 +85,13 @@ extern int xfs_dir_canenter(struct xfs_t char *name, int namelen); extern int xfs_dir_ino_validate(struct xfs_mount *mp, xfs_ino_t ino); +#define xfs_dir_hashname(dp, n, l) \ + ((dp)->i_mount->m_dirnameops->hashname((dp), (n), (l))) + +#define xfs_dir_compname(dp, n1, l1, n2, l2) \ + ((dp)->i_mount->m_dirnameops->compname((dp), (n1), (l1), \ + (n2), (l2))) + /* * Utility routines for v2 directories. */ =========================================================================== fs/xfs/xfs_dir2_block.c =========================================================================== --- a/fs/xfs/xfs_dir2_block.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_block.c 2007-10-15 16:57:13.164123893 +1000 @@ -38,6 +38,7 @@ #include "xfs_dir2_block.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" /* * Local function prototypes. @@ -450,6 +451,8 @@ xfs_dir2_block_getdents( int wantoff; /* starting block offset */ xfs_ino_t ino; xfs_off_t cook; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; mp = dp->i_mount; /* @@ -481,6 +484,9 @@ xfs_dir2_block_getdents( ptr = (char *)block->u; endptr = (char *)xfs_dir2_block_leaf_p(btp); + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Loop over the data portion of the block. * Each object is a real entry (dep) or an unused one (dup). @@ -513,17 +519,21 @@ xfs_dir2_block_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, dep->name, + dep->namelen, nls_name, MAXNAMELEN); /* * If it didn't fit, set the final offset to here & return. */ - if (filldir(dirent, dep->name, dep->namelen, cook, - ino, DT_UNKNOWN)) { + + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)dep->name, + nls_namelen > 0 ? nls_namelen : dep->namelen, + cook, ino, DT_UNKNOWN)) { *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (char *)dep - (char *)block); - xfs_da_brelse(NULL, bp); - return 0; + goto out; } } @@ -532,7 +542,10 @@ xfs_dir2_block_getdents( * Set the offset to a non-existent block 1 and return. */ *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); +out: xfs_da_brelse(NULL, bp); + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return 0; } @@ -701,9 +714,8 @@ xfs_dir2_block_lookup_int( /* * Compare, if it's right give back buffer & entry number. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, args->name, + args->namelen) == 0) { *bpp = bp; *entno = mid; return 0; @@ -1189,8 +1201,8 @@ xfs_dir2_sf_to_block( tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); xfs_dir2_data_log_entry(tp, bp, dep); - blp[2 + i].hashval = cpu_to_be32(xfs_da_hashname( - (char *)sfep->name, sfep->namelen)); + blp[2 + i].hashval = cpu_to_be32(xfs_dir_hashname(dp, + sfep->name, sfep->namelen)); blp[2 + i].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); offset = (int)((char *)(tagp + 1) - (char *)block); =========================================================================== fs/xfs/xfs_dir2_data.c =========================================================================== --- a/fs/xfs/xfs_dir2_data.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_data.c 2007-10-10 15:10:39.019079916 +1000 @@ -140,7 +140,8 @@ xfs_dir2_data_check( addr = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (xfs_dir2_data_aoff_t) ((char *)dep - (char *)d)); - hash = xfs_da_hashname((char *)dep->name, dep->namelen); + hash = xfs_dir_hashname(dp, (char *)dep->name, + dep->namelen); for (i = 0; i < be32_to_cpu(btp->count); i++) { if (be32_to_cpu(lep[i].address) == addr && be32_to_cpu(lep[i].hashval) == hash) =========================================================================== fs/xfs/xfs_dir2_leaf.c =========================================================================== --- a/fs/xfs/xfs_dir2_leaf.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_leaf.c 2007-10-15 16:57:31.749743368 +1000 @@ -40,6 +40,7 @@ #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" /* * Local function declarations. @@ -780,6 +781,8 @@ xfs_dir2_leaf_getdents( int ra_offset; /* map entry offset for ra */ int ra_want; /* readahead count wanted */ xfs_ino_t ino; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; /* * If the offset is at or past the largest allowed value, @@ -800,6 +803,9 @@ xfs_dir2_leaf_getdents( map_valid = ra_index = ra_offset = ra_current = map_blocks = 0; bp = NULL; + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Inside the loop we keep the main offset value as a byte offset * in the directory file. @@ -1086,11 +1092,15 @@ xfs_dir2_leaf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, dep->name, + dep->namelen, nls_name, MAXNAMELEN); /* * Won't fit. Return to caller. */ - if (filldir(dirent, dep->name, dep->namelen, + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)dep->name, + nls_namelen > 0 ? nls_namelen : dep->namelen, xfs_dir2_byte_to_dataptr(mp, curoff + length), ino, DT_UNKNOWN)) break; @@ -1113,6 +1123,8 @@ xfs_dir2_leaf_getdents( kmem_free(map, map_size * sizeof(*map)); if (bp) xfs_da_brelse(NULL, bp); + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return error; } @@ -1392,9 +1404,8 @@ xfs_dir2_leaf_lookup_int( /* * If it matches then return it. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, args->name, + args->namelen) == 0) { *dbpp = dbp; *indexp = index; return 0; =========================================================================== fs/xfs/xfs_dir2_node.c =========================================================================== --- a/fs/xfs/xfs_dir2_node.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_node.c 2007-10-10 15:11:08.719279567 +1000 @@ -578,9 +578,8 @@ xfs_dir2_leafn_lookup_int( /* * Compare the entry, return it if it matches. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, + args->name, args->namelen) == 0) { args->inumber = be64_to_cpu(dep->inumber); *indexp = index; state->extravalid = 1; =========================================================================== fs/xfs/xfs_dir2_sf.c =========================================================================== --- a/fs/xfs/xfs_dir2_sf.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_sf.c 2007-10-18 14:03:09.916774315 +1000 @@ -38,6 +38,7 @@ #include "xfs_dir2_leaf.h" #include "xfs_dir2_block.h" #include "xfs_dir2_trace.h" +#include "xfs_unicode.h" /* * Prototypes for internal functions. @@ -708,6 +709,8 @@ xfs_dir2_sf_getdents( xfs_dir2_dataptr_t dot_offset; xfs_dir2_dataptr_t dotdot_offset; xfs_ino_t ino; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; mp = dp->i_mount; @@ -774,6 +777,9 @@ xfs_dir2_sf_getdents( } } + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Loop while there are more entries and put'ing works. */ @@ -791,17 +797,22 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - - if (filldir(dirent, sfep->name, sfep->namelen, + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, sfep->name, + sfep->namelen, nls_name, MAXNAMELEN); + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)sfep->name, + nls_namelen > 0 ? nls_namelen : sfep->namelen, off + xfs_dir2_data_entsize(sfep->namelen), ino, DT_UNKNOWN)) { *offset = off; - return 0; + goto out; } sfep = xfs_dir2_sf_nextentry(sfp, sfep); } - *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); +out: + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return 0; } @@ -855,9 +866,8 @@ xfs_dir2_sf_lookup( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(args->name, sfep->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, sfep->namelen, + args->name, args->namelen) == 0) { args->inumber = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); @@ -910,9 +920,8 @@ xfs_dir2_sf_removename( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(sfep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, sfep->namelen, + args->name, args->namelen) == 0) { ASSERT(xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)) == args->inumber); @@ -1047,9 +1056,9 @@ xfs_dir2_sf_replace( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(args->name, sfep->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, + sfep->namelen, args->name, + args->namelen) == 0) { #if XFS_BIG_INUMS || defined(DEBUG) ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); =========================================================================== fs/xfs/xfs_mount.c =========================================================================== --- a/fs/xfs/xfs_mount.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_mount.c 2007-10-23 16:36:16.371190339 +1000 @@ -43,6 +43,7 @@ #include "xfs_rw.h" #include "xfs_quota.h" #include "xfs_fsops.h" +#include "xfs_unicode.h" STATIC void xfs_mount_log_sbunit(xfs_mount_t *, __int64_t); STATIC int xfs_uuid_mount(xfs_mount_t *); @@ -119,6 +120,8 @@ static const struct { { offsetof(xfs_sb_t, sb_logsectsize),0 }, { offsetof(xfs_sb_t, sb_logsunit), 0 }, { offsetof(xfs_sb_t, sb_features2), 0 }, + { offsetof(xfs_sb_t, sb_reserved), 0 }, + { offsetof(xfs_sb_t, sb_cftino), 0 }, { sizeof(xfs_sb_t), 0 } }; @@ -171,6 +174,9 @@ xfs_mount_free( sizeof(xfs_perag_t) * mp->m_sb.sb_agcount); } + if (mp->m_cft) + xfs_unicode_free_cft(mp->m_cft); + spinlock_destroy(&mp->m_ail_lock); spinlock_destroy(&mp->m_sb_lock); mutex_destroy(&mp->m_ilock); @@ -455,6 +461,8 @@ xfs_sb_from_disk( to->sb_logsectsize = be16_to_cpu(from->sb_logsectsize); to->sb_logsunit = be32_to_cpu(from->sb_logsunit); to->sb_features2 = be32_to_cpu(from->sb_features2); + to->sb_bad_features2 = be32_to_cpu(from->sb_bad_features2); + to->sb_cftino = be64_to_cpu(from->sb_cftino); } /* @@ -1057,7 +1065,9 @@ xfs_mountfs( mp->m_dmevmask = 0; /* not persistent; set after each mount */ - xfs_dir_mount(mp); + error = xfs_dir_mount(mp); + if (error) + goto error1; /* * Initialize the attribute manager's entries. @@ -1165,6 +1175,17 @@ xfs_mountfs( } /* + * Load in unicode case folding table from disk + */ + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + error = xfs_unicode_read_cft(mp); + if (error) { + cmn_err(CE_WARN, "XFS: failed to read unicode table"); + goto error4; + } + } + + /* * If fs is not mounted readonly, then update the superblock * unit and width changes. */ @@ -1220,6 +1241,8 @@ xfs_mountfs( * Free up the root inode. */ VN_RELE(rvp); + if (mp->m_cft) + xfs_unicode_free_cft(mp->m_cft); error3: xfs_log_unmount_dealloc(mp); error2: =========================================================================== fs/xfs/xfs_mount.h =========================================================================== --- a/fs/xfs/xfs_mount.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_mount.h 2007-10-22 13:57:35.769401728 +1000 @@ -54,6 +54,7 @@ typedef struct xfs_trans_reservations { #else struct cred; struct log; +struct nls_table; struct xfs_mount_args; struct xfs_inode; struct xfs_bmbt_irec; @@ -61,6 +62,8 @@ struct xfs_bmap_free; struct xfs_extdelta; struct xfs_swapext; struct xfs_mru_cache; +struct xfs_nameops; +struct xfs_cft; /* * Prototypes and functions for the Data Migration subsystem. @@ -306,6 +309,9 @@ typedef struct xfs_mount { __uint8_t m_inode_quiesce;/* call quiesce on new inodes. field governed by m_ilock */ __uint8_t m_sectbb_log; /* sectlog - BBSHIFT */ + const struct xfs_nameops *m_dirnameops; /* vector of dir name ops */ + const struct xfs_cft *m_cft; /* unicode case fold table */ + struct nls_table *m_nls; /* active NLS table */ int m_dirblksize; /* directory block sz--bytes */ int m_dirblkfsbs; /* directory block sz--fsbs */ xfs_dablk_t m_dirdatablk; /* blockno of dir data v2 */ @@ -371,6 +377,8 @@ typedef struct xfs_mount { counters */ #define XFS_MOUNT_FILESTREAMS (1ULL << 24) /* enable the filestreams allocator */ +#define XFS_MOUNT_CI_LOOKUP (1ULL << 25) /* enable case-insensitive + * file lookup */ /* =========================================================================== fs/xfs/xfs_sb.h =========================================================================== --- a/fs/xfs/xfs_sb.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_sb.h 2007-10-23 16:55:47.440178601 +1000 @@ -46,10 +46,12 @@ struct xfs_mount; #define XFS_SB_VERSION_SECTORBIT 0x0800 #define XFS_SB_VERSION_EXTFLGBIT 0x1000 #define XFS_SB_VERSION_DIRV2BIT 0x2000 +#define XFS_SB_VERSION_OLDCIBIT 0x4000 #define XFS_SB_VERSION_MOREBITSBIT 0x8000 #define XFS_SB_VERSION_OKSASHFBITS \ (XFS_SB_VERSION_EXTFLGBIT | \ - XFS_SB_VERSION_DIRV2BIT) + XFS_SB_VERSION_DIRV2BIT | \ + XFS_SB_VERSION_OLDCIBIT) #define XFS_SB_VERSION_OKREALFBITS \ (XFS_SB_VERSION_ATTRBIT | \ XFS_SB_VERSION_NLINKBIT | \ @@ -77,10 +79,12 @@ struct xfs_mount; #define XFS_SB_VERSION2_LAZYSBCOUNTBIT 0x00000002 /* Superblk counters */ #define XFS_SB_VERSION2_RESERVED4BIT 0x00000004 #define XFS_SB_VERSION2_ATTR2BIT 0x00000008 /* Inline attr rework */ +#define XFS_SB_VERSION2_UNICODEBIT 0x00000020 /* Unicode names */ #define XFS_SB_VERSION2_OKREALFBITS \ (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \ - XFS_SB_VERSION2_ATTR2BIT) + XFS_SB_VERSION2_ATTR2BIT | \ + XFS_SB_VERSION2_UNICODEBIT) #define XFS_SB_VERSION2_OKSASHFBITS \ (0) #define XFS_SB_VERSION2_OKREALBITS \ @@ -145,6 +149,9 @@ typedef struct xfs_sb { __uint16_t sb_logsectsize; /* sector size for the log, bytes */ __uint32_t sb_logsunit; /* stripe unit size for the log */ __uint32_t sb_features2; /* additional feature bits */ + __uint32_t sb_bad_features2; /* features2 could be here */ + xfs_ino_t sb_cftino; /* unicode case folding table inode */ + /* must be padded to 64 bit alignment */ } xfs_sb_t; /* @@ -205,6 +212,9 @@ typedef struct xfs_dsb { __be16 sb_logsectsize; /* sector size for the log, bytes */ __be32 sb_logsunit; /* stripe unit size for the log */ __be32 sb_features2; /* additional feature bits */ + __be32 sb_bad_features2; /* features2 could be here */ + __be64 sb_cftino; /* unicode case folding table inode */ + /* must be padded to 64 bit alignment */ } xfs_dsb_t; /* @@ -223,7 +233,7 @@ typedef enum { XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN, XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG, XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT, - XFS_SBS_FEATURES2, + XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2, XFS_SBS_CFTINO, XFS_SBS_FIELDCOUNT } xfs_sb_field_t; @@ -248,13 +258,15 @@ typedef enum { #define XFS_SB_IFREE XFS_SB_MVAL(IFREE) #define XFS_SB_FDBLOCKS XFS_SB_MVAL(FDBLOCKS) #define XFS_SB_FEATURES2 XFS_SB_MVAL(FEATURES2) +#define XFS_SB_CASEFOLDINO XFS_SB_MVAL(CASEFOLDINO) #define XFS_SB_NUM_BITS ((int)XFS_SBS_FIELDCOUNT) #define XFS_SB_ALL_BITS ((1LL << XFS_SB_NUM_BITS) - 1) #define XFS_SB_MOD_BITS \ (XFS_SB_UUID | XFS_SB_ROOTINO | XFS_SB_RBMINO | XFS_SB_RSUMINO | \ XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO | XFS_SB_GQUOTINO | \ XFS_SB_QFLAGS | XFS_SB_SHARED_VN | XFS_SB_UNIT | XFS_SB_WIDTH | \ - XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2) + XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2 | \ + XFS_SB_CFTINO) /* @@ -463,6 +475,12 @@ static inline int xfs_sb_version_hassect ((sbp)->sb_versionnum & XFS_SB_VERSION_SECTORBIT); } +static inline int xfs_sb_version_hasoldci(xfs_sb_t *sbp) +{ + return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ + ((sbp)->sb_versionnum & XFS_SB_VERSION_OLDCIBIT); +} + #define XFS_SB_VERSION_HASMOREBITS(sbp) xfs_sb_version_hasmorebits(sbp) static inline int xfs_sb_version_hasmorebits(xfs_sb_t *sbp) { @@ -502,6 +520,13 @@ static inline void xfs_sb_version_addatt ((sbp)->sb_features2 | XFS_SB_VERSION2_ATTR2BIT))); } +static inline int xfs_sb_version_hasunicode(xfs_sb_t *sbp) +{ + return (xfs_sb_version_hasmorebits(sbp) && \ + ((sbp)->sb_features2 & XFS_SB_VERSION2_UNICODEBIT)); +} + + /* * end of superblock version macros */ =========================================================================== fs/xfs/xfs_unicode.c =========================================================================== --- a/fs/xfs/xfs_unicode.c 2006-06-17 00:58:24.000000000 +1000 +++ b/fs/xfs/xfs_unicode.c 2007-10-23 16:17:02.336480442 +1000 @@ -0,0 +1,547 @@ +/* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "xfs.h" +#include "xfs_fs.h" +#include "xfs_bit.h" +#include "xfs_log.h" +#include "xfs_inum.h" +#include "xfs_clnt.h" +#include "xfs_trans.h" +#include "xfs_sb.h" +#include "xfs_ag.h" +#include "xfs_dir2.h" +#include "xfs_alloc.h" +#include "xfs_dmapi.h" +#include "xfs_mount.h" +#include "xfs_bmap_btree.h" +#include "xfs_alloc_btree.h" +#include "xfs_ialloc_btree.h" +#include "xfs_dir2_sf.h" +#include "xfs_attr_sf.h" +#include "xfs_dinode.h" +#include "xfs_inode.h" +#include "xfs_btree.h" +#include "xfs_ialloc.h" +#include "xfs_itable.h" +#include "xfs_rtalloc.h" +#include "xfs_error.h" +#include "xfs_bmap.h" +#include "xfs_unicode.h" + +#define MAX_FOLD_CHARS 4 + +static inline int +xfs_casefold( + const xfs_cft_t *cft, + __uint16_t c, + __uint16_t *fc) +{ + __uint16_t *table = XFS_CFT_PTR(cft, 0); + __uint16_t tmp = table[c >> 8]; + int i; + + if (!tmp) { + *fc = c; + return 1; + } + tmp = table[tmp + (c & 0xff)]; + if ((tmp & 0xf000) != 0xe000) { + *fc = tmp; + return 1; + } + i = ((tmp >> 10) & 0x3) + 2; + ASSERT(i < cft->num_tables); + table = XFS_CFT_PTR(cft, i - 1) + ((tmp & 0x3ff) * i); + + memcpy(fc, table, sizeof(__uint16_t) * i); + + return i; +} + +static inline int +xfs_utf8_casefold( + const xfs_cft_t *cft, + const uchar_t **name, + int *namelen, + __uint16_t *fc) +{ + wchar_t uc; + + if (*namelen == 0) + return 0; + + if (**name & 0x80) { + int n = utf8_mbtowc(&uc, *name, *namelen); + if (n < 0) { + (*namelen)--; + *fc = *(*name)++; + return 1; + } + *name += n; + *namelen -= n; + } else { + uc = *(*name)++; + (*namelen)--; + } + return xfs_casefold(cft, uc, fc); +} + +__uint32_t +xfs_unicode_hash( + const xfs_cft_t *cft, + const uchar_t *name, + int namelen) +{ + __uint32_t hash = 0; + __uint16_t fc[MAX_FOLD_CHARS]; + int nfc; + int i; + + while (namelen > 0) { + nfc = xfs_utf8_casefold(cft, &name, &namelen, fc); + for (i = 0; i < nfc; i++) + hash = fc[i] ^ rol32(hash, 7); + } + return hash; +} + +int +xfs_unicode_casecmp( + const xfs_cft_t *cft, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + __uint16_t fc1[MAX_FOLD_CHARS], fc2[MAX_FOLD_CHARS]; + __uint16_t *pfc1, *pfc2; + int nfc1, nfc2; + + nfc1 = xfs_utf8_casefold(cft, &name1, &len1, fc1); + pfc1 = fc1; + nfc2 = xfs_utf8_casefold(cft, &name2, &len2, fc2); + pfc2 = fc2; + + while (nfc1 > 0 && nfc2 > 0) { + if (*pfc1 != *pfc2) + return (*pfc1 < *pfc2) ? -1 : 1; + if (!--nfc1) { + nfc1 = xfs_utf8_casefold(cft, &name1, &len1, fc1); + pfc1 = fc1; + } else + pfc1++; + if (!--nfc2) { + nfc2 = xfs_utf8_casefold(cft, &name2, &len2, fc2); + pfc2 = fc2; + } else + pfc2++; + } + if (nfc1 != nfc2) + return (nfc1 < nfc2) ? -1 : 1; + return 0; +} + + +int +xfs_nls_to_unicode( + struct nls_table *nls, + const char *nls_name, + int nls_namelen, + char *uni_name, + int uni_buflen) +{ + int i, o; + wchar_t uc; + int nlen; + int u8len; + + if (!nls) { + if (uni_buflen < nls_namelen) + return -ENAMETOOLONG; + memcpy(uni_name, nls_name, nls_namelen); + return nls_namelen; + } + + for (i = 0, o = 0; i < nls_namelen; i += nlen, o += u8len) { + nlen = nls->char2uni(nls_name + i, nls_namelen - i, &uc); + if (nlen < 0) + return nlen; + if (uc >= 0xfffe || (uc >= 0xd800 && uc <= 0xdfff)) + return -EINVAL; /* don't support chars outside BMP */ + u8len = utf8_wctomb(uni_name + o, uc, uni_buflen - o); + if (u8len <= 0) + return (uni_buflen - o < 3) ? -ENAMETOOLONG : -EINVAL; + } + return o; +} + +int +xfs_unicode_to_nls( + struct nls_table *nls, + const char *uni_name, + int uni_namelen, + char *nls_name, + int nls_buflen) +{ + int i, o; + wchar_t uc; + int nlen; + int u8len; + + if (!nls) { + if (nls_buflen < uni_namelen) + return -ENAMETOOLONG; + memcpy(nls_name, uni_name, uni_namelen); + return uni_namelen; + } + + for (i = 0, o = 0; i < uni_namelen && o < nls_buflen; i += u8len, o += nlen) { + u8len = utf8_mbtowc(&uc, uni_name + i, uni_namelen - i); + if (u8len < 0) + return -EINVAL; + nlen = nls->uni2char(uc, nls_name + o, nls_buflen - o); + if (nlen == -EINVAL) { + nls_name[o] = '?'; + nlen = 1; + } else if (nlen < 0) + return nlen; + } + if (i < uni_namelen) + return -ENAMETOOLONG; + return o; +} + +static inline int +xfs_nls_casefold( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t **name, + int *namelen, + __uint16_t *fc) +{ + wchar_t uc; + + if (*namelen == 0) + return 0; + + if (**name & 0x80) { + int n = nls->char2uni(*name, *namelen, &uc); + if (n < 0) { + uc = *(*name)++; + (*namelen)--; + } else { + *name += n; + *namelen -= n; + } + } else { + uc = *(*name)++; + (*namelen)--; + } + return xfs_casefold(cft, uc, fc); +} + + +__uint32_t +xfs_nls_hash( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t *name, + int namelen) +{ + __uint32_t hash = 0; + __uint16_t fc[MAX_FOLD_CHARS]; + int i, nfc; + + while (namelen > 0) { + nfc = xfs_nls_casefold(nls, cft, &name, &namelen, fc); + for (i = 0; i < nfc; i++) + hash = fc[i] ^ rol32(hash, 7); + } + return hash; +} + +int +xfs_nls_casecmp( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + __uint16_t fc1[MAX_FOLD_CHARS], fc2[MAX_FOLD_CHARS]; + __uint16_t *pfc1, *pfc2; + int nfc1, nfc2; + + nfc1 = xfs_nls_casefold(nls, cft, &name1, &len1, fc1); + pfc1 = fc1; + nfc2 = xfs_nls_casefold(nls, cft, &name2, &len2, fc2); + pfc2 = fc2; + + while (nfc1 > 0 && nfc2 > 0) { + if (*pfc1 != *pfc2) + return (*pfc1 < *pfc2) ? -1 : 1; + if (!--nfc1) { + nfc1 = xfs_nls_casefold(nls, cft, &name1, &len1, fc1); + pfc1 = fc1; + } else + pfc1++; + if (!--nfc2) { + nfc2 = xfs_nls_casefold(nls, cft, &name2, &len2, fc2); + pfc2 = fc2; + } else + pfc2++; + } + if (nfc1 != nfc2) + return (nfc1 < nfc2) ? -1 : 1; + return 0; + +} + +int +xfs_unicode_validate( + const uchar_t *name, + int namelen) +{ + wchar_t uc; + int i, nlen; + + for (i = 0; i < namelen; i += nlen) { + if (*name >= 0xf0) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "UTF-8 char beyond U+FFFF\n"); + return -EINVAL; + } + /* utf8_mbtowc must fail on overlong sequences too */ + nlen = utf8_mbtowc(&uc, name + i, namelen - i); + if (nlen < 0) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "invalid UTF-8 sequence\n"); + return -EILSEQ; + } + /* check for invalid/surrogate/private unicode chars */ + if (uc >= 0xfffe || (uc >= 0xd800 && uc <= 0xf8ff)) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "unsupported UTF-8 char\n"); + return -EINVAL; + } + } + return 0; +} + +/* + * Unicode Case Fold Table management + */ + +struct cft_item { + xfs_cft_t *table; + int size; + int refcount; +}; + +static mutex_t cft_lock; +static int cft_size; +static struct cft_item *cft_list; + +static xfs_cft_t * +add_cft( + xfs_dcft_t *dcft, + int size) +{ + int found = 0; + int i, j; + xfs_cft_t *cft; + __be16 *duc; + __uint16_t *uc; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + if (cft_list[i].size != size) + continue; + cft = cft_list[i].table; + if (cft->num_tables != be32_to_cpu(dcft->num_tables) || + cft->flags != be32_to_cpu(dcft->flags)) + continue; + found = 1; + for (j = 0; j < cft->num_tables; j++) { + if (cft->table_offset[j] != + be32_to_cpu(dcft->table_offset[j])) { + found = 0; + break; + } + } + if (found) { + cft_list[i].refcount++; + mutex_unlock(&cft_lock); + return cft; + } + } + + cft = vmalloc(size); + if (!cft) { + mutex_unlock(&cft_lock); + return NULL; + } + cft->magic = be32_to_cpu(dcft->magic); + cft->flags = be32_to_cpu(dcft->flags); + cft->num_tables = be32_to_cpu(dcft->num_tables); + ASSERT(cft->num_tables <= MAX_FOLD_CHARS); + for (i = 0; i < cft->num_tables; i++) + cft->table_offset[i] = be32_to_cpu(dcft->table_offset[i]); + j = (size - cft->table_offset[0]) / sizeof(__uint16_t); + uc = XFS_CFT_PTR(cft, 0); + duc = XFS_DCFT_PTR(dcft, 0); + for (i = 0; i < j; i++) + uc[i] = be16_to_cpu(duc[i]); + + cft_list = kmem_realloc(cft_list, + (cft_size + 1) * sizeof(struct cft_item), + cft_size * sizeof(struct cft_item), KM_SLEEP); + cft_list[cft_size].table = cft; + cft_list[cft_size].size = size; + cft_list[cft_size].refcount = 1; + cft_size++; + + mutex_unlock(&cft_lock); + + return cft; +} + +static void +remove_cft( + const xfs_cft_t *cft) +{ + int i; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + if (cft_list[i].table == cft) { + ASSERT(cft_list[i].refcount > 0); + cft_list[i].refcount--; + break; + } + } + + mutex_unlock(&cft_lock); +} + + +int +xfs_unicode_read_cft( + xfs_mount_t *mp) +{ + int error; + xfs_inode_t *cftip; + int size; + int nfsb; + int nmap; + xfs_bmbt_irec_t *mapp; + int n; + int byte_cnt; + xfs_buf_t *bp; + char *table; + xfs_dcft_t *dcft; + + if (mp->m_sb.sb_cftino == NULLFSINO || mp->m_sb.sb_cftino == 0) + return EINVAL; + error = xfs_iget(mp, NULL, mp->m_sb.sb_cftino, 0, 0, &cftip, 0); + if (error) + return error; + ASSERT(cftip != NULL); + + size = cftip->i_d.di_size; + nfsb = cftip->i_d.di_nblocks; + + table = vmalloc(size); + if (!table) { + xfs_iput(cftip, 0); + return ENOMEM; + } + dcft = (xfs_dcft_t *)table; + + nmap = nfsb; + mapp = kmem_alloc(nfsb * sizeof(xfs_bmbt_irec_t), KM_SLEEP); + + error = xfs_bmapi(NULL, cftip, 0, nfsb, 0, NULL, 0, mapp, &nmap, + NULL, NULL); + if (error) + goto out; + + for (n = 0; n < nmap; n++) { + byte_cnt = XFS_FSB_TO_B(mp, mapp[n].br_blockcount); + + bp = xfs_buf_read(mp->m_ddev_targp, + XFS_FSB_TO_DADDR(mp, mapp[n].br_startblock), + BTOBB(byte_cnt), 0); + error = XFS_BUF_GETERROR(bp); + if (error) + goto out; + + if (size < byte_cnt) + byte_cnt = size; + size -= byte_cnt; + memcpy(table, XFS_BUF_PTR(bp), byte_cnt); + table += byte_cnt; + xfs_buf_relse(bp); + } + + mp->m_cft = add_cft(dcft, cftip->i_d.di_size); + if (mp->m_cft == NULL) + error = ENOMEM; + +out: + xfs_iput(cftip, 0); + kmem_free(mapp, nfsb * sizeof(xfs_bmbt_irec_t)); + vfree(dcft); + + return error; +} + +void +xfs_unicode_free_cft( + const xfs_cft_t *cft) +{ + remove_cft(cft); +} + +void +xfs_unicode_init(void) +{ + mutex_init(&cft_lock); +} + +void +xfs_unicode_uninit(void) +{ + int i; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + ASSERT(cft_list[i].refcount == 0); + vfree(cft_list[i].table); + } + kmem_free(cft_list, cft_size * sizeof(struct cft_item)); + cft_size = 0; + cft_list = NULL; + + mutex_unlock(&cft_lock); +} =========================================================================== fs/xfs/xfs_unicode.h =========================================================================== --- a/fs/xfs/xfs_unicode.h 2006-06-17 00:58:24.000000000 +1000 +++ b/fs/xfs/xfs_unicode.h 2007-10-23 13:04:32.733676326 +1000 @@ -0,0 +1,75 @@ +/* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#ifndef __XFS_UNICODE_H__ +#define __XFS_UNICODE_H__ + +#define XFS_CFT_MAGIC 0x58434654 /* 'XCFT' */ +#define XFS_CFT_FLAG_TURKIC 0x00000001 + +/* + * Case Fold Table - on disk version. Must match the incore version below. + */ +typedef struct xfs_dcft { + __be32 magic; /* validity check */ + __be32 flags; + __be32 num_tables; /* single, double, etc */ + __be32 table_offset[1]; +} xfs_dcft_t; + +/* + * Case Fold Table - in core version. Must match the ondisk version above. + */ +typedef struct xfs_cft { + __uint32_t magic; + __uint32_t flags; + __uint32_t num_tables; /* single, double, etc */ + __uint32_t table_offset[1];/* num_tables sized */ + /* 16-bit array tables immediately follow */ +} xfs_cft_t; + +#define XFS_CFT_PTR(t,n) (__uint16_t *)(((char *)(t)) + \ + (t)->table_offset[n]) +#define XFS_DCFT_PTR(t,n) (__be16 *)(((char *)(t)) + \ + be32_to_cpu((t)->table_offset[n])) + +extern void xfs_unicode_init(void); +extern void xfs_unicode_uninit(void); + +extern __uint32_t xfs_unicode_hash(const xfs_cft_t *cft, + const uchar_t *name, int namelen); + +extern int xfs_unicode_casecmp(const xfs_cft_t *cft, const uchar_t *name1, + int len1, const uchar_t *name2, int len2); + +extern int xfs_nls_to_unicode(struct nls_table *nls, const char *nls_name, + int nls_namelen, char *uni_name, int uni_buflen); +extern int xfs_unicode_to_nls(struct nls_table *nls, const char *uni_name, + int uni_namelen, char *nls_name, int nls_buflen); + +extern __uint32_t xfs_nls_hash(struct nls_table *nls, const xfs_cft_t *cft, + const uchar_t *name, int namelen); +extern int xfs_nls_casecmp(struct nls_table *nls, const xfs_cft_t *cft, + const uchar_t *name1, int len1, + const uchar_t *name2, int len2); + +extern int xfs_unicode_validate(const uchar_t *name, int namelen); + +extern int xfs_unicode_read_cft(struct xfs_mount *mp); +extern void xfs_unicode_free_cft(const xfs_cft_t *cft); + +#endif /* __XFS_UNICODE_H__ */ =========================================================================== fs/xfs/xfs_vfsops.c =========================================================================== --- a/fs/xfs/xfs_vfsops.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_vfsops.c 2007-10-23 17:00:14.533732586 +1000 @@ -56,7 +56,7 @@ #include "xfs_fsops.h" #include "xfs_vnodeops.h" #include "xfs_vfsops.h" - +#include "xfs_unicode.h" int xfs_init(void) @@ -86,6 +86,7 @@ xfs_init(void) xfs_acl_zone_init(xfs_acl_zone, "xfs_acl"); xfs_mru_cache_init(); xfs_filestream_init(); + xfs_unicode_init(); /* * The size of the zone allocated buf log item is the maximum @@ -169,6 +170,7 @@ xfs_cleanup(void) xfs_cleanup_procfs(); xfs_sysctl_unregister(); xfs_refcache_destroy(); + xfs_unicode_uninit(); xfs_filestream_uninit(); xfs_mru_cache_uninit(); xfs_acl_zone_destroy(xfs_acl_zone); @@ -258,7 +260,6 @@ xfs_start_flags( mp->m_logname = kmem_alloc(strlen(ap->logname) + 1, KM_SLEEP); strcpy(mp->m_logname, ap->logname); } - if (ap->flags & XFSMNT_WSYNC) mp->m_flags |= XFS_MOUNT_WSYNC; #if XFS_BIG_INUMS @@ -415,6 +416,37 @@ xfs_finish_flags( mp->m_qflags |= XFS_OQUOTA_ENFD; } + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + if (ap->flags2 & XFSMNT2_CILOOKUP) + mp->m_flags |= XFS_MOUNT_CI_LOOKUP; + + mp->m_nls = ap->nls[0] ? load_nls(ap->nls) : load_nls_default(); + if (!mp->m_nls) { + cmn_err(CE_WARN, + "XFS: unable to load nls mapping \"%s\"\n", ap->nls); + return XFS_ERROR(EINVAL); + } + if (strcmp(mp->m_nls->charset, "utf8") == 0) { + /* special case utf8 - no translation required */ + unload_nls(mp->m_nls); + mp->m_nls = NULL; + } + } else { + /* + * Check for mount options which require a Unicode FS + */ + if (ap->flags2 & XFSMNT2_CILOOKUP) { + cmn_err(CE_WARN, + "XFS: can't do case-insensitive mount on non-utf8 filesystem"); + return XFS_ERROR(EINVAL); + + } + if (ap->nls[0]) { + cmn_err(CE_WARN, + "XFS: can't use nls mount option on non-utf8 filesystem"); + return XFS_ERROR(EINVAL); + } + } return 0; } @@ -652,6 +684,8 @@ out: xfs_unmountfs(mp, credp); xfs_qmops_put(mp); xfs_dmops_put(mp); + if (mp->m_nls) + unload_nls(mp->m_nls); kmem_free(mp, sizeof(xfs_mount_t)); } @@ -1505,6 +1539,9 @@ xfs_vget( #define MNTOPT_ATTR2 "attr2" /* do use attr2 attribute format */ #define MNTOPT_NOATTR2 "noattr2" /* do not use attr2 attribute format */ #define MNTOPT_FILESTREAM "filestreams" /* use filestreams allocator */ +#define MNTOPT_NLS "nls" /* NLS code page to use */ +#define MNTOPT_CILOOKUP "ci" /* case-insensitive lookup */ +#define MNTOPT_CIATTR "ciattr" /* case-insensitive attrs */ #define MNTOPT_QUOTA "quota" /* disk quotas (user) */ #define MNTOPT_NOQUOTA "noquota" /* no quotas */ #define MNTOPT_USRQUOTA "usrquota" /* user quota enabled */ @@ -1699,6 +1736,18 @@ xfs_parseargs( args->flags &= ~XFSMNT_ATTR2; } else if (!strcmp(this_char, MNTOPT_FILESTREAM)) { args->flags2 |= XFSMNT2_FILESTREAMS; + } else if (!strcmp(this_char, MNTOPT_NLS)) { + if (!value || !*value) { + cmn_err(CE_WARN, + "XFS: %s option requires an argument", + this_char); + return EINVAL; + } + strncpy(args->nls, value, MAXNAMELEN); + } else if (!strcmp(this_char, MNTOPT_CILOOKUP)) { + args->flags2 |= XFSMNT2_CILOOKUP; + } else if (!strcmp(this_char, MNTOPT_CIATTR)) { + args->flags2 |= XFSMNT2_CIATTR; } else if (!strcmp(this_char, MNTOPT_NOQUOTA)) { args->flags &= ~(XFSMNT_UQUOTAENF|XFSMNT_UQUOTA); args->flags &= ~(XFSMNT_GQUOTAENF|XFSMNT_GQUOTA); From owner-xfs@oss.sgi.com Tue Oct 23 03:01:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 03:01:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NA1JBA028613 for ; Tue, 23 Oct 2007 03:01:20 -0700 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from imp.csi.cam.ac.uk ([131.111.10.57]:49596) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpsa (PLAIN:aia21) (TLSv1:AES128-SHA:128) id 1IkGZT-0008S3-I6 (Exim 4.67) (return-path ); Tue, 23 Oct 2007 11:01:11 +0100 From: Anton Altaparmakov To: Barry Naujok In-Reply-To: Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS References: Message-Id: <30F0B02B-9857-43E8-89C0-E9C85EF081A2@cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 23 Oct 2007 11:01:11 +0100 Cc: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" X-Mailer: Apple Mail (2.912) X-Virus-Scanned: ClamAV 0.91.2/4572/Tue Oct 23 00:50:50 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13425 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aia21@cam.ac.uk Precedence: bulk X-list: xfs Hi, On 23 Oct 2007, at 08:53, Barry Naujok wrote: > Following is the initial test version of case-insensitive support > for XFS in Linux. It implements case-insensitivity utilising a > Unicode case folding table stored on disk generated from > http://www.unicode.org/Public/UNIDATA/CaseFolding.txt > > As the filesystem stores names as Unicode (UTF-8), the "nls" > mount option has been added to support systems not utilising > UTF-8 natively. If the nls mount option is not used, it will > use the default NLS defined in the kernel's config. > > To allow case-insensitivity to be a mount option rather than > a mkfs option, the hashes stored on disk are always case-folded. > This is indicated by the new "unicode" bit in the superblock. > This bit also associated with the presence of the case-folding > table on disk. > > With the case-folding table on disk, it allows us to upgrade > the table in the future while retaining backwards and forwards > compatibility. It also allows special case tables such as > Turkic case which is supported in this patch set. > > The case-insensitive support also installs a couple of > dentry_operations for the XFS inodes: hash and compare. > > Currently, there is a couple of outstanding issues with the > dentry cache interaction: > > - The first lookup if case-mismatched will continue to > have the mismatched case in the cache. Not really sure > if this is an issue or not. If it is an issue, how > should I resolve it? > > - As above, but with a non-existing lookup, then creating > the file with a different case, the first failed lookup > will define the case used. I have partially resolved > this with a memcpy if the two lengths are the same. > How do I fix this if the lengths are different? > (TODO's show the location of this problem.) Both of the above can be fairly easily fixed if you want. NTFS does it in the stock kernel. You would need to change the XFS ->lookup inode operation so that when it reads the directory to check whether a name exists, if it is found but the case is not matched, you need to make a copy of the correctly cased name (if NTFS this is done in fs/ntfs/ dir.c::ntfs_lookup_inode_by_name() if you want to take a look, the name is stored in the "ntfs_name" structure that is allocated during the lookup if a case mismatched match is found and this is returned to the caller). Then in ->lookup() if you got a correctly cased name structure (if the name was cased correctly the correctly cased named structure pointer would be NULL) then you need to replace the dentry passed into - >lookup with a new one with the correct case. This is a little complicated because such a dentry may already exist in which case you have to use the existing one (instantiating it if it was negative) and if it does not already exist you need to allocate a new one, instantiate it and then move it over the old one. Again a little complicated because of disconnected dentries for NFS. But it is not too bad and it works well in NTFS (see fs/ntfs/namei.c::ntfs_lookup() the code that does all of this starts at the "handle_name" goto label). Doing things this way means that you never have wrong case dentries in dcache. And this in turn means that things like handling ->unlink and ->rename inode operations is much easier as the dentry you receive there is returned from a ->lookup() call thus you know it is correctly cased already so you can do a case-sensitive match when looking up the directory entry to remove/rename! (I am afraid you cannot look at the NTFS code for that as that is not publicly available yet. )-:) Best regards, Anton > Other TODOs: > > - support for case-insensitve extended attributes > as a separate mount option. > > - Other xfsprogs updates: xfs_repair, xfs_db -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ From owner-xfs@oss.sgi.com Tue Oct 23 03:07:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 03:08:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NA7pRZ029482 for ; Tue, 23 Oct 2007 03:07:55 -0700 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from imp.csi.cam.ac.uk ([131.111.10.57]:49614) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpsa (PLAIN:aia21) (TLSv1:AES128-SHA:128) id 1IkGfs-0003Fs-GC (Exim 4.67) (return-path ); Tue, 23 Oct 2007 11:07:48 +0100 From: Anton Altaparmakov To: Barry Naujok In-Reply-To: <30F0B02B-9857-43E8-89C0-E9C85EF081A2@cam.ac.uk> Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS References: <30F0B02B-9857-43E8-89C0-E9C85EF081A2@cam.ac.uk> Message-Id: <7858EE76-E860-41C3-8AFC-CE67DF210081@cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 23 Oct 2007 11:07:47 +0100 Cc: xfs@oss.sgi.com, xfs-dev , linux-fsdevel@vger.kernel.org X-Mailer: Apple Mail (2.912) X-Virus-Scanned: ClamAV 0.91.2/4572/Tue Oct 23 00:50:50 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13426 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aia21@cam.ac.uk Precedence: bulk X-list: xfs I forgot to say: If you do what I did for NTFS you can also throw away your custom dentry operations that your patch adds as the dcache then only holds correctly cased names so you are fine to do case sensitive dcache lookups at all times. Access via wrongly cased name will always go to ->lookup inode operation and that is fine because such lookups almost never happen because majority of users will either use a GUI in which case all names are always correctly cased as the names displayed in the GUI are obtained from a ->readdir and thus show the correct case or they will use the command line in which case they will be savvy enough to use tab-completion in which case the names are correct case, too. Tab-completion does not work on wrongly cased names so you are very unlikely to ever get a wrongly cased name at all. And yes of course you can on purpose construct a test / benchmark where having to do the ->lookup each time will be really slow because you keep creating files and then accessing them by wrongly cased name on purpose (or whatever) but I would hope that you do not care about such artificial benchmarks that do not reflect any real-world loads... Best regards, Anton On 23 Oct 2007, at 11:01, Anton Altaparmakov wrote: > Hi, > > On 23 Oct 2007, at 08:53, Barry Naujok wrote: >> Following is the initial test version of case-insensitive support >> for XFS in Linux. It implements case-insensitivity utilising a >> Unicode case folding table stored on disk generated from >> http://www.unicode.org/Public/UNIDATA/CaseFolding.txt >> >> As the filesystem stores names as Unicode (UTF-8), the "nls" >> mount option has been added to support systems not utilising >> UTF-8 natively. If the nls mount option is not used, it will >> use the default NLS defined in the kernel's config. >> >> To allow case-insensitivity to be a mount option rather than >> a mkfs option, the hashes stored on disk are always case-folded. >> This is indicated by the new "unicode" bit in the superblock. >> This bit also associated with the presence of the case-folding >> table on disk. >> >> With the case-folding table on disk, it allows us to upgrade >> the table in the future while retaining backwards and forwards >> compatibility. It also allows special case tables such as >> Turkic case which is supported in this patch set. >> >> The case-insensitive support also installs a couple of >> dentry_operations for the XFS inodes: hash and compare. >> >> Currently, there is a couple of outstanding issues with the >> dentry cache interaction: >> >> - The first lookup if case-mismatched will continue to >> have the mismatched case in the cache. Not really sure >> if this is an issue or not. If it is an issue, how >> should I resolve it? >> >> - As above, but with a non-existing lookup, then creating >> the file with a different case, the first failed lookup >> will define the case used. I have partially resolved >> this with a memcpy if the two lengths are the same. >> How do I fix this if the lengths are different? >> (TODO's show the location of this problem.) > > Both of the above can be fairly easily fixed if you want. NTFS does > it in the stock kernel. > > You would need to change the XFS ->lookup inode operation so that > when it reads the directory to check whether a name exists, if it is > found but the case is not matched, you need to make a copy of the > correctly cased name (if NTFS this is done in fs/ntfs/ > dir.c::ntfs_lookup_inode_by_name() if you want to take a look, the > name is stored in the "ntfs_name" structure that is allocated during > the lookup if a case mismatched match is found and this is returned > to the caller). > > Then in ->lookup() if you got a correctly cased name structure (if > the name was cased correctly the correctly cased named structure > pointer would be NULL) then you need to replace the dentry passed > into ->lookup with a new one with the correct case. This is a > little complicated because such a dentry may already exist in which > case you have to use the existing one (instantiating it if it was > negative) and if it does not already exist you need to allocate a > new one, instantiate it and then move it over the old one. Again a > little complicated because of disconnected dentries for NFS. But it > is not too bad and it works well in NTFS (see fs/ntfs/ > namei.c::ntfs_lookup() the code that does all of this starts at the > "handle_name" goto label). > > Doing things this way means that you never have wrong case dentries > in dcache. And this in turn means that things like handling - > >unlink and ->rename inode operations is much easier as the dentry > you receive there is returned from a ->lookup() call thus you know > it is correctly cased already so you can do a case-sensitive match > when looking up the directory entry to remove/rename! (I am afraid > you cannot look at the NTFS code for that as that is not publicly > available yet. )-:) > > Best regards, > > Anton > >> Other TODOs: >> >> - support for case-insensitve extended attributes >> as a separate mount option. >> >> - Other xfsprogs updates: xfs_repair, xfs_db -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ From owner-xfs@oss.sgi.com Tue Oct 23 05:15:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 05:15:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_50,VBOUNCE_MESSAGE autolearn=no version=3.3.0-r574664 Received: from omr-m22.mx.aol.com (omr-m22.mx.aol.com [64.12.136.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NCFPSQ004510 for ; Tue, 23 Oct 2007 05:15:26 -0700 Received: from rly-dc04.mx.aol.com (rly-dc04.mx.aol.com [205.188.109.8]) by omr-m22.mx.aol.com (v117.7) with ESMTP id MAILOMRM223-7d9a471de5dd89; Tue, 23 Oct 2007 08:15:25 -0400 Received: from localhost (localhost) by rly-dc04.mx.aol.com (8.14.1/8.14.1) id l9NCFJBF004701; Tue, 23 Oct 2007 08:15:25 -0400 Date: Tue, 23 Oct 2007 08:15:25 -0400 From: Mail Delivery Subsystem Message-Id: <200710231215.l9NCFJBF004701@rly-dc04.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l9NCFJBF004701.1193141725/rly-dc04.mx.aol.com" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: smtp1.wanadoo.jo [193.252.22.182] rly-dc04 X-AOL-IP: 205.188.109.8 X-Virus-Scanned: ClamAV 0.91.2/4572/Tue Oct 23 00:50:50 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13427 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --l9NCFJBF004701.1193141725/rly-dc04.mx.aol.com The original message was received at Tue, 23 Oct 2007 08:15:04 -0400 from smtp1.wanadoo.jo [193.252.22.182] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-dc05.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --l9NCFJBF004701.1193141725/rly-dc04.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-dc04.mx.aol.com Arrival-Date: Tue, 23 Oct 2007 08:15:04 -0400 Final-Recipient: RFC822; okcomputer12@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-dc05.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Tue, 23 Oct 2007 08:15:25 -0400 --l9NCFJBF004701.1193141725/rly-dc04.mx.aol.com Content-Type: text/rfc822-headers Received: from mwinf4011.affiliated.me-wanadoo.net (smtp1.wanadoo.jo [193.252.22.182]) by rly-dc04.mx.aol.com (v119.12) with ESMTP id MAILRELAYINDC044-b18471de5c785; Tue, 23 Oct 2007 08:15:04 -0400 Received: from oss.sgi.com (unknown [86.108.116.185]) by mwinf4011.affiliated.me-wanadoo.net (SMTP Server) with ESMTP id 623381C00445 for ; Tue, 23 Oct 2007 14:14:57 +0200 (CEST) X-ME-UUID: 20071023121458402.623381C00445@mwinf4011.affiliated.me-wanadoo.net X-ME-bounce-domain: orange.jo From: xfs@oss.sgi.com To: okcomputer12@aol.com Subject: Mail System Error - Returned Mail Date: Tue, 23 Oct 2007 05:14:15 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_3E0333EA.8118F0D8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20071023121457.623381C00445@mwinf4011.affiliated.me-wanadoo.net> X-AOL-IP: 193.252.22.182 X-AOL-SCOLL-SCORE:0:2:464037312:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : --l9NCFJBF004701.1193141725/rly-dc04.mx.aol.com-- From owner-xfs@oss.sgi.com Tue Oct 23 05:55:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 05:55:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12, J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from rproxy.teamix.net (team.teamix.net [194.150.191.72]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NCtN7u010118 for ; Tue, 23 Oct 2007 05:55:26 -0700 Received: from mango.of.teamix.net (unknown [172.21.123.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by rproxy.teamix.net (Postfix) with ESMTP id C8C6947E6A for ; Tue, 23 Oct 2007 12:22:20 +0000 (UTC) From: Martin Steigerwald Organization: team(ix) GmbH To: xfs@oss.sgi.com Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS Date: Tue, 23 Oct 2007 14:22:21 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710231422.21637.ms@teamix.de> X-Virus-Scanned: ClamAV 0.91.2/4573/Tue Oct 23 05:01:01 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13428 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 Am Dienstag, 23. Oktober 2007 schrieb Barry Naujok: Hi Barry, > To allow case-insensitivity to be a mount option rather than > a mkfs option, the hashes stored on disk are always case-folded. > This is indicated by the new "unicode" bit in the superblock. > This bit also associated with the presence of the case-folding > table on disk. What would happen in the following scenario? mount -t xfs /dev/somedevice /mnt/tmp touch /mnt/tmp/testfile touch /mnt/tmp/Testfile touch /mnt/tmp/TESTFILE mount -t xfs -o remount,ci /dev/somedevice /mnt/tmp rm /mnt/tmp/testfile (I think I do not understand enough of XFS to read that myself out of your patch.) Ciao, -- 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 Tue Oct 23 13:45:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 13:45:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NKjNNf021121 for ; Tue, 23 Oct 2007 13:45:24 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IkQDY-000697-QC; Tue, 23 Oct 2007 21:19:12 +0100 Date: Tue, 23 Oct 2007 21:19:12 +0100 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Subject: Re: [RFC 1/2] Case-insensitive XFS - kernel patch Message-ID: <20071023201912.GA23558@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4574/Tue Oct 23 07:57:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13429 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 This patch is quite badly mangled by your mailer. Could you just attach it? (Or even better use a mailer that handles inlined text without mangling it..) From owner-xfs@oss.sgi.com Tue Oct 23 16:12:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 16:12:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9NNCY9O009127 for ; Tue, 23 Oct 2007 16:12:38 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l9NMpuGV086960; Tue, 23 Oct 2007 17:51:58 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <471E7B0C.7020804@thebarn.com> Date: Tue, 23 Oct 2007 17:51:56 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Donald Douwsma CC: Allan Hsu , xfs@oss.sgi.com Subject: Re: problems subscribing to this list. References: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> <471D7E55.9020103@sgi.com> In-Reply-To: <471D7E55.9020103@sgi.com> Content-Type: multipart/mixed; boundary="------------020508030604020100070608" X-Virus-Scanned: ClamAV 0.91.2/4577/Tue Oct 23 14:58:17 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4576/Tue Oct 23 15:40:23 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13430 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020508030604020100070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Donald Douwsma wrote: > Allan Hsu wrote: >> Sorry to spam the list with this, but I'm not sure who else to >> contact. I've been trying to subscribe to this list for a couple >> weeks, but I keep getting errors like this: >> >> List context changed to 'xfs' by following command. >> >>>> appsub xfs allan@counterpop.net 471CF171:4034.1:ksf >>>> >> Unable to process request due to filesystem error. >> >> --- >> Ecartis v1.0.0 - job execution complete. >> >> -Allan >> > > Hi Allan, > > I'll manually add you to the list while we try to figure this out. > > I cant see anything obvious is in the logs, and nothing filesystem > specific. > I suspect its an error specific to ecartis... > > _sigh_ > > Don > Ok so posting this to the list is a bit silly for new subscribers. As a reminder to existing list subscribers interesting in modifying their list status, the web interface is more reliable than the the email interface. http://oss.sgi.com/cgi-bin/lsg2.cgi -Russell --------------020508030604020100070608 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------020508030604020100070608-- From owner-xfs@oss.sgi.com Tue Oct 23 17:32:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 17:32:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_33, J_CHICKENPOX_42,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_51, J_CHICKENPOX_53,J_CHICKENPOX_61,J_CHICKENPOX_62,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9O0WHiM001577 for ; Tue, 23 Oct 2007 17:32:19 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA07413; Wed, 24 Oct 2007 10:32:09 +1000 To: "Christoph Hellwig" Subject: Re: [RFC 1/2] Case-insensitive XFS - kernel patch From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 References: <20071023201912.GA23558@infradead.org> Date: Wed, 24 Oct 2007 10:32:14 +1000 Message-ID: In-Reply-To: <20071023201912.GA23558@infradead.org> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4577/Tue Oct 23 14:58:17 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l9O0WNiM001586 X-archive-position: 13431 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 24 Oct 2007 06:19:12 +1000, Christoph Hellwig wrote: > This patch is quite badly mangled by your mailer. Could you just > attach it? (Or even better use a mailer that handles inlined text > without mangling it..) Found the setting at last. Here it is again... =========================================================================== fs/xfs/Makefile =========================================================================== --- a/fs/xfs/Makefile 2007-10-23 17:19:40.000000000 +1000 +++ b/fs/xfs/Makefile 2007-10-23 16:17:22.173903950 +1000 @@ -74,6 +74,7 @@ xfs-y += xfs_alloc.o \ xfs_trans_extfree.o \ xfs_trans_inode.o \ xfs_trans_item.o \ + xfs_unicode.o \ xfs_utils.o \ xfs_vfsops.o \ xfs_vnodeops.o \ =========================================================================== fs/xfs/linux-2.6/xfs_iops.c =========================================================================== --- a/fs/xfs/linux-2.6/xfs_iops.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_iops.c 2007-10-23 16:43:19.828562924 +1000 @@ -47,12 +47,17 @@ #include "xfs_buf_item.h" #include "xfs_utils.h" #include "xfs_vnodeops.h" +#include "xfs_da_btree.h" +#include "xfs_unicode.h" #include #include #include #include +struct dentry_operations xfs_dentry_operations; +struct dentry_operations xfs_nls_dentry_operations; + /* * Bring the atime in the XFS inode uptodate. * Used before logging the inode to disk or when the Linux inode goes away. @@ -369,10 +374,17 @@ xfs_vn_lookup( { bhv_vnode_t *cvp; int error; + struct xfs_mount *mp = XFS_I(dir)->i_mount; + struct dentry *result; if (dentry->d_name.len >= MAXNAMELEN) return ERR_PTR(-ENAMETOOLONG); + if (xfs_sb_version_hasunicode(&mp->m_sb) || + xfs_sb_version_hasoldci(&mp->m_sb)) + dentry->d_op = mp->m_nls ? &xfs_nls_dentry_operations : + &xfs_dentry_operations; + error = xfs_lookup(XFS_I(dir), dentry, &cvp); if (unlikely(error)) { if (unlikely(error != ENOENT)) @@ -381,7 +393,11 @@ xfs_vn_lookup( return NULL; } - return d_splice_alias(vn_to_inode(cvp), dentry); + result = d_splice_alias(vn_to_inode(cvp), dentry); + if (result) + result->d_op = dentry->d_op; + + return result; } STATIC int @@ -823,3 +839,74 @@ const struct inode_operations xfs_symlin .listxattr = xfs_vn_listxattr, .removexattr = xfs_vn_removexattr, }; + + +STATIC int +xfs_dentry_hash( + struct dentry *dir, + struct qstr *this) +{ + this->hash = xfs_dir_hashname(XFS_I(dir->d_inode), + this->name, this->len); + return 0; +} + +STATIC int +xfs_dentry_compare( + struct dentry *dir, + struct qstr *a, + struct qstr *b) +{ + int result = xfs_dir_compname(XFS_I(dir->d_inode), a->name, a->len, + b->name, b->len); + if (result == 0) { + if (a->len == b->len) + memcpy((unsigned char *)a->name, b->name, a->len); + else { + /* TODO: more complicated when name lengths differ */ + } + } + return result; +} + +STATIC int +xfs_nls_dentry_hash( + struct dentry *dir, + struct qstr *this) +{ + xfs_mount_t *mp = XFS_I(dir->d_inode)->i_mount; + + this->hash = xfs_nls_hash(mp->m_nls, mp->m_cft, this->name, this->len); + return 0; +} + +STATIC int +xfs_nls_dentry_compare( + struct dentry *dir, + struct qstr *a, + struct qstr *b) +{ + xfs_mount_t *mp = XFS_I(dir->d_inode)->i_mount; + int result = xfs_nls_casecmp(mp->m_nls, mp->m_cft, + a->name, a->len, b->name, b->len); + if (result == 0) { + if (a->len == b->len) + memcpy((unsigned char *)a->name, b->name, a->len); + else { + /* TODO: more complicated when name lengths differ */ + } + } + return result; +} + +struct dentry_operations xfs_dentry_operations = +{ + .d_hash = xfs_dentry_hash, + .d_compare = xfs_dentry_compare, +}; + +struct dentry_operations xfs_nls_dentry_operations = +{ + .d_hash = xfs_nls_dentry_hash, + .d_compare = xfs_nls_dentry_compare, +}; =========================================================================== fs/xfs/linux-2.6/xfs_linux.h =========================================================================== --- a/fs/xfs/linux-2.6/xfs_linux.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_linux.h 2007-10-10 15:16:26.698563845 +1000 @@ -75,6 +75,8 @@ #include #include #include +#include +#include #include #include =========================================================================== fs/xfs/linux-2.6/xfs_super.c =========================================================================== --- a/fs/xfs/linux-2.6/xfs_super.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/linux-2.6/xfs_super.c 2007-10-23 16:43:46.017187812 +1000 @@ -50,6 +50,7 @@ #include "xfs_vnodeops.h" #include "xfs_vfsops.h" #include "xfs_version.h" +#include "xfs_unicode.h" #include #include @@ -65,6 +66,9 @@ static kmem_zone_t *xfs_vnode_zone; static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; +extern struct dentry_operations xfs_dentry_operations; +extern struct dentry_operations xfs_nls_dentry_operations; + STATIC struct xfs_mount_args * xfs_args_allocate( struct super_block *sb, @@ -871,6 +875,10 @@ xfs_fs_fill_super( error = EINVAL; goto fail_vnrele; } + if (xfs_sb_version_hasunicode(&mp->m_sb) || + xfs_sb_version_hasoldci(&mp->m_sb)) + sb->s_root->d_op = mp->m_nls ? &xfs_nls_dentry_operations : + &xfs_dentry_operations; mp->m_sync_work.w_syncer = xfs_sync_worker; mp->m_sync_work.w_mount = mp; =========================================================================== fs/xfs/xfs_clnt.h =========================================================================== --- a/fs/xfs/xfs_clnt.h 2007-10-23 17:19:40.000000000 +1000 +++ b/fs/xfs/xfs_clnt.h 2007-10-12 17:07:03.022094920 +1000 @@ -48,6 +48,7 @@ struct xfs_mount_args { char rtname[MAXNAMELEN+1]; /* realtime device filename */ char logname[MAXNAMELEN+1]; /* journal device filename */ char mtpt[MAXNAMELEN+1]; /* filesystem mount point */ + char nls[MAXNAMELEN+1]; /* NLS code page to use */ int sunit; /* stripe unit (BBs) */ int swidth; /* stripe width (BBs), multiple of sunit */ uchar_t iosizelog; /* log2 of the preferred I/O size */ @@ -100,5 +101,9 @@ struct xfs_mount_args { * I/O size in stat(2) */ #define XFSMNT2_FILESTREAMS 0x00000002 /* enable the filestreams * allocator */ +#define XFSMNT2_CILOOKUP 0x00000004 /* enable case-insensitive + * filename lookup */ +#define XFSMNT2_CIATTR 0x00000008 /* enable case-insensitive + * extended attrs */ #endif /* __XFS_CLNT_H__ */ =========================================================================== fs/xfs/xfs_da_btree.c =========================================================================== --- a/fs/xfs/xfs_da_btree.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_da_btree.c 2007-10-22 17:09:31.333665254 +1000 @@ -1530,6 +1530,26 @@ xfs_da_hashname(const uchar_t *name, int } } + +xfs_dahash_t +xfs_default_hashname(xfs_inode_t *inode, const uchar_t *name, int namelen) +{ + return xfs_da_hashname(name, namelen); +} + +int +xfs_default_compname(xfs_inode_t *inode, const uchar_t *name1, int len1, + const uchar_t *name2, int len2) +{ + return (len1 == len2) ? memcmp(name1, name2, len1) : + (len1 < len2) ? -1 : 1; +} + +const struct xfs_nameops xfs_default_nameops = { + .hashname = xfs_default_hashname, + .compname = xfs_default_compname +}; + /* * Add a block to the btree ahead of the file. * Return the new block number to the caller. =========================================================================== fs/xfs/xfs_da_btree.h =========================================================================== --- a/fs/xfs/xfs_da_btree.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_da_btree.h 2007-10-23 16:19:40.083993281 +1000 @@ -208,6 +208,27 @@ typedef struct xfs_da_state { *========================================================================*/ /* + * Name ops for directory and/or attr name operations + */ + +typedef xfs_dahash_t (*xfs_hashname_t)(struct xfs_inode *, + const uchar_t *, int); +typedef int (*xfs_compname_t)(struct xfs_inode *, const uchar_t *, int, + const uchar_t *, int); + +typedef struct xfs_nameops { + xfs_hashname_t hashname; + xfs_compname_t compname; +} xfs_nameops_t; + +extern const struct xfs_nameops xfs_default_nameops; + +xfs_dahash_t xfs_default_hashname(struct xfs_inode *inode, const uchar_t *name, + int namelen); +int xfs_default_compname(struct xfs_inode *inode, const uchar_t *name1, + int len1, const uchar_t *name2, int len2); + +/* * Routines used for growing the Btree. */ int xfs_da_node_create(xfs_da_args_t *args, xfs_dablk_t blkno, int level, =========================================================================== fs/xfs/xfs_dir2.c =========================================================================== --- a/fs/xfs/xfs_dir2.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2.c 2007-10-23 16:42:40.857585216 +1000 @@ -42,9 +42,71 @@ #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" +static xfs_dahash_t +xfs_ascii_ci_hashname( + xfs_inode_t *inode, + const uchar_t *name, + int namelen) +{ + xfs_dahash_t hash; + int i; + + for (i = 0, hash = 0; i < namelen; i++) + hash = tolower(name[i]) ^ rol32(hash, 7); + + return hash; +} + +static int +xfs_ascii_ci_compname( + xfs_inode_t *inode, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + return (len1 == len2) ? strncasecmp(name1, name2, len1) : len1 - len2; +} + +static xfs_dahash_t +xfs_unicode_ci_hashname( + xfs_inode_t *inode, + const uchar_t *name, + int namelen) +{ + return xfs_unicode_hash(inode->i_mount->m_cft, name, namelen); +} -void +static int +xfs_unicode_ci_compname( + xfs_inode_t *inode, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + return xfs_unicode_casecmp(inode->i_mount->m_cft, + name1, len1, name2, len2); +} + +static const struct xfs_nameops xfs_ascii_ci_nameops = { + .hashname = xfs_ascii_ci_hashname, + .compname = xfs_ascii_ci_compname, +}; + +static const struct xfs_nameops xfs_unicode_nameops = { + .hashname = xfs_unicode_ci_hashname, + .compname = xfs_default_compname, +}; + +static const struct xfs_nameops xfs_unicode_ci_nameops = { + .hashname = xfs_unicode_ci_hashname, + .compname = xfs_unicode_ci_compname, +}; + +int xfs_dir_mount( xfs_mount_t *mp) { @@ -63,6 +125,15 @@ xfs_dir_mount( (mp->m_dirblksize - (uint)sizeof(xfs_da_node_hdr_t)) / (uint)sizeof(xfs_da_node_entry_t); mp->m_dir_magicpct = (mp->m_dirblksize * 37) / 100; + + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + mp->m_dirnameops = (mp->m_flags & XFS_MOUNT_CI_LOOKUP) ? + &xfs_unicode_ci_nameops : &xfs_unicode_nameops; + } else + mp->m_dirnameops = (xfs_sb_version_hasoldci(&mp->m_sb)) ? + &xfs_ascii_ci_nameops : &xfs_default_nameops; + + return 0; } /* @@ -139,6 +210,50 @@ xfs_dir_init( } /* + * Set up the args with appropriate name and hash value + */ + +static int +xfs_dir_setup_name_and_hash( + xfs_da_args_t *args, + const char *name, + int namelen) +{ + char *uname; + + if (args->dp->i_mount->m_nls) { + uname = kmem_alloc(MAXNAMELEN, KM_SLEEP); + args->namelen = xfs_nls_to_unicode(args->dp->i_mount->m_nls, + name, namelen, uname, MAXNAMELEN); + if (args->namelen < 0) { + kmem_free(uname, MAXNAMELEN); + return -args->namelen; + } + args->name = uname; + } else { + if (xfs_sb_version_hasunicode(&args->dp->i_mount->m_sb)) { + int rval; + rval = xfs_unicode_validate(name, namelen); + if (rval < 0) + return -rval; + } + args->name = name; + args->namelen = namelen; + } + args->hashval = xfs_dir_hashname(args->dp, args->name, args->namelen); + return 0; +} + +static inline void +xfs_dir_cleanup_name( + xfs_da_args_t *args, + const uchar_t *name) +{ + if (args->name != name) + kmem_free((void *)args->name, MAXNAMELEN); +} + +/* Enter a name in a directory. */ int @@ -161,9 +276,6 @@ xfs_dir_createname( return rval; XFS_STATS_INC(xs_dir_create); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = inum; args.dp = dp; args.firstblock = first; @@ -173,19 +285,24 @@ xfs_dir_createname( args.trans = tp; args.justcheck = 0; args.addname = args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_addname(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_addname(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_addname(&args); else rval = xfs_dir2_node_addname(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -207,9 +324,6 @@ xfs_dir_lookup( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_lookup); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = 0; args.dp = dp; args.firstblock = NULL; @@ -219,15 +333,18 @@ xfs_dir_lookup( args.trans = tp; args.justcheck = args.addname = 0; args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_lookup(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_lookup(&args); else @@ -236,6 +353,8 @@ xfs_dir_lookup( rval = 0; if (rval == 0) *inum = args.inumber; +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -260,9 +379,6 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = ino; args.dp = dp; args.firstblock = first; @@ -271,19 +387,24 @@ xfs_dir_removename( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 0; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_removename(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_removename(&args); else rval = xfs_dir2_node_removename(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -344,9 +465,6 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = inum; args.dp = dp; args.firstblock = first; @@ -355,19 +473,24 @@ xfs_dir_replace( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 0; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_replace(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_replace(&args); else rval = xfs_dir2_node_replace(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } @@ -387,9 +510,6 @@ xfs_dir_canenter( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); - args.name = name; - args.namelen = namelen; - args.hashval = xfs_da_hashname(name, namelen); args.inumber = 0; args.dp = dp; args.firstblock = NULL; @@ -398,19 +518,24 @@ xfs_dir_canenter( args.whichfork = XFS_DATA_FORK; args.trans = tp; args.justcheck = args.addname = args.oknoent = 1; + rval = xfs_dir_setup_name_and_hash(&args, name, namelen); + if (rval) + return rval; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_addname(&args); else if ((rval = xfs_dir2_isblock(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_block_addname(&args); else if ((rval = xfs_dir2_isleaf(tp, dp, &v))) - return rval; + goto out; else if (v) rval = xfs_dir2_leaf_addname(&args); else rval = xfs_dir2_node_addname(&args); +out: + xfs_dir_cleanup_name(&args, name); return rval; } =========================================================================== fs/xfs/xfs_dir2.h =========================================================================== --- a/fs/xfs/xfs_dir2.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2.h 2007-10-22 17:32:23.984399805 +1000 @@ -63,7 +63,7 @@ typedef xfs_off_t xfs_dir2_off_t; * Generic directory interface routines */ extern void xfs_dir_startup(void); -extern void xfs_dir_mount(struct xfs_mount *mp); +extern int xfs_dir_mount(struct xfs_mount *mp); extern int xfs_dir_isempty(struct xfs_inode *dp); extern int xfs_dir_init(struct xfs_trans *tp, struct xfs_inode *dp, struct xfs_inode *pdp); @@ -85,6 +85,13 @@ extern int xfs_dir_canenter(struct xfs_t char *name, int namelen); extern int xfs_dir_ino_validate(struct xfs_mount *mp, xfs_ino_t ino); +#define xfs_dir_hashname(dp, n, l) \ + ((dp)->i_mount->m_dirnameops->hashname((dp), (n), (l))) + +#define xfs_dir_compname(dp, n1, l1, n2, l2) \ + ((dp)->i_mount->m_dirnameops->compname((dp), (n1), (l1), \ + (n2), (l2))) + /* * Utility routines for v2 directories. */ =========================================================================== fs/xfs/xfs_dir2_block.c =========================================================================== --- a/fs/xfs/xfs_dir2_block.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_block.c 2007-10-15 16:57:13.164123893 +1000 @@ -38,6 +38,7 @@ #include "xfs_dir2_block.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" /* * Local function prototypes. @@ -450,6 +451,8 @@ xfs_dir2_block_getdents( int wantoff; /* starting block offset */ xfs_ino_t ino; xfs_off_t cook; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; mp = dp->i_mount; /* @@ -481,6 +484,9 @@ xfs_dir2_block_getdents( ptr = (char *)block->u; endptr = (char *)xfs_dir2_block_leaf_p(btp); + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Loop over the data portion of the block. * Each object is a real entry (dep) or an unused one (dup). @@ -513,17 +519,21 @@ xfs_dir2_block_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, dep->name, + dep->namelen, nls_name, MAXNAMELEN); /* * If it didn't fit, set the final offset to here & return. */ - if (filldir(dirent, dep->name, dep->namelen, cook, - ino, DT_UNKNOWN)) { + + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)dep->name, + nls_namelen > 0 ? nls_namelen : dep->namelen, + cook, ino, DT_UNKNOWN)) { *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (char *)dep - (char *)block); - xfs_da_brelse(NULL, bp); - return 0; + goto out; } } @@ -532,7 +542,10 @@ xfs_dir2_block_getdents( * Set the offset to a non-existent block 1 and return. */ *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); +out: xfs_da_brelse(NULL, bp); + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return 0; } @@ -701,9 +714,8 @@ xfs_dir2_block_lookup_int( /* * Compare, if it's right give back buffer & entry number. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, args->name, + args->namelen) == 0) { *bpp = bp; *entno = mid; return 0; @@ -1189,8 +1201,8 @@ xfs_dir2_sf_to_block( tagp = xfs_dir2_data_entry_tag_p(dep); *tagp = cpu_to_be16((char *)dep - (char *)block); xfs_dir2_data_log_entry(tp, bp, dep); - blp[2 + i].hashval = cpu_to_be32(xfs_da_hashname( - (char *)sfep->name, sfep->namelen)); + blp[2 + i].hashval = cpu_to_be32(xfs_dir_hashname(dp, + sfep->name, sfep->namelen)); blp[2 + i].address = cpu_to_be32(xfs_dir2_byte_to_dataptr(mp, (char *)dep - (char *)block)); offset = (int)((char *)(tagp + 1) - (char *)block); =========================================================================== fs/xfs/xfs_dir2_data.c =========================================================================== --- a/fs/xfs/xfs_dir2_data.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_data.c 2007-10-10 15:10:39.019079916 +1000 @@ -140,7 +140,8 @@ xfs_dir2_data_check( addr = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, (xfs_dir2_data_aoff_t) ((char *)dep - (char *)d)); - hash = xfs_da_hashname((char *)dep->name, dep->namelen); + hash = xfs_dir_hashname(dp, (char *)dep->name, + dep->namelen); for (i = 0; i < be32_to_cpu(btp->count); i++) { if (be32_to_cpu(lep[i].address) == addr && be32_to_cpu(lep[i].hashval) == hash) =========================================================================== fs/xfs/xfs_dir2_leaf.c =========================================================================== --- a/fs/xfs/xfs_dir2_leaf.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_leaf.c 2007-10-15 16:57:31.749743368 +1000 @@ -40,6 +40,7 @@ #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_unicode.h" /* * Local function declarations. @@ -780,6 +781,8 @@ xfs_dir2_leaf_getdents( int ra_offset; /* map entry offset for ra */ int ra_want; /* readahead count wanted */ xfs_ino_t ino; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; /* * If the offset is at or past the largest allowed value, @@ -800,6 +803,9 @@ xfs_dir2_leaf_getdents( map_valid = ra_index = ra_offset = ra_current = map_blocks = 0; bp = NULL; + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Inside the loop we keep the main offset value as a byte offset * in the directory file. @@ -1086,11 +1092,15 @@ xfs_dir2_leaf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, dep->name, + dep->namelen, nls_name, MAXNAMELEN); /* * Won't fit. Return to caller. */ - if (filldir(dirent, dep->name, dep->namelen, + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)dep->name, + nls_namelen > 0 ? nls_namelen : dep->namelen, xfs_dir2_byte_to_dataptr(mp, curoff + length), ino, DT_UNKNOWN)) break; @@ -1113,6 +1123,8 @@ xfs_dir2_leaf_getdents( kmem_free(map, map_size * sizeof(*map)); if (bp) xfs_da_brelse(NULL, bp); + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return error; } @@ -1392,9 +1404,8 @@ xfs_dir2_leaf_lookup_int( /* * If it matches then return it. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, args->name, + args->namelen) == 0) { *dbpp = dbp; *indexp = index; return 0; =========================================================================== fs/xfs/xfs_dir2_node.c =========================================================================== --- a/fs/xfs/xfs_dir2_node.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_node.c 2007-10-10 15:11:08.719279567 +1000 @@ -578,9 +578,8 @@ xfs_dir2_leafn_lookup_int( /* * Compare the entry, return it if it matches. */ - if (dep->namelen == args->namelen && - dep->name[0] == args->name[0] && - memcmp(dep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, dep->name, dep->namelen, + args->name, args->namelen) == 0) { args->inumber = be64_to_cpu(dep->inumber); *indexp = index; state->extravalid = 1; =========================================================================== fs/xfs/xfs_dir2_sf.c =========================================================================== --- a/fs/xfs/xfs_dir2_sf.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_dir2_sf.c 2007-10-18 14:03:09.916774315 +1000 @@ -38,6 +38,7 @@ #include "xfs_dir2_leaf.h" #include "xfs_dir2_block.h" #include "xfs_dir2_trace.h" +#include "xfs_unicode.h" /* * Prototypes for internal functions. @@ -708,6 +709,8 @@ xfs_dir2_sf_getdents( xfs_dir2_dataptr_t dot_offset; xfs_dir2_dataptr_t dotdot_offset; xfs_ino_t ino; + char *nls_name = NULL; /* NLS name buffer */ + int nls_namelen = 0; mp = dp->i_mount; @@ -774,6 +777,9 @@ xfs_dir2_sf_getdents( } } + if (mp->m_nls) + nls_name = kmem_alloc(MAXNAMELEN, KM_SLEEP); + /* * Loop while there are more entries and put'ing works. */ @@ -791,17 +797,22 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - - if (filldir(dirent, sfep->name, sfep->namelen, + if (mp->m_nls) + nls_namelen = xfs_unicode_to_nls(mp->m_nls, sfep->name, + sfep->namelen, nls_name, MAXNAMELEN); + if (filldir(dirent, nls_namelen > 0 ? nls_name : (char *)sfep->name, + nls_namelen > 0 ? nls_namelen : sfep->namelen, off + xfs_dir2_data_entsize(sfep->namelen), ino, DT_UNKNOWN)) { *offset = off; - return 0; + goto out; } sfep = xfs_dir2_sf_nextentry(sfp, sfep); } - *offset = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk + 1, 0); +out: + if (mp->m_nls) + kmem_free(nls_name, MAXNAMELEN); return 0; } @@ -855,9 +866,8 @@ xfs_dir2_sf_lookup( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(args->name, sfep->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, sfep->namelen, + args->name, args->namelen) == 0) { args->inumber = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); @@ -910,9 +920,8 @@ xfs_dir2_sf_removename( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(sfep->name, args->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, sfep->namelen, + args->name, args->namelen) == 0) { ASSERT(xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)) == args->inumber); @@ -1047,9 +1056,9 @@ xfs_dir2_sf_replace( for (i = 0, sfep = xfs_dir2_sf_firstentry(sfp); i < sfp->hdr.count; i++, sfep = xfs_dir2_sf_nextentry(sfp, sfep)) { - if (sfep->namelen == args->namelen && - sfep->name[0] == args->name[0] && - memcmp(args->name, sfep->name, args->namelen) == 0) { + if (xfs_dir_compname(dp, sfep->name, + sfep->namelen, args->name, + args->namelen) == 0) { #if XFS_BIG_INUMS || defined(DEBUG) ino = xfs_dir2_sf_get_inumber(sfp, xfs_dir2_sf_inumberp(sfep)); =========================================================================== fs/xfs/xfs_mount.c =========================================================================== --- a/fs/xfs/xfs_mount.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_mount.c 2007-10-23 16:36:16.371190339 +1000 @@ -43,6 +43,7 @@ #include "xfs_rw.h" #include "xfs_quota.h" #include "xfs_fsops.h" +#include "xfs_unicode.h" STATIC void xfs_mount_log_sbunit(xfs_mount_t *, __int64_t); STATIC int xfs_uuid_mount(xfs_mount_t *); @@ -119,6 +120,8 @@ static const struct { { offsetof(xfs_sb_t, sb_logsectsize),0 }, { offsetof(xfs_sb_t, sb_logsunit), 0 }, { offsetof(xfs_sb_t, sb_features2), 0 }, + { offsetof(xfs_sb_t, sb_reserved), 0 }, + { offsetof(xfs_sb_t, sb_cftino), 0 }, { sizeof(xfs_sb_t), 0 } }; @@ -171,6 +174,9 @@ xfs_mount_free( sizeof(xfs_perag_t) * mp->m_sb.sb_agcount); } + if (mp->m_cft) + xfs_unicode_free_cft(mp->m_cft); + spinlock_destroy(&mp->m_ail_lock); spinlock_destroy(&mp->m_sb_lock); mutex_destroy(&mp->m_ilock); @@ -455,6 +461,8 @@ xfs_sb_from_disk( to->sb_logsectsize = be16_to_cpu(from->sb_logsectsize); to->sb_logsunit = be32_to_cpu(from->sb_logsunit); to->sb_features2 = be32_to_cpu(from->sb_features2); + to->sb_bad_features2 = be32_to_cpu(from->sb_bad_features2); + to->sb_cftino = be64_to_cpu(from->sb_cftino); } /* @@ -1057,7 +1065,9 @@ xfs_mountfs( mp->m_dmevmask = 0; /* not persistent; set after each mount */ - xfs_dir_mount(mp); + error = xfs_dir_mount(mp); + if (error) + goto error1; /* * Initialize the attribute manager's entries. @@ -1165,6 +1175,17 @@ xfs_mountfs( } /* + * Load in unicode case folding table from disk + */ + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + error = xfs_unicode_read_cft(mp); + if (error) { + cmn_err(CE_WARN, "XFS: failed to read unicode table"); + goto error4; + } + } + + /* * If fs is not mounted readonly, then update the superblock * unit and width changes. */ @@ -1220,6 +1241,8 @@ xfs_mountfs( * Free up the root inode. */ VN_RELE(rvp); + if (mp->m_cft) + xfs_unicode_free_cft(mp->m_cft); error3: xfs_log_unmount_dealloc(mp); error2: =========================================================================== fs/xfs/xfs_mount.h =========================================================================== --- a/fs/xfs/xfs_mount.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_mount.h 2007-10-22 13:57:35.769401728 +1000 @@ -54,6 +54,7 @@ typedef struct xfs_trans_reservations { #else struct cred; struct log; +struct nls_table; struct xfs_mount_args; struct xfs_inode; struct xfs_bmbt_irec; @@ -61,6 +62,8 @@ struct xfs_bmap_free; struct xfs_extdelta; struct xfs_swapext; struct xfs_mru_cache; +struct xfs_nameops; +struct xfs_cft; /* * Prototypes and functions for the Data Migration subsystem. @@ -306,6 +309,9 @@ typedef struct xfs_mount { __uint8_t m_inode_quiesce;/* call quiesce on new inodes. field governed by m_ilock */ __uint8_t m_sectbb_log; /* sectlog - BBSHIFT */ + const struct xfs_nameops *m_dirnameops; /* vector of dir name ops */ + const struct xfs_cft *m_cft; /* unicode case fold table */ + struct nls_table *m_nls; /* active NLS table */ int m_dirblksize; /* directory block sz--bytes */ int m_dirblkfsbs; /* directory block sz--fsbs */ xfs_dablk_t m_dirdatablk; /* blockno of dir data v2 */ @@ -371,6 +377,8 @@ typedef struct xfs_mount { counters */ #define XFS_MOUNT_FILESTREAMS (1ULL << 24) /* enable the filestreams allocator */ +#define XFS_MOUNT_CI_LOOKUP (1ULL << 25) /* enable case-insensitive + * file lookup */ /* =========================================================================== fs/xfs/xfs_sb.h =========================================================================== --- a/fs/xfs/xfs_sb.h 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_sb.h 2007-10-23 16:55:47.440178601 +1000 @@ -46,10 +46,12 @@ struct xfs_mount; #define XFS_SB_VERSION_SECTORBIT 0x0800 #define XFS_SB_VERSION_EXTFLGBIT 0x1000 #define XFS_SB_VERSION_DIRV2BIT 0x2000 +#define XFS_SB_VERSION_OLDCIBIT 0x4000 #define XFS_SB_VERSION_MOREBITSBIT 0x8000 #define XFS_SB_VERSION_OKSASHFBITS \ (XFS_SB_VERSION_EXTFLGBIT | \ - XFS_SB_VERSION_DIRV2BIT) + XFS_SB_VERSION_DIRV2BIT | \ + XFS_SB_VERSION_OLDCIBIT) #define XFS_SB_VERSION_OKREALFBITS \ (XFS_SB_VERSION_ATTRBIT | \ XFS_SB_VERSION_NLINKBIT | \ @@ -77,10 +79,12 @@ struct xfs_mount; #define XFS_SB_VERSION2_LAZYSBCOUNTBIT 0x00000002 /* Superblk counters */ #define XFS_SB_VERSION2_RESERVED4BIT 0x00000004 #define XFS_SB_VERSION2_ATTR2BIT 0x00000008 /* Inline attr rework */ +#define XFS_SB_VERSION2_UNICODEBIT 0x00000020 /* Unicode names */ #define XFS_SB_VERSION2_OKREALFBITS \ (XFS_SB_VERSION2_LAZYSBCOUNTBIT | \ - XFS_SB_VERSION2_ATTR2BIT) + XFS_SB_VERSION2_ATTR2BIT | \ + XFS_SB_VERSION2_UNICODEBIT) #define XFS_SB_VERSION2_OKSASHFBITS \ (0) #define XFS_SB_VERSION2_OKREALBITS \ @@ -145,6 +149,9 @@ typedef struct xfs_sb { __uint16_t sb_logsectsize; /* sector size for the log, bytes */ __uint32_t sb_logsunit; /* stripe unit size for the log */ __uint32_t sb_features2; /* additional feature bits */ + __uint32_t sb_bad_features2; /* features2 could be here */ + xfs_ino_t sb_cftino; /* unicode case folding table inode */ + /* must be padded to 64 bit alignment */ } xfs_sb_t; /* @@ -205,6 +212,9 @@ typedef struct xfs_dsb { __be16 sb_logsectsize; /* sector size for the log, bytes */ __be32 sb_logsunit; /* stripe unit size for the log */ __be32 sb_features2; /* additional feature bits */ + __be32 sb_bad_features2; /* features2 could be here */ + __be64 sb_cftino; /* unicode case folding table inode */ + /* must be padded to 64 bit alignment */ } xfs_dsb_t; /* @@ -223,7 +233,7 @@ typedef enum { XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN, XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG, XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT, - XFS_SBS_FEATURES2, + XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2, XFS_SBS_CFTINO, XFS_SBS_FIELDCOUNT } xfs_sb_field_t; @@ -248,13 +258,15 @@ typedef enum { #define XFS_SB_IFREE XFS_SB_MVAL(IFREE) #define XFS_SB_FDBLOCKS XFS_SB_MVAL(FDBLOCKS) #define XFS_SB_FEATURES2 XFS_SB_MVAL(FEATURES2) +#define XFS_SB_CASEFOLDINO XFS_SB_MVAL(CASEFOLDINO) #define XFS_SB_NUM_BITS ((int)XFS_SBS_FIELDCOUNT) #define XFS_SB_ALL_BITS ((1LL << XFS_SB_NUM_BITS) - 1) #define XFS_SB_MOD_BITS \ (XFS_SB_UUID | XFS_SB_ROOTINO | XFS_SB_RBMINO | XFS_SB_RSUMINO | \ XFS_SB_VERSIONNUM | XFS_SB_UQUOTINO | XFS_SB_GQUOTINO | \ XFS_SB_QFLAGS | XFS_SB_SHARED_VN | XFS_SB_UNIT | XFS_SB_WIDTH | \ - XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2) + XFS_SB_ICOUNT | XFS_SB_IFREE | XFS_SB_FDBLOCKS | XFS_SB_FEATURES2 | \ + XFS_SB_CFTINO) /* @@ -463,6 +475,12 @@ static inline int xfs_sb_version_hassect ((sbp)->sb_versionnum & XFS_SB_VERSION_SECTORBIT); } +static inline int xfs_sb_version_hasoldci(xfs_sb_t *sbp) +{ + return (XFS_SB_VERSION_NUM(sbp) == XFS_SB_VERSION_4) && \ + ((sbp)->sb_versionnum & XFS_SB_VERSION_OLDCIBIT); +} + #define XFS_SB_VERSION_HASMOREBITS(sbp) xfs_sb_version_hasmorebits(sbp) static inline int xfs_sb_version_hasmorebits(xfs_sb_t *sbp) { @@ -502,6 +520,13 @@ static inline void xfs_sb_version_addatt ((sbp)->sb_features2 | XFS_SB_VERSION2_ATTR2BIT))); } +static inline int xfs_sb_version_hasunicode(xfs_sb_t *sbp) +{ + return (xfs_sb_version_hasmorebits(sbp) && \ + ((sbp)->sb_features2 & XFS_SB_VERSION2_UNICODEBIT)); +} + + /* * end of superblock version macros */ =========================================================================== fs/xfs/xfs_unicode.c =========================================================================== --- a/fs/xfs/xfs_unicode.c 2006-06-17 00:58:24.000000000 +1000 +++ b/fs/xfs/xfs_unicode.c 2007-10-23 16:17:02.336480442 +1000 @@ -0,0 +1,547 @@ +/* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "xfs.h" +#include "xfs_fs.h" +#include "xfs_bit.h" +#include "xfs_log.h" +#include "xfs_inum.h" +#include "xfs_clnt.h" +#include "xfs_trans.h" +#include "xfs_sb.h" +#include "xfs_ag.h" +#include "xfs_dir2.h" +#include "xfs_alloc.h" +#include "xfs_dmapi.h" +#include "xfs_mount.h" +#include "xfs_bmap_btree.h" +#include "xfs_alloc_btree.h" +#include "xfs_ialloc_btree.h" +#include "xfs_dir2_sf.h" +#include "xfs_attr_sf.h" +#include "xfs_dinode.h" +#include "xfs_inode.h" +#include "xfs_btree.h" +#include "xfs_ialloc.h" +#include "xfs_itable.h" +#include "xfs_rtalloc.h" +#include "xfs_error.h" +#include "xfs_bmap.h" +#include "xfs_unicode.h" + +#define MAX_FOLD_CHARS 4 + +static inline int +xfs_casefold( + const xfs_cft_t *cft, + __uint16_t c, + __uint16_t *fc) +{ + __uint16_t *table = XFS_CFT_PTR(cft, 0); + __uint16_t tmp = table[c >> 8]; + int i; + + if (!tmp) { + *fc = c; + return 1; + } + tmp = table[tmp + (c & 0xff)]; + if ((tmp & 0xf000) != 0xe000) { + *fc = tmp; + return 1; + } + i = ((tmp >> 10) & 0x3) + 2; + ASSERT(i < cft->num_tables); + table = XFS_CFT_PTR(cft, i - 1) + ((tmp & 0x3ff) * i); + + memcpy(fc, table, sizeof(__uint16_t) * i); + + return i; +} + +static inline int +xfs_utf8_casefold( + const xfs_cft_t *cft, + const uchar_t **name, + int *namelen, + __uint16_t *fc) +{ + wchar_t uc; + + if (*namelen == 0) + return 0; + + if (**name & 0x80) { + int n = utf8_mbtowc(&uc, *name, *namelen); + if (n < 0) { + (*namelen)--; + *fc = *(*name)++; + return 1; + } + *name += n; + *namelen -= n; + } else { + uc = *(*name)++; + (*namelen)--; + } + return xfs_casefold(cft, uc, fc); +} + +__uint32_t +xfs_unicode_hash( + const xfs_cft_t *cft, + const uchar_t *name, + int namelen) +{ + __uint32_t hash = 0; + __uint16_t fc[MAX_FOLD_CHARS]; + int nfc; + int i; + + while (namelen > 0) { + nfc = xfs_utf8_casefold(cft, &name, &namelen, fc); + for (i = 0; i < nfc; i++) + hash = fc[i] ^ rol32(hash, 7); + } + return hash; +} + +int +xfs_unicode_casecmp( + const xfs_cft_t *cft, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + __uint16_t fc1[MAX_FOLD_CHARS], fc2[MAX_FOLD_CHARS]; + __uint16_t *pfc1, *pfc2; + int nfc1, nfc2; + + nfc1 = xfs_utf8_casefold(cft, &name1, &len1, fc1); + pfc1 = fc1; + nfc2 = xfs_utf8_casefold(cft, &name2, &len2, fc2); + pfc2 = fc2; + + while (nfc1 > 0 && nfc2 > 0) { + if (*pfc1 != *pfc2) + return (*pfc1 < *pfc2) ? -1 : 1; + if (!--nfc1) { + nfc1 = xfs_utf8_casefold(cft, &name1, &len1, fc1); + pfc1 = fc1; + } else + pfc1++; + if (!--nfc2) { + nfc2 = xfs_utf8_casefold(cft, &name2, &len2, fc2); + pfc2 = fc2; + } else + pfc2++; + } + if (nfc1 != nfc2) + return (nfc1 < nfc2) ? -1 : 1; + return 0; +} + + +int +xfs_nls_to_unicode( + struct nls_table *nls, + const char *nls_name, + int nls_namelen, + char *uni_name, + int uni_buflen) +{ + int i, o; + wchar_t uc; + int nlen; + int u8len; + + if (!nls) { + if (uni_buflen < nls_namelen) + return -ENAMETOOLONG; + memcpy(uni_name, nls_name, nls_namelen); + return nls_namelen; + } + + for (i = 0, o = 0; i < nls_namelen; i += nlen, o += u8len) { + nlen = nls->char2uni(nls_name + i, nls_namelen - i, &uc); + if (nlen < 0) + return nlen; + if (uc >= 0xfffe || (uc >= 0xd800 && uc <= 0xdfff)) + return -EINVAL; /* don't support chars outside BMP */ + u8len = utf8_wctomb(uni_name + o, uc, uni_buflen - o); + if (u8len <= 0) + return (uni_buflen - o < 3) ? -ENAMETOOLONG : -EINVAL; + } + return o; +} + +int +xfs_unicode_to_nls( + struct nls_table *nls, + const char *uni_name, + int uni_namelen, + char *nls_name, + int nls_buflen) +{ + int i, o; + wchar_t uc; + int nlen; + int u8len; + + if (!nls) { + if (nls_buflen < uni_namelen) + return -ENAMETOOLONG; + memcpy(nls_name, uni_name, uni_namelen); + return uni_namelen; + } + + for (i = 0, o = 0; i < uni_namelen && o < nls_buflen; i += u8len, o += nlen) { + u8len = utf8_mbtowc(&uc, uni_name + i, uni_namelen - i); + if (u8len < 0) + return -EINVAL; + nlen = nls->uni2char(uc, nls_name + o, nls_buflen - o); + if (nlen == -EINVAL) { + nls_name[o] = '?'; + nlen = 1; + } else if (nlen < 0) + return nlen; + } + if (i < uni_namelen) + return -ENAMETOOLONG; + return o; +} + +static inline int +xfs_nls_casefold( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t **name, + int *namelen, + __uint16_t *fc) +{ + wchar_t uc; + + if (*namelen == 0) + return 0; + + if (**name & 0x80) { + int n = nls->char2uni(*name, *namelen, &uc); + if (n < 0) { + uc = *(*name)++; + (*namelen)--; + } else { + *name += n; + *namelen -= n; + } + } else { + uc = *(*name)++; + (*namelen)--; + } + return xfs_casefold(cft, uc, fc); +} + + +__uint32_t +xfs_nls_hash( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t *name, + int namelen) +{ + __uint32_t hash = 0; + __uint16_t fc[MAX_FOLD_CHARS]; + int i, nfc; + + while (namelen > 0) { + nfc = xfs_nls_casefold(nls, cft, &name, &namelen, fc); + for (i = 0; i < nfc; i++) + hash = fc[i] ^ rol32(hash, 7); + } + return hash; +} + +int +xfs_nls_casecmp( + struct nls_table *nls, + const xfs_cft_t *cft, + const uchar_t *name1, + int len1, + const uchar_t *name2, + int len2) +{ + __uint16_t fc1[MAX_FOLD_CHARS], fc2[MAX_FOLD_CHARS]; + __uint16_t *pfc1, *pfc2; + int nfc1, nfc2; + + nfc1 = xfs_nls_casefold(nls, cft, &name1, &len1, fc1); + pfc1 = fc1; + nfc2 = xfs_nls_casefold(nls, cft, &name2, &len2, fc2); + pfc2 = fc2; + + while (nfc1 > 0 && nfc2 > 0) { + if (*pfc1 != *pfc2) + return (*pfc1 < *pfc2) ? -1 : 1; + if (!--nfc1) { + nfc1 = xfs_nls_casefold(nls, cft, &name1, &len1, fc1); + pfc1 = fc1; + } else + pfc1++; + if (!--nfc2) { + nfc2 = xfs_nls_casefold(nls, cft, &name2, &len2, fc2); + pfc2 = fc2; + } else + pfc2++; + } + if (nfc1 != nfc2) + return (nfc1 < nfc2) ? -1 : 1; + return 0; + +} + +int +xfs_unicode_validate( + const uchar_t *name, + int namelen) +{ + wchar_t uc; + int i, nlen; + + for (i = 0; i < namelen; i += nlen) { + if (*name >= 0xf0) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "UTF-8 char beyond U+FFFF\n"); + return -EINVAL; + } + /* utf8_mbtowc must fail on overlong sequences too */ + nlen = utf8_mbtowc(&uc, name + i, namelen - i); + if (nlen < 0) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "invalid UTF-8 sequence\n"); + return -EILSEQ; + } + /* check for invalid/surrogate/private unicode chars */ + if (uc >= 0xfffe || (uc >= 0xd800 && uc <= 0xf8ff)) { + cmn_err(CE_WARN, "xfs_unicode_validate: " + "unsupported UTF-8 char\n"); + return -EINVAL; + } + } + return 0; +} + +/* + * Unicode Case Fold Table management + */ + +struct cft_item { + xfs_cft_t *table; + int size; + int refcount; +}; + +static mutex_t cft_lock; +static int cft_size; +static struct cft_item *cft_list; + +static xfs_cft_t * +add_cft( + xfs_dcft_t *dcft, + int size) +{ + int found = 0; + int i, j; + xfs_cft_t *cft; + __be16 *duc; + __uint16_t *uc; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + if (cft_list[i].size != size) + continue; + cft = cft_list[i].table; + if (cft->num_tables != be32_to_cpu(dcft->num_tables) || + cft->flags != be32_to_cpu(dcft->flags)) + continue; + found = 1; + for (j = 0; j < cft->num_tables; j++) { + if (cft->table_offset[j] != + be32_to_cpu(dcft->table_offset[j])) { + found = 0; + break; + } + } + if (found) { + cft_list[i].refcount++; + mutex_unlock(&cft_lock); + return cft; + } + } + + cft = vmalloc(size); + if (!cft) { + mutex_unlock(&cft_lock); + return NULL; + } + cft->magic = be32_to_cpu(dcft->magic); + cft->flags = be32_to_cpu(dcft->flags); + cft->num_tables = be32_to_cpu(dcft->num_tables); + ASSERT(cft->num_tables <= MAX_FOLD_CHARS); + for (i = 0; i < cft->num_tables; i++) + cft->table_offset[i] = be32_to_cpu(dcft->table_offset[i]); + j = (size - cft->table_offset[0]) / sizeof(__uint16_t); + uc = XFS_CFT_PTR(cft, 0); + duc = XFS_DCFT_PTR(dcft, 0); + for (i = 0; i < j; i++) + uc[i] = be16_to_cpu(duc[i]); + + cft_list = kmem_realloc(cft_list, + (cft_size + 1) * sizeof(struct cft_item), + cft_size * sizeof(struct cft_item), KM_SLEEP); + cft_list[cft_size].table = cft; + cft_list[cft_size].size = size; + cft_list[cft_size].refcount = 1; + cft_size++; + + mutex_unlock(&cft_lock); + + return cft; +} + +static void +remove_cft( + const xfs_cft_t *cft) +{ + int i; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + if (cft_list[i].table == cft) { + ASSERT(cft_list[i].refcount > 0); + cft_list[i].refcount--; + break; + } + } + + mutex_unlock(&cft_lock); +} + + +int +xfs_unicode_read_cft( + xfs_mount_t *mp) +{ + int error; + xfs_inode_t *cftip; + int size; + int nfsb; + int nmap; + xfs_bmbt_irec_t *mapp; + int n; + int byte_cnt; + xfs_buf_t *bp; + char *table; + xfs_dcft_t *dcft; + + if (mp->m_sb.sb_cftino == NULLFSINO || mp->m_sb.sb_cftino == 0) + return EINVAL; + error = xfs_iget(mp, NULL, mp->m_sb.sb_cftino, 0, 0, &cftip, 0); + if (error) + return error; + ASSERT(cftip != NULL); + + size = cftip->i_d.di_size; + nfsb = cftip->i_d.di_nblocks; + + table = vmalloc(size); + if (!table) { + xfs_iput(cftip, 0); + return ENOMEM; + } + dcft = (xfs_dcft_t *)table; + + nmap = nfsb; + mapp = kmem_alloc(nfsb * sizeof(xfs_bmbt_irec_t), KM_SLEEP); + + error = xfs_bmapi(NULL, cftip, 0, nfsb, 0, NULL, 0, mapp, &nmap, + NULL, NULL); + if (error) + goto out; + + for (n = 0; n < nmap; n++) { + byte_cnt = XFS_FSB_TO_B(mp, mapp[n].br_blockcount); + + bp = xfs_buf_read(mp->m_ddev_targp, + XFS_FSB_TO_DADDR(mp, mapp[n].br_startblock), + BTOBB(byte_cnt), 0); + error = XFS_BUF_GETERROR(bp); + if (error) + goto out; + + if (size < byte_cnt) + byte_cnt = size; + size -= byte_cnt; + memcpy(table, XFS_BUF_PTR(bp), byte_cnt); + table += byte_cnt; + xfs_buf_relse(bp); + } + + mp->m_cft = add_cft(dcft, cftip->i_d.di_size); + if (mp->m_cft == NULL) + error = ENOMEM; + +out: + xfs_iput(cftip, 0); + kmem_free(mapp, nfsb * sizeof(xfs_bmbt_irec_t)); + vfree(dcft); + + return error; +} + +void +xfs_unicode_free_cft( + const xfs_cft_t *cft) +{ + remove_cft(cft); +} + +void +xfs_unicode_init(void) +{ + mutex_init(&cft_lock); +} + +void +xfs_unicode_uninit(void) +{ + int i; + + mutex_lock(&cft_lock); + + for (i = 0; i < cft_size; i++) { + ASSERT(cft_list[i].refcount == 0); + vfree(cft_list[i].table); + } + kmem_free(cft_list, cft_size * sizeof(struct cft_item)); + cft_size = 0; + cft_list = NULL; + + mutex_unlock(&cft_lock); +} =========================================================================== fs/xfs/xfs_unicode.h =========================================================================== --- a/fs/xfs/xfs_unicode.h 2006-06-17 00:58:24.000000000 +1000 +++ b/fs/xfs/xfs_unicode.h 2007-10-23 13:04:32.733676326 +1000 @@ -0,0 +1,75 @@ +/* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#ifndef __XFS_UNICODE_H__ +#define __XFS_UNICODE_H__ + +#define XFS_CFT_MAGIC 0x58434654 /* 'XCFT' */ +#define XFS_CFT_FLAG_TURKIC 0x00000001 + +/* + * Case Fold Table - on disk version. Must match the incore version below. + */ +typedef struct xfs_dcft { + __be32 magic; /* validity check */ + __be32 flags; + __be32 num_tables; /* single, double, etc */ + __be32 table_offset[1]; +} xfs_dcft_t; + +/* + * Case Fold Table - in core version. Must match the ondisk version above. + */ +typedef struct xfs_cft { + __uint32_t magic; + __uint32_t flags; + __uint32_t num_tables; /* single, double, etc */ + __uint32_t table_offset[1];/* num_tables sized */ + /* 16-bit array tables immediately follow */ +} xfs_cft_t; + +#define XFS_CFT_PTR(t,n) (__uint16_t *)(((char *)(t)) + \ + (t)->table_offset[n]) +#define XFS_DCFT_PTR(t,n) (__be16 *)(((char *)(t)) + \ + be32_to_cpu((t)->table_offset[n])) + +extern void xfs_unicode_init(void); +extern void xfs_unicode_uninit(void); + +extern __uint32_t xfs_unicode_hash(const xfs_cft_t *cft, + const uchar_t *name, int namelen); + +extern int xfs_unicode_casecmp(const xfs_cft_t *cft, const uchar_t *name1, + int len1, const uchar_t *name2, int len2); + +extern int xfs_nls_to_unicode(struct nls_table *nls, const char *nls_name, + int nls_namelen, char *uni_name, int uni_buflen); +extern int xfs_unicode_to_nls(struct nls_table *nls, const char *uni_name, + int uni_namelen, char *nls_name, int nls_buflen); + +extern __uint32_t xfs_nls_hash(struct nls_table *nls, const xfs_cft_t *cft, + const uchar_t *name, int namelen); +extern int xfs_nls_casecmp(struct nls_table *nls, const xfs_cft_t *cft, + const uchar_t *name1, int len1, + const uchar_t *name2, int len2); + +extern int xfs_unicode_validate(const uchar_t *name, int namelen); + +extern int xfs_unicode_read_cft(struct xfs_mount *mp); +extern void xfs_unicode_free_cft(const xfs_cft_t *cft); + +#endif /* __XFS_UNICODE_H__ */ =========================================================================== fs/xfs/xfs_vfsops.c =========================================================================== --- a/fs/xfs/xfs_vfsops.c 2007-10-23 17:19:41.000000000 +1000 +++ b/fs/xfs/xfs_vfsops.c 2007-10-23 17:00:14.533732586 +1000 @@ -56,7 +56,7 @@ #include "xfs_fsops.h" #include "xfs_vnodeops.h" #include "xfs_vfsops.h" - +#include "xfs_unicode.h" int xfs_init(void) @@ -86,6 +86,7 @@ xfs_init(void) xfs_acl_zone_init(xfs_acl_zone, "xfs_acl"); xfs_mru_cache_init(); xfs_filestream_init(); + xfs_unicode_init(); /* * The size of the zone allocated buf log item is the maximum @@ -169,6 +170,7 @@ xfs_cleanup(void) xfs_cleanup_procfs(); xfs_sysctl_unregister(); xfs_refcache_destroy(); + xfs_unicode_uninit(); xfs_filestream_uninit(); xfs_mru_cache_uninit(); xfs_acl_zone_destroy(xfs_acl_zone); @@ -258,7 +260,6 @@ xfs_start_flags( mp->m_logname = kmem_alloc(strlen(ap->logname) + 1, KM_SLEEP); strcpy(mp->m_logname, ap->logname); } - if (ap->flags & XFSMNT_WSYNC) mp->m_flags |= XFS_MOUNT_WSYNC; #if XFS_BIG_INUMS @@ -415,6 +416,37 @@ xfs_finish_flags( mp->m_qflags |= XFS_OQUOTA_ENFD; } + if (xfs_sb_version_hasunicode(&mp->m_sb)) { + if (ap->flags2 & XFSMNT2_CILOOKUP) + mp->m_flags |= XFS_MOUNT_CI_LOOKUP; + + mp->m_nls = ap->nls[0] ? load_nls(ap->nls) : load_nls_default(); + if (!mp->m_nls) { + cmn_err(CE_WARN, + "XFS: unable to load nls mapping \"%s\"\n", ap->nls); + return XFS_ERROR(EINVAL); + } + if (strcmp(mp->m_nls->charset, "utf8") == 0) { + /* special case utf8 - no translation required */ + unload_nls(mp->m_nls); + mp->m_nls = NULL; + } + } else { + /* + * Check for mount options which require a Unicode FS + */ + if (ap->flags2 & XFSMNT2_CILOOKUP) { + cmn_err(CE_WARN, + "XFS: can't do case-insensitive mount on non-utf8 filesystem"); + return XFS_ERROR(EINVAL); + + } + if (ap->nls[0]) { + cmn_err(CE_WARN, + "XFS: can't use nls mount option on non-utf8 filesystem"); + return XFS_ERROR(EINVAL); + } + } return 0; } @@ -652,6 +684,8 @@ out: xfs_unmountfs(mp, credp); xfs_qmops_put(mp); xfs_dmops_put(mp); + if (mp->m_nls) + unload_nls(mp->m_nls); kmem_free(mp, sizeof(xfs_mount_t)); } @@ -1505,6 +1539,9 @@ xfs_vget( #define MNTOPT_ATTR2 "attr2" /* do use attr2 attribute format */ #define MNTOPT_NOATTR2 "noattr2" /* do not use attr2 attribute format */ #define MNTOPT_FILESTREAM "filestreams" /* use filestreams allocator */ +#define MNTOPT_NLS "nls" /* NLS code page to use */ +#define MNTOPT_CILOOKUP "ci" /* case-insensitive lookup */ +#define MNTOPT_CIATTR "ciattr" /* case-insensitive attrs */ #define MNTOPT_QUOTA "quota" /* disk quotas (user) */ #define MNTOPT_NOQUOTA "noquota" /* no quotas */ #define MNTOPT_USRQUOTA "usrquota" /* user quota enabled */ @@ -1699,6 +1736,18 @@ xfs_parseargs( args->flags &= ~XFSMNT_ATTR2; } else if (!strcmp(this_char, MNTOPT_FILESTREAM)) { args->flags2 |= XFSMNT2_FILESTREAMS; + } else if (!strcmp(this_char, MNTOPT_NLS)) { + if (!value || !*value) { + cmn_err(CE_WARN, + "XFS: %s option requires an argument", + this_char); + return EINVAL; + } + strncpy(args->nls, value, MAXNAMELEN); + } else if (!strcmp(this_char, MNTOPT_CILOOKUP)) { + args->flags2 |= XFSMNT2_CILOOKUP; + } else if (!strcmp(this_char, MNTOPT_CIATTR)) { + args->flags2 |= XFSMNT2_CIATTR; } else if (!strcmp(this_char, MNTOPT_NOQUOTA)) { args->flags &= ~(XFSMNT_UQUOTAENF|XFSMNT_UQUOTA); args->flags &= ~(XFSMNT_GQUOTAENF|XFSMNT_GQUOTA); From owner-xfs@oss.sgi.com Tue Oct 23 17:34:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 17:34:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9O0YAEZ001938 for ; Tue, 23 Oct 2007 17:34:12 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 KAA07493; Wed, 24 Oct 2007 10:34:09 +1000 Date: Wed, 24 Oct 2007 10:34:15 +1000 To: "Martin Steigerwald" , xfs@oss.sgi.com Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS From: "Barry Naujok" Organization: SGI Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 References: <200710231422.21637.ms@teamix.de> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200710231422.21637.ms@teamix.de> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4577/Tue Oct 23 14:58:17 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13432 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 23 Oct 2007 22:22:21 +1000, Martin Steigerwald wrote: > Am Dienstag, 23. Oktober 2007 schrieb Barry Naujok: > > Hi Barry, > >> To allow case-insensitivity to be a mount option rather than >> a mkfs option, the hashes stored on disk are always case-folded. >> This is indicated by the new "unicode" bit in the superblock. >> This bit also associated with the presence of the case-folding >> table on disk. > > What would happen in the following scenario? > > mount -t xfs /dev/somedevice /mnt/tmp > touch /mnt/tmp/testfile > touch /mnt/tmp/Testfile > touch /mnt/tmp/TESTFILE > > mount -t xfs -o remount,ci /dev/somedevice /mnt/tmp > rm /mnt/tmp/testfile testfile would be deleted, Testfile and TESTFILE will remain. Subsequent rm's should remove the rest. From owner-xfs@oss.sgi.com Tue Oct 23 18:01:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 23 Oct 2007 18:01:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.3.0-r574664 Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9O11lXv005381 for ; Tue, 23 Oct 2007 18:01:49 -0700 Received: from filer.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id l9O0b6EI003929; Tue, 23 Oct 2007 20:37:06 -0400 Received: (from jsipek@localhost) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1/Submit) id l9O0b64W003926; Tue, 23 Oct 2007 20:37:06 -0400 X-Authentication-Warning: filer.fsl.cs.sunysb.edu: jsipek set sender to jsipek@fsl.cs.sunysb.edu using -f Date: Tue, 23 Oct 2007 20:37:06 -0400 From: Josef Sipek To: Anton A Vorobev Cc: xfs@oss.sgi.com Subject: Re: Slow seek in kernels >= 2.6.18 Message-ID: <20071024003706.GA27516@filer.fsl.cs.sunysb.edu> References: <4717156C.3030308@firma.seznam.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4717156C.3030308@firma.seznam.cz> User-Agent: Mutt/1.5.16 (2007-07-16) X-Virus-Scanned: ClamAV 0.91.2/4580/Tue Oct 23 16:55:29 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13433 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jsipek@fsl.cs.sunysb.edu Precedence: bulk X-list: xfs On Thu, Oct 18, 2007 at 10:12:28AM +0200, Anton A Vorobev wrote: > Hi! > > A question. We've got an application that runs about 30-40 minutes. After > kernel upgrade from 2.6.17 branch, it runs about 3 hours. > I've made tests with the help of bonnie++, it shows that random seek > operations are about 3 times slower in kernels newer than 2.6.18 in > comparison with 2.6.17. This difference may be seen only during high load > of a server. When it is in normal state, parameters are rather the same. I think that's about when the defaults for few /proc/sys/vm/ vars changed. One from 10 to 5, and another from 40 to 10. I forget the exact filenames. Josef 'Jeff' Sipek. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) From owner-xfs@oss.sgi.com Wed Oct 24 00:38:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 00:38:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9O7cFYi027757 for ; Wed, 24 Oct 2007 00:38:17 -0700 Received: from pc-bnaujok.melbourne.sgi.com (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 RAA17821; Wed, 24 Oct 2007 17:38:08 +1000 Date: Wed, 24 Oct 2007 17:39:55 +1000 To: "Anton Altaparmakov" Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com, xfs-dev , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 References: <30F0B02B-9857-43E8-89C0-E9C85EF081A2@cam.ac.uk> <7858EE76-E860-41C3-8AFC-CE67DF210081@cam.ac.uk> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <7858EE76-E860-41C3-8AFC-CE67DF210081@cam.ac.uk> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/4585/Tue Oct 23 23:24:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13434 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Hi Anton, On Tue, 23 Oct 2007 20:07:47 +1000, Anton Altaparmakov wrote: > I forgot to say: If you do what I did for NTFS you can also throw > away your custom dentry operations that your patch adds as the dcache > then only holds correctly cased names so you are fine to do case > sensitive dcache lookups at all times. Access via wrongly cased name > will always go to ->lookup inode operation and that is fine because > such lookups almost never happen because majority of users will either > use a GUI in which case all names are always correctly cased as the > names displayed in the GUI are obtained from a ->readdir and thus show > the correct case or they will use the command line in which case they > will be savvy enough to use tab-completion in which case the names are > correct case, too. Tab-completion does not work on wrongly cased > names so you are very unlikely to ever get a wrongly cased name at all. > > And yes of course you can on purpose construct a test / benchmark > where having to do the ->lookup each time will be really slow because > you keep creating files and then accessing them by wrongly cased name > on purpose (or whatever) but I would hope that you do not care about > such artificial benchmarks that do not reflect any real-world loads... I have been looking at ntfs_lookup() and seeing how it does its stuff. It seems that is the best way to go. One thing I have noticed is with two or more attempted case-insensitive lookups that don't exist yet case match the same (ie. ntfs_lookup_inode_by_name() fails with -ENOENT), d_add(dent, NULL) is called, populating the dentry with effective duplicates. Eg: # cat /mnt/foo/fileNOTexist # cat /mnt/foo/FILEnotEXIST Will have two negative dentries, am I correct? Regards, Barry. From owner-xfs@oss.sgi.com Wed Oct 24 01:03:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 01:03:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9O83bMU031552 for ; Wed, 24 Oct 2007 01:03:38 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Ikan9-0008Sq-AP; Wed, 24 Oct 2007 08:36:39 +0100 Date: Wed, 24 Oct 2007 08:36:39 +0100 From: Christoph Hellwig To: Barry Naujok Cc: Christoph Hellwig , "xfs@oss.sgi.com" , xfs-dev , "linux-fsdevel@vger.kernel.org" Subject: Re: [RFC 1/2] Case-insensitive XFS - kernel patch Message-ID: <20071024073639.GA32469@infradead.org> References: <20071023201912.GA23558@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4585/Tue Oct 23 23:24:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13435 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 On Wed, Oct 24, 2007 at 10:32:14AM +1000, Barry Naujok wrote: > On Wed, 24 Oct 2007 06:19:12 +1000, Christoph Hellwig wrote: > > > This patch is quite badly mangled by your mailer. Could you just > > attach it? (Or even better use a mailer that handles inlined text It's still mangled, e.g. > #include "xfs_vnodeops.h" > +#include "xfs_da_btree.h" > +#include "xfs_unicode.h" The # should be lined up, with only one character (' ', '+' or '-') before them. No idea what the mailer does here. From owner-xfs@oss.sgi.com Wed Oct 24 01:19:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 01:19:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9O8JQoj001899 for ; Wed, 24 Oct 2007 01:19:29 -0700 Received: by fk-out-0910.google.com with SMTP id 18so105580fks for ; Wed, 24 Oct 2007 01:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=v2i7kCdjjhFlm4Dtr1Ovrskyu44PzVPQtAS6IBZ/1Hg=; b=PtPi3jgYfqFhKNOEcI5lU//Td8lcNpAzygg+CodFQd/JEAc4bAJJ8+1WLxcVgB34pkYK8T04SvzhyK609XiKtrDyxWv00w8aa+Rl7qgSBCuj0af2u4wnSQtj1tUQMTij70i4LXkOjQgzz10T2w3ZnAGIz+FRTmuQ4E+QTFpDqwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=jMESVbhBew/KgR8Hf5miH3ffK1tdf+JQkOPJ+OPk+aBvHkHIgoUyfJLUiil4afJMSoNBdunJY1aS4A5BoP/+WbI2jOwd2Jp7IlL49AHaWGlSVGpdrFkCHGbSEP0AKrHGPzxLfgL+BIVCLyY6/4++/4/iYeW59ycsg0F7eBIfYQo= Received: by 10.82.170.2 with SMTP id s2mr760443bue.1193212404250; Wed, 24 Oct 2007 00:53:24 -0700 (PDT) Received: from petole.dyndns.org ( [62.34.16.56]) by mx.google.com with ESMTPS id y2sm908261mug.2007.10.24.00.53.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2007 00:53:23 -0700 (PDT) Date: Wed, 24 Oct 2007 09:53:20 +0200 From: Nicolas KOWALSKI To: xfs@oss.sgi.com Subject: Re: problems subscribing to this list. Message-ID: <20071024075320.GX31811@petole.dyndns.org> Mail-Followup-To: xfs@oss.sgi.com References: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> <471D7E55.9020103@sgi.com> <471E7B0C.7020804@thebarn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471E7B0C.7020804@thebarn.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Scanned: ClamAV 0.91.2/4585/Tue Oct 23 23:24:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13436 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nicolas.kowalski@gmail.com Precedence: bulk X-list: xfs On Tue, Oct 23, 2007 at 05:51:56PM -0500, Russell Cattelan wrote: > Ok so posting this to the list is a bit silly for new subscribers. As > a reminder to existing list subscribers interesting in modifying their > list status, the web interface is more reliable than the the email > interface. > > http://oss.sgi.com/cgi-bin/lsg2.cgi Thanks for the link. Maybe it should be mentionned in the mailing-list page for easier access? http://oss.sgi.com/projects/xfs/mail.html Thanks, -- Nicolas From owner-xfs@oss.sgi.com Wed Oct 24 01:32:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 01:32:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_12, J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from rproxy.teamix.net (team.teamix.net [194.150.191.72]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9O8WPCg003453 for ; Wed, 24 Oct 2007 01:32:28 -0700 Received: from mango.of.teamix.net (unknown [172.21.123.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by rproxy.teamix.net (Postfix) with ESMTP id BD17A47E38; Wed, 24 Oct 2007 08:32:21 +0000 (UTC) From: Martin Steigerwald Organization: team(ix) GmbH To: xfs@oss.sgi.com Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS Date: Wed, 24 Oct 2007 10:32:21 +0200 User-Agent: KMail/1.9.7 Cc: "Barry Naujok" References: <200710231422.21637.ms@teamix.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710241032.22157.ms@teamix.de> X-Virus-Scanned: ClamAV 0.91.2/4585/Tue Oct 23 23:24:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13437 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 Am Mittwoch, 24. Oktober 2007 schrieb Barry Naujok: > On Tue, 23 Oct 2007 22:22:21 +1000, Martin Steigerwald wrote: > > What would happen in the following scenario? > > > > mount -t xfs /dev/somedevice /mnt/tmp > > touch /mnt/tmp/testfile > > touch /mnt/tmp/Testfile > > touch /mnt/tmp/TESTFILE > > > > mount -t xfs -o remount,ci /dev/somedevice /mnt/tmp > > rm /mnt/tmp/testfile > > testfile would be deleted, Testfile and TESTFILE will remain. > Subsequent rm's should remove the rest. Sounds indeed quite clever to me ;-) I look forward to that feature which could be interesting for samba file shares cause samba would not have to map case-insensitive paths from Windows to the case-sensitive paths under Linux anymore. -- 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 Oct 24 02:03:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 02:03:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_56, J_CHICKENPOX_72,MIME_8BIT_HEADER,RDNS_DYNAMIC autolearn=no version=3.3.0-r574664 Received: from zeus.office.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9O93R83007035 for ; Wed, 24 Oct 2007 02:03:29 -0700 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by zeus.office.navi.pl (8.13.1/8.13.1) with ESMTP id l9O8fOx7008229; Wed, 24 Oct 2007 10:41:24 +0200 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id l9O8fUY3012834; Wed, 24 Oct 2007 10:41:31 +0200 Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Barry Naujok Cc: Martin Steigerwald , xfs@oss.sgi.com In-Reply-To: References: <200710231422.21637.ms@teamix.de> Content-Type: text/plain; charset=UTF-8 Date: Wed, 24 Oct 2007 10:41:30 +0200 Message-Id: <1193215290.12133.16.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/4586/Wed Oct 24 01:13:13 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13438 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs On Wed, 2007-10-24 at 10:34 +1000, Barry Naujok wrote: > On Tue, 23 Oct 2007 22:22:21 +1000, Martin Steigerwald wrote: > > > Am Dienstag, 23. Oktober 2007 schrieb Barry Naujok: > > > > Hi Barry, > > > >> To allow case-insensitivity to be a mount option rather than > >> a mkfs option, the hashes stored on disk are always case-folded. > >> This is indicated by the new "unicode" bit in the superblock. > >> This bit also associated with the presence of the case-folding > >> table on disk. > > > > What would happen in the following scenario? > > > > mount -t xfs /dev/somedevice /mnt/tmp > > touch /mnt/tmp/testfile > > touch /mnt/tmp/Testfile > > touch /mnt/tmp/TESTFILE > > > > mount -t xfs -o remount,ci /dev/somedevice /mnt/tmp > > rm /mnt/tmp/testfile > > testfile would be deleted, Testfile and TESTFILE will remain. > Subsequent rm's should remove the rest. Or maybe testfile and Testfile will remain? If it is mounted as ci you have no idea which one will be deleted. IMO having this as mount option is broken by design. If you do it as mkfs option then you avoid most of ugly problems. 1. What if you have the following code in your program if (exists lala){ error=remove lala if(error) die if(!error) error=create lala if(error) die } the create will fail, and it is clearly not expected behaviour. 2. What will ls show: Test.txt test.txt TeSt.txt when mount as ci? 3. Which one will be removed if you do rm on ci mounted filesystem? 4. If it were mkfs option you could avoid expensive filename lookups. Just store all files in lowercase and on lookup convert the argument to lowercase. If you want to preserve case you could use eg. file attribute to store filename with case preserved. Regards, Olaf FrÄ…czyk -- Olaf FrÄ…czyk From owner-xfs@oss.sgi.com Wed Oct 24 06:22:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 06:22:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_05,J_CHICKENPOX_43, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9ODMSua009661 for ; Wed, 24 Oct 2007 06:22:30 -0700 Received: from joyride2 ([10.152.4.58] [10.152.4.58]) by mailout.lrz-muenchen.de for xfs@oss.sgi.com; Wed, 24 Oct 2007 13:05:18 +0200 From: =?iso-8859-1?Q?Bernd_M=FCller-Rathgeber?= To: Subject: XFA on LVM and MD Raid Date: Wed, 24 Oct 2007 13:05:18 +0200 Message-Id: <001a01c8162d$c3531300$49f93900$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgWLcM6M9BuGl6eR82TId7oiVP7jg== Content-Language: de X-Virus-Scanned: ClamAV 0.91.2/4589/Wed Oct 24 02:55:55 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l9ODMVua009666 X-archive-position: 13439 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mueller-rathgeber@tum.de Precedence: bulk X-list: xfs Hello. I have major stability problems with my xfs-Filesystem. I´m using it for User-Data. My setup are 5 md-Softwareraid partitions on 2 disks sda and sdb. Combined with an lvm group. And there a bunch of logical volumes with xfs. Using xfsprogs 2.9.4 from Debian and an Linux 2.6.12.6-arm1 #32 Tue Jan 23 17:11:52 CST 2007 armv5tejl GNU/Linux. I can´t even make a new xfs partition! Is it really possible to use xfs on top of lvm on top of md? Greetings Bernd bmr-nas:/home# lvcreate -n rsync -L 5G vg0 Logical volume "rsync" created bmr-nas:/home# mkfs.xfs /dev/vg0/rsync meta-data=/dev/vg0/rsync isize=256 agcount=8, agsize=163840 blks = sectsz=512 attr=0 data = bsize=4096 blocks=1310720, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 bmr-nas:/home# xfs_check /dev/vg0/rsync cache_node_purge: refcount was 1, not zero (node=0xb0a08) xfs_check: cannot read root inode (22) bad sb version # 0x8430 in ag 0 agf_freeblks 163832, counted 163828 in ag 0 agf_longest 163832, counted 163828 in ag 0 agi_count 64, counted 0 in ag 0 agi_freecount 61, counted 0 in ag 0 block 5/4 expected type free1 got freelist block 5/5 expected type free1 got freelist block 5/6 expected type free1 got freelist block 5/7 expected type free1 got freelist agf_freeblks 163832, counted 163836 in ag 5 agf_longest 163832, counted 163836 in ag 5 block 6/4 expected type unknown got freelist block 6/5 expected type unknown got freelist block 6/6 expected type unknown got freelist block 6/7 expected type unknown got freelist block 7/4 expected type unknown got freelist block 7/5 expected type unknown got freelist block 7/6 expected type unknown got freelist block 7/7 expected type unknown got freelist root inode 128 is missing block 0/8 type unknown not expected block 0/9 type unknown not expected block 0/10 type unknown not expected block 0/11 type unknown not expected block 6/4 type free1 not expected block 6/5 type free1 not expected block 6/6 type free1 not expected block 6/7 type free1 not expected block 7/4 type free1 not expected block 7/5 type free1 not expected block 7/6 type free1 not expected block 7/7 type free1 not expected sb_icount 4611686018427387904, counted 0 sb_ifree 64, counted 0 sb_fdblocks 1308124, counted 1308128 bmr-nas:~# xfs_repair /dev/vg0/rsync Phase 1 - find and verify superblock... bad primary superblock - bad version number !!! attempting to find secondary superblock... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ .................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................found candidate secondary superblock... unable to verify superblock, continuing... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ................................Sorry, could not find valid secondary superblock Exiting now. From owner-xfs@oss.sgi.com Wed Oct 24 08:06:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 08:06:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9OF6ZSV024255 for ; Wed, 24 Oct 2007 08:06:39 -0700 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from imp.csi.cam.ac.uk ([131.111.10.57]:52398) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpsa (PLAIN:aia21) (TLSv1:AES128-SHA:128) id 1Ikhnu-0005Vo-7u (Exim 4.63) (return-path ); Wed, 24 Oct 2007 16:05:54 +0100 From: Anton Altaparmakov To: Barry Naujok In-Reply-To: Subject: Re: [RFC 0/2] Case-insensitive filename lookup for XFS References: <30F0B02B-9857-43E8-89C0-E9C85EF081A2@cam.ac.uk> <7858EE76-E860-41C3-8AFC-CE67DF210081@cam.ac.uk> Message-Id: <1CEB9B80-1826-4495-9156-88BD43BC0186@cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Wed, 24 Oct 2007 16:05:54 +0100 Cc: xfs@oss.sgi.com, xfs-dev , linux-fsdevel@vger.kernel.org X-Mailer: Apple Mail (2.912) X-Virus-Scanned: ClamAV 0.91.2/4589/Wed Oct 24 02:55:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13440 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aia21@cam.ac.uk Precedence: bulk X-list: xfs Hi Barry, On 24 Oct 2007, at 08:39, Barry Naujok wrote: > On Tue, 23 Oct 2007 20:07:47 +1000, Anton Altaparmakov > wrote: >> I forgot to say: If you do what I did for NTFS you can also throw >> away your custom dentry operations that your patch adds as the dcache >> then only holds correctly cased names so you are fine to do case >> sensitive dcache lookups at all times. Access via wrongly cased name >> will always go to ->lookup inode operation and that is fine because >> such lookups almost never happen because majority of users will >> either >> use a GUI in which case all names are always correctly cased as the >> names displayed in the GUI are obtained from a ->readdir and thus >> show >> the correct case or they will use the command line in which case they >> will be savvy enough to use tab-completion in which case the names >> are >> correct case, too. Tab-completion does not work on wrongly cased >> names so you are very unlikely to ever get a wrongly cased name at >> all. >> >> And yes of course you can on purpose construct a test / benchmark >> where having to do the ->lookup each time will be really slow because >> you keep creating files and then accessing them by wrongly cased name >> on purpose (or whatever) but I would hope that you do not care about >> such artificial benchmarks that do not reflect any real-world >> loads... > > I have been looking at ntfs_lookup() and seeing how it does its stuff. > It seems that is the best way to go. > > One thing I have noticed is with two or more attempted case- > insensitive > lookups that don't exist yet case match the same > (ie. ntfs_lookup_inode_by_name() fails with -ENOENT), d_add(dent, > NULL) > is called, populating the dentry with effective duplicates. > > Eg: > # cat /mnt/foo/fileNOTexist > # cat /mnt/foo/FILEnotEXIST > > Will have two negative dentries, am I correct? Yes, that is correct. Well spotted! That means NTFS needs to start killing all negative dentries belonging to a directory each time a directory entry is created in that directory. That is what I do for NTFS on Mac OS X already but I had forgotten about needing to do it on Linux, too. )-: In OSX there the VFS provides a function to do this "xnu/bsd/vfs/ vfs_cache.c::cache_purge_negatives()", we will need to implement an equivalent on Linux: /* * Purge all negative cache entries that are children of the * given vnode. A case-insensitive file system (or any file * system that has multiple equivalent names for the same * directory entry) can use this when creating or renaming * to remove negative entries that may no longer apply. */ void cache_purge_negatives(vnode_t vp) { struct namecache *ncp; NAME_CACHE_LOCK(); LIST_FOREACH(ncp, &vp->v_ncchildren, nc_child) if (ncp->nc_vp == NULL) cache_delete(ncp, 1); NAME_CACHE_UNLOCK(); } The Linux version should be analogous AFAICS, i.e. take the dentry of the directory in which an entry is being created and iterate over its d_subdirs list and for each dentry on that list if it is a negative dentry, i.e. d_inode is NULL, throw the dentry away. Basically very similar to the OSX function but I can't quite see which dcache function we need to call to do the "throw the dentry away" bit. None of the functions in fs/dcache.c look quite right. I imagine we want to take the dcache_lock, traverse d_subdirs list of the directory dentry and for each negative dentry on the list, do a __dget_locked(), __d_drop(), spin_unlock(&dentry->d_lock), then move it from d_subdirs of its parent to a private list and when when we are done, drop the dcache_lock and go over the private list and do a dput() for each dentry on the private list which will result in them all being d_kill()ed. This can probably be made more efficient by someone who understands the dcache better than me but it seems what I suggest would at least do the right thing... Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ From owner-xfs@oss.sgi.com Wed Oct 24 15:27:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 24 Oct 2007 15:27:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9OMRdLi016445 for ; Wed, 24 Oct 2007 15:27:40 -0700 Received: from [IPv6:::1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id l9OMRfo0023565 for ; Wed, 24 Oct 2007 17:27:42 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <471FC6DD.8070009@thebarn.com> Date: Wed, 24 Oct 2007 17:27:41 -0500 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: problems subscribing to this list. References: <3D77EBFA-5164-454E-A4D3-C32BC1830800@counterpop.net> <471D7E55.9020103@sgi.com> <471E7B0C.7020804@thebarn.com> <20071024075320.GX31811@petole.dyndns.org> In-Reply-To: <20071024075320.GX31811@petole.dyndns.org> Content-Type: multipart/mixed; boundary="------------000500020000090006030408" X-Virus-Scanned: ClamAV 0.91.2/4591/Wed Oct 24 12:47:49 2007 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.1/4591/Wed Oct 24 14:47:49 2007 on slurp.thebarn.com X-Virus-Status: Clean X-archive-position: 13441 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------000500020000090006030408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nicolas KOWALSKI wrote: > On Tue, Oct 23, 2007 at 05:51:56PM -0500, Russell Cattelan wrote: > >> Ok so posting this to the list is a bit silly for new subscribers. As >> a reminder to existing list subscribers interesting in modifying their >> list status, the web interface is more reliable than the the email >> interface. >> >> http://oss.sgi.com/cgi-bin/lsg2.cgi >> > > Thanks for the link. > > Maybe it should be mentionned in the mailing-list page for easier access? > > http://oss.sgi.com/projects/xfs/mail.html > > Thanks, > Yes I agree, I did make that request a few weeks back. I will re-ping the SGI folks that can make that change. -Russell --------------000500020000090006030408 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------000500020000090006030408-- From owner-xfs@oss.sgi.com Thu Oct 25 17:57:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 25 Oct 2007 17:57:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9Q0vSPX022059 for ; Thu, 25 Oct 2007 17:57:30 -0700 Received: from Liberator.local (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 9E0D918008611; Thu, 25 Oct 2007 19:57:30 -0500 (CDT) Message-ID: <47213B7A.10501@sandeen.net> Date: Thu, 25 Oct 2007 19:57:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: xfs-oss Subject: [PATCH V3] optimize XFS_IS_REALTIME_INODE w/o realtime config References: <46C7627A.60503@sandeen.net> <20070824140822.GP72985246@sgi.com> <46CF1B22.7090007@sandeen.net> In-Reply-To: <46CF1B22.7090007@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4596/Thu Oct 25 16:37:29 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13442 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 Try again.. :) ------------- Use XFS_IS_REALTIME_INODE in more places, and #define it to 0 if CONFIG_XFS_RT is off. This should be safe because mount checks in xfs_rtmount_init: # define xfs_rtmount_init(m) (((mp)->m_sb.sb_rblocks == 0)? 0 : (ENOSYS)) so if we get mounted w/o CONFIG_XFS_RT, no realtime inodes should be encountered after that. Defining XFS_IS_REALTIME_INODE to 0 saves a bit of stack space, presumeably gcc can optimize around the various "if (0)" type checks: xfs_alloc_file_space -8 xfs_bmap_adjacent -16 xfs_bmapi -8 xfs_bmap_rtalloc -16 xfs_bunmapi -28 xfs_free_file_space -64 xfs_imap +8 <-- ? hmm. xfs_iomap_write_direct -12 xfs_qm_dqusage_adjust -4 xfs_qm_vop_chown_reserve -4 Signed-off-by: Eric Sandeen Index: linux-2.6-xfs/fs/xfs/xfs_rtalloc.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rtalloc.h +++ linux-2.6-xfs/fs/xfs/xfs_rtalloc.h @@ -21,8 +21,6 @@ struct xfs_mount; struct xfs_trans; -#define XFS_IS_REALTIME_INODE(ip) ((ip)->i_d.di_flags & XFS_DIFLAG_REALTIME) - /* Min and max rt extent sizes, specified in bytes */ #define XFS_MAX_RTEXTSIZE (1024 * 1024 * 1024) /* 1GB */ #define XFS_DFL_RTEXTSIZE (64 * 1024) /* 64KB */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c @@ -741,7 +741,7 @@ xfs_ioctl( case XFS_IOC_DIOINFO: { struct dioattr da; xfs_buftarg_t *target = - (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) ? + XFS_IS_REALTIME_INODE(ip) ? mp->m_rtdev_targp : mp->m_ddev_targp; da.d_mem = da.d_miniosz = 1 << target->bt_sshift; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c @@ -213,7 +213,7 @@ xfs_read( if (unlikely(ioflags & IO_ISDIRECT)) { xfs_buftarg_t *target = - (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) ? + XFS_IS_REALTIME_INODE(ip) ? mp->m_rtdev_targp : mp->m_ddev_targp; if ((*offset & target->bt_smask) || (size & target->bt_smask)) { @@ -668,7 +668,7 @@ start: if (ioflags & IO_ISDIRECT) { xfs_buftarg_t *target = - (xip->i_d.di_flags & XFS_DIFLAG_REALTIME) ? + XFS_IS_REALTIME_INODE(xip) ? mp->m_rtdev_targp : mp->m_ddev_targp; if ((pos & target->bt_smask) || (count & target->bt_smask)) { Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c @@ -185,8 +185,7 @@ xfs_swap_extents( } /* Verify both files are either real-time or non-realtime */ - if ((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != - (tip->i_d.di_flags & XFS_DIFLAG_REALTIME)) { + if (XFS_IS_REALTIME_INODE(ip) != XFS_IS_REALTIME_INODE(tip)) { error = XFS_ERROR(EINVAL); goto error0; } Index: linux-2.6-xfs/fs/xfs/xfs_rw.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.h +++ linux-2.6-xfs/fs/xfs/xfs_rw.h @@ -32,7 +32,7 @@ struct xfs_mount; static inline xfs_daddr_t xfs_fsb_to_db(struct xfs_inode *ip, xfs_fsblock_t fsb) { - return (((ip)->i_d.di_flags & XFS_DIFLAG_REALTIME) ? \ + return (XFS_IS_REALTIME_INODE(ip) ? \ (xfs_daddr_t)XFS_FSB_TO_BB((ip)->i_mount, (fsb)) : \ XFS_FSB_TO_DADDR((ip)->i_mount, (fsb))); } @@ -53,7 +53,7 @@ xfs_get_extsz_hint( { xfs_extlen_t extsz; - if (unlikely(ip->i_d.di_flags & XFS_DIFLAG_REALTIME)) { + if (unlikely(XFS_IS_REALTIME_INODE(ip))) { extsz = (ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) ? ip->i_d.di_extsize : ip->i_mount->m_sb.sb_rextsize; Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c @@ -136,7 +136,7 @@ xfs_getattr( default: vap->va_rdev = 0; - if (!(ip->i_d.di_flags & XFS_DIFLAG_REALTIME)) { + if (!(XFS_IS_REALTIME_INODE(ip))) { vap->va_blocksize = xfs_preferred_iosize(mp); } else { @@ -508,7 +508,7 @@ xfs_setattr( */ if ((ip->i_d.di_nextents || ip->i_delayed_blks) && (mask & XFS_AT_XFLAGS) && - (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) != + (XFS_IS_REALTIME_INODE(ip)) != (vap->va_xflags & XFS_XFLAG_REALTIME)) { code = XFS_ERROR(EINVAL); /* EFBIG? */ goto error_return; @@ -520,7 +520,7 @@ xfs_setattr( if ((mask & XFS_AT_EXTSIZE) && vap->va_extsize != 0) { xfs_extlen_t size; - if ((ip->i_d.di_flags & XFS_DIFLAG_REALTIME) || + if (XFS_IS_REALTIME_INODE(ip) || ((mask & XFS_AT_XFLAGS) && (vap->va_xflags & XFS_XFLAG_REALTIME))) { size = mp->m_sb.sb_rextsize << @@ -1144,7 +1144,7 @@ xfs_fsync( * If this inode is on the RT dev we need to flush that * cache as well. */ - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) + if (XFS_IS_REALTIME_INODE(ip)) xfs_blkdev_issue_flush(ip->i_mount->m_rtdev_targp); } @@ -4044,7 +4044,7 @@ xfs_zero_remaining_bytes( int error = 0; bp = xfs_buf_get_noaddr(mp->m_sb.sb_blocksize, - ip->i_d.di_flags & XFS_DIFLAG_REALTIME ? + XFS_IS_REALTIME_INODE(ip) ? mp->m_rtdev_targp : mp->m_ddev_targp); for (offset = startoff; offset <= endoff; offset = lastoffset + 1) { @@ -4141,7 +4141,7 @@ xfs_free_file_space( error = 0; if (len <= 0) /* if nothing being freed */ return error; - rt = (ip->i_d.di_flags & XFS_DIFLAG_REALTIME); + rt = XFS_IS_REALTIME_INODE(ip); startoffset_fsb = XFS_B_TO_FSB(mp, offset); end_dmi_offset = offset + len; endoffset_fsb = XFS_B_TO_FSBT(mp, end_dmi_offset); Index: linux-2.6-xfs/fs/xfs/xfs_dinode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dinode.h +++ linux-2.6-xfs/fs/xfs/xfs_dinode.h @@ -273,6 +273,12 @@ typedef enum xfs_dinode_fmt #define XFS_DIFLAG_NODEFRAG (1 << XFS_DIFLAG_NODEFRAG_BIT) #define XFS_DIFLAG_FILESTREAM (1 << XFS_DIFLAG_FILESTREAM_BIT) +#ifdef CONFIG_XFS_RT +#define XFS_IS_REALTIME_INODE(ip) ((ip)->i_d.di_flags & XFS_DIFLAG_REALTIME) +#else +#define XFS_IS_REALTIME_INODE(ip) (0) +#endif + #define XFS_DIFLAG_ANY \ (XFS_DIFLAG_REALTIME | XFS_DIFLAG_PREALLOC | XFS_DIFLAG_NEWRTBM | \ XFS_DIFLAG_IMMUTABLE | XFS_DIFLAG_APPEND | XFS_DIFLAG_SYNC | \ Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c @@ -1045,7 +1045,7 @@ xfs_dm_direct_ok( /* Realtime files can ONLY do direct I/O. */ - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) + if (XFS_IS_REALTIME_INODE(ip)) return(1); /* If direct I/O is disabled, or if the request is too small, use Index: linux-2.6-xfs/fs/xfs/xfs_bmap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bmap.c +++ linux-2.6-xfs/fs/xfs/xfs_bmap.c @@ -2969,7 +2969,7 @@ STATIC int xfs_bmap_alloc( xfs_bmalloca_t *ap) /* bmap alloc argument struct */ { - if ((ap->ip->i_d.di_flags & XFS_DIFLAG_REALTIME) && ap->userdata) + if (XFS_IS_REALTIME_INODE(ap->ip) && ap->userdata) return xfs_bmap_rtalloc(ap); return xfs_bmap_btalloc(ap); } @@ -3096,8 +3096,7 @@ xfs_bmap_del_extent( /* * Realtime allocation. Free it and record di_nblocks update. */ - if (whichfork == XFS_DATA_FORK && - (ip->i_d.di_flags & XFS_DIFLAG_REALTIME)) { + if (whichfork == XFS_DATA_FORK && XFS_IS_REALTIME_INODE(ip)) { xfs_fsblock_t bno; xfs_filblks_t len; Index: linux-2.6-xfs/fs/xfs/xfs_bmap_btree.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bmap_btree.c +++ linux-2.6-xfs/fs/xfs/xfs_bmap_btree.c @@ -2062,8 +2062,7 @@ xfs_bmbt_insert( pcur->bc_private.b.allocated; pcur->bc_private.b.allocated = 0; ASSERT((cur->bc_private.b.firstblock != NULLFSBLOCK) || - (cur->bc_private.b.ip->i_d.di_flags & - XFS_DIFLAG_REALTIME)); + XFS_IS_REALTIME_INODE(cur->bc_private.b.ip)); cur->bc_private.b.firstblock = pcur->bc_private.b.firstblock; ASSERT(cur->bc_private.b.flist == Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c +++ linux-2.6-xfs/fs/xfs/xfs_inode.c @@ -1296,7 +1296,7 @@ xfs_isize_check( if ((ip->i_d.di_mode & S_IFMT) != S_IFREG) return; - if (ip->i_d.di_flags & (XFS_DIFLAG_REALTIME | XFS_DIFLAG_EXTSIZE)) + if (XFS_IS_REALTIME_INODE(ip) || (ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE)) return; nimaps = 2; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c @@ -113,7 +113,7 @@ xfs_find_bdev_for_inode( { struct xfs_mount *mp = ip->i_mount; - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) + if (XFS_IS_REALTIME_INODE(ip)) return mp->m_rtdev_targp->bt_bdev; else return mp->m_ddev_targp->bt_bdev; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c @@ -597,7 +597,7 @@ xfs_vn_getattr( sysv_minor(ip->i_df.if_u2.if_rdev)); break; default: - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { + if (XFS_IS_REALTIME_INODE(ip)) { /* * If the file blocks are being allocated from a * realtime volume, then return the inode's realtime Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c @@ -141,7 +141,7 @@ xfs_imap_to_bmap( iomapp->iomap_bsize = XFS_FSB_TO_B(mp, imap->br_blockcount); iomapp->iomap_flags = flags; - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) { + if (XFS_IS_REALTIME_INODE(ip)) { iomapp->iomap_flags |= IOMAP_REALTIME; iomapp->iomap_target = mp->m_rtdev_targp; } else { @@ -298,7 +298,7 @@ xfs_iomap_eof_align_last_fsb( xfs_extlen_t align; int eof, error; - if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) + if (XFS_IS_REALTIME_INODE(ip)) ; /* * If mounted with the "-o swalloc" option, roundup the allocation @@ -524,7 +524,7 @@ xfs_iomap_write_direct( } if (unlikely(!imap.br_startblock && - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) { + !(XFS_IS_REALTIME_INODE(ip)))) { error = xfs_cmn_err_fsblock_zero(ip, &imap); goto error_out; } @@ -687,7 +687,7 @@ retry: } if (unlikely(!imap[0].br_startblock && - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) + !(XFS_IS_REALTIME_INODE(ip)))) return xfs_cmn_err_fsblock_zero(ip, &imap[0]); *ret_imap = imap[0]; @@ -809,7 +809,7 @@ xfs_iomap_write_allocate( */ for (i = 0; i < nimaps; i++) { if (unlikely(!imap[i].br_startblock && - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) + !(XFS_IS_REALTIME_INODE(ip)))) return xfs_cmn_err_fsblock_zero(ip, &imap[i]); if ((offset_fsb >= imap[i].br_startoff) && (offset_fsb < (imap[i].br_startoff + @@ -907,7 +907,7 @@ xfs_iomap_write_unwritten( return XFS_ERROR(error); if (unlikely(!imap.br_startblock && - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) + !(XFS_IS_REALTIME_INODE(ip)))) return xfs_cmn_err_fsblock_zero(ip, &imap); if ((numblks_fsb = imap.br_blockcount) == 0) { From owner-xfs@oss.sgi.com Sat Oct 27 04:48:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 Oct 2007 04:48:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from smtp-out.neti.ee (mail.neti.ee [194.126.101.114]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9RBmo9l018107 for ; Sat, 27 Oct 2007 04:48:52 -0700 Received: from smtp-out.neti.ee (relay13.estpak.ee [88.196.174.168]) by HOT-Bounce1.estpak.ee (Postfix) with ESMTP id 2235E6C41F4 for ; Sat, 27 Oct 2007 14:30:38 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by MXR-13.estpak.ee (Postfix) with ESMTP id 14A38A826; Sat, 27 Oct 2007 14:30:35 +0300 (EEST) X-Virus-Scanned: ClamAV 0.91.2/4606/Sat Oct 27 03:06:38 2007 on oss.sgi.com X-Virus-Scanned: amavisd-new at !change-mydomain-variable!.example.com Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-1.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoyQdBdQVgyQ; Sat, 27 Oct 2007 14:30:32 +0300 (EEST) Received: from Relayhost3.neti.ee (unknown [88.196.174.169]) by MXR-13.estpak.ee (Postfix) with ESMTP id 5DE68AD39; Sat, 27 Oct 2007 14:30:32 +0300 (EEST) In-Reply-To: <20071019075949.GS995458@sgi.com> References: <20071018222357.GN995458@sgi.com> <20071019075949.GS995458@sgi.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <034B199C-F1D2-42F8-B774-58AA11D8C79E@cern.ch> Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: Mario Kadastik Subject: Re: raw vs XFS sequential write and system load Date: Sat, 27 Oct 2007 14:30:32 +0300 To: David Chinner X-Mailer: Apple Mail (2.752.2) X-Virus-Status: Clean X-archive-position: 13443 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mario.kadastik@cern.ch Precedence: bulk X-list: xfs Well to finally summarize, the things pointed out all helped too, but the major change in system behavior came from the fact that 2.6.23 had totally different virtual memory defaults than 2.6.9 and running with 2.6.23 one has to change the dirty_ratio to something bigger to allow for a fast i/o machine to actually handle the load. Now the four nodes we have are all running very nicely and calmly and performing all the tasks we have asked from them, no more see we any congestion etc. I have summarized my weeks of investigations into a twiki page, comments are welcome: http://hep.kbfi.ee/index.php/IT/KernelTuning Thanks for the help, Mario From owner-xfs@oss.sgi.com Sat Oct 27 06:07:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 Oct 2007 06:07:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9RD7fcm006791 for ; Sat, 27 Oct 2007 06:07:42 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 7702A1C076DE5; Sat, 27 Oct 2007 09:07:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 72DEF4019581; Sat, 27 Oct 2007 09:07:43 -0400 (EDT) Date: Sat, 27 Oct 2007 09:07:43 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Mario Kadastik cc: David Chinner , xfs@oss.sgi.com Subject: Re: raw vs XFS sequential write and system load In-Reply-To: <034B199C-F1D2-42F8-B774-58AA11D8C79E@cern.ch> Message-ID: References: <20071018222357.GN995458@sgi.com> <20071019075949.GS995458@sgi.com> <034B199C-F1D2-42F8-B774-58AA11D8C79E@cern.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4608/Sat Oct 27 04:42:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13444 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 On Sat, 27 Oct 2007, Mario Kadastik wrote: > Well to finally summarize, the things pointed out all helped too, but the > major change in system behavior came from the fact that 2.6.23 had totally > different virtual memory defaults than 2.6.9 and running with 2.6.23 one has > to change the dirty_ratio to something bigger to allow for a fast i/o machine > to actually handle the load. Now the four nodes we have are all running very > nicely and calmly and performing all the tasks we have asked from them, no > more see we any congestion etc. > > I have summarized my weeks of investigations into a twiki page, comments are > welcome: > > http://hep.kbfi.ee/index.php/IT/KernelTuning > > Thanks for the help, > > Mario > Very nice doc! Thanks. Justin. From owner-xfs@oss.sgi.com Sat Oct 27 16:41:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 27 Oct 2007 16:41:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_99,J_CHICKENPOX_46 autolearn=no version=3.3.0-r574664 Received: from perso1.free.fr (perso1.free.fr [212.27.63.203]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9RNfnvM012714 for ; Sat, 27 Oct 2007 16:41:51 -0700 Received: from localhost.localdomain (localhost [127.0.0.1]) by perso1.free.fr (Postfix) with ESMTP id 51FDCA0D099 for ; Sun, 28 Oct 2007 01:24:10 +0200 (MEST) XPARM: clowforeversblog.free.fr XPARAM2: 196.1.179.139 Subject: Elizabeth & Deacon Samson, From: Elizabeth & Deacon Samson Reply-To: Deacon.samson@Deacons.com MIME-Version: 1.0 Message-Id: <20060309113857.3940.qmail@msgcu.org> Content-Type: text/plain Content-Transfer-Encoding: 8bit Date: Sun, 28 Oct 2007 01:24:10 To: xfs@oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/4610/Sat Oct 27 09:25:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13445 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Deacon.samson@Deacons.com Precedence: bulk X-list: xfs 218 Brixton Hill,london England-SW2 IRP United Kingdom. Dear In Christ, This is a personal email directed to you and I request that it be treated as such. God is a spirit, and they that worship him must worship him in spirit and in truth. Based on this scripture, it became obvious that I should do the right thing if I must enter into the kingdom of God. I am , Deacon Samson the legal adviser to late Mr. Mike & Carol Hall, a God fearing and dedicated couple. They were very wealthy but had no child. They travelled to Patong-Thailand for Christmas holiday but met death on the 26th of December 2004 during the Tsunami disaster( http://news.bbc.co.uk/1/hi/england/bristol/4153821.stm As their legal adviser, before their death, the husband Mr. Mike Hall instructed me to write his WILL, because they had no child, he dedicated their wealth to God. They had a lot of landed properties houses Stocks/bonds, etc. According to their instruction. According to the WILL, their assets should be given out to a ministry for the work of God. As their legal adviser, all the documents for the fund that are deposited with the Vault company are in my care. As a born again Christian , I have been reading my bible and I have to do what is lawful and right in the sight of God by giving out the fund to the chosen ministry for the purpose of God's work as instructed by the owners before there death. After my fasting and prayers Today, I asked God to make his choice and direct me to an honest Christian or the chosen ministry that deserves this fund by his Grace. I then came across your address on the Internet.I appeal to you to use the fund wisely for things that will glorify the name of God. Also, could you get back to me having visiting the above website to enable us discuss in a more clarifying manner to the best of your understanding. I must say that I'm very uncomfortable sending this message to you without knowing truly if you would misconstrue the importance and decides to go public. In this regards, I will not hold back to say that the essence of this message is strictly for Charity. May God bless you as you make up your mind to work for God. Thanks. Elizabeth & Deacon Samaon Call me on +44-7045701758 From owner-xfs@oss.sgi.com Sun Oct 28 08:36:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 08:36:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_40,RCVD_IN_DNSWL_MED, SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from b.mx.filmlight.ltd.uk (bongo.filmlight.ltd.uk [217.40.27.26]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9SFafYr013514 for ; Sun, 28 Oct 2007 08:36:43 -0700 Received: (dqd 4291 invoked from network); 28 Oct 2007 14:36:43 -0000 Received: from unknown (HELO ?10.44.0.101?) (roger@10.44.0.101) by b.mx.filmlight.ltd.uk with SMTP; 28 Oct 2007 14:36:43 -0000 Message-ID: <47249E7A.7060709@filmlight.ltd.uk> Date: Sun, 28 Oct 2007 14:36:42 +0000 From: Roger Willcocks User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: bug: truncate to zero + setuid Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4611/Sat Oct 27 21:53:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13446 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: roger@filmlight.ltd.uk Precedence: bulk X-list: xfs The nfsv3 setattr call permits a simultaneous truncate + setuid/gid operation. Normally XFS handles this fine, but if the file's being truncated to zero, and the file's already empty, XFS simply ignores the setuid/gid part, returning 'success'. The error's in xfs_vnodeops.c/xfs_setattr below the comment 'Short circuit the truncate case for zero length files', which bypasses all other changes. The simplest fix is to test whether this is the only change that's happening, otherwise you get tangled in transactions. if (mask & XFS_AT_SIZE) { /* Short circuit the truncate case for zero length files */ - if ((vap->va_size == 0) && + if (((mask & ~XFS_AT_SIZE) == 0) && (vap->va_size == 0) && (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == 0)) { -- Roger From owner-xfs@oss.sgi.com Sun Oct 28 10:47:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 10:47:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-7.9 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_61, J_CHICKENPOX_71,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.0-r574664 Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9SHlJTC013644 for ; Sun, 28 Oct 2007 10:47:20 -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 CB33C150F8; Sun, 28 Oct 2007 18:36:10 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: linux-xfs@oss.sgi.com, Timothy Shimmin Subject: attr: xattr.conf Date: Sun, 28 Oct 2007 18:38:10 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_CkMJHqRsX6Tc6k/" Message-Id: <200710281838.10658.agruen@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4614/Sun Oct 28 08:21:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13448 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs --Boundary-00=_CkMJHqRsX6Tc6k/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, here is another patch which for some reason didn't get merged into the upstream version: the current attribute copying functions attr_copy_file and attr_copy_fd is a static list of exceptions for attributes that need special treatment. The list of those attributes tends to change (slowly) with kernel versions. We replaced the static list with a config file a while ago; this is the patch used. Any objections to merging this into the upstream version as well? Attached is the patch, and an xattr.conf example. Thanks, Andreas --Boundary-00=_CkMJHqRsX6Tc6k/ Content-Type: text/plain; charset="us-ascii"; name="xattr.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xattr.conf" # /etc/xattr.conf # # How to handle extended attributes when copying between files # # Format: # # # Actions: # permissions - copy when trying to preserve permissions. # skip - do not copy. system.nfs4_acl permissions system.nfs4acl permissions system.posix_acl_access permissions system.posix_acl_default permissions trusted.SGI_ACL_DEFAULT skip # xfs specific trusted.SGI_ACL_FILE skip # xfs specific trusted.SGI_CAP_FILE skip # xfs specific trusted.SGI_DMI_* skip # xfs specific trusted.SGI_MAC_FILE skip # xfs specific xfsroot.* skip # xfs specific; obsolete user.Beagle.* skip # ignore Beagle index data --Boundary-00=_CkMJHqRsX6Tc6k/ Content-Type: text/x-diff; charset="us-ascii"; name="xattr_conf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xattr_conf.diff" Index: attr-2.4.39/libattr/Makefile =================================================================== --- attr-2.4.39.orig/libattr/Makefile +++ attr-2.4.39/libattr/Makefile @@ -12,7 +12,7 @@ LT_CURRENT = 2 LT_REVISION = 0 LT_AGE = 1 -CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c +CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c attr_copy_action.c HFILES = libattr.h ifeq ($(PKG_PLATFORM),linux) Index: attr-2.4.39/libattr/attr_copy_action.c =================================================================== --- /dev/null +++ attr-2.4.39/libattr/attr_copy_action.c @@ -0,0 +1,163 @@ +/* Copyright (C) 2006 Andreas Gruenbacher , SuSE Linux AG. + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +*/ + +#include +#include +#include +#include +#include +#include +#include + +#include "attr/libattr.h" +#define ERROR_CONTEXT_MACROS +#include "error_context.h" + +#define ATTR_CONF "/etc/xattr.conf" + +struct attr_action { + struct attr_action *next; + char *pattern; + int action; +}; + +static struct attr_action *attr_actions; + +static void +free_attr_actions(void) +{ + struct attr_action *tmp; + + while (attr_actions) { + tmp = attr_actions->next; + free(attr_actions->pattern); + free(attr_actions); + attr_actions = tmp; + } +} + +static int +attr_parse_attr_conf(struct error_context *ctx) +{ + char *text, *t; + size_t size_guess = 4096, len; + FILE *file; + char *pattern = NULL; + struct attr_action *new; + int action; + + if (attr_actions) + return 0; + +repeat: + text = malloc(size_guess + 1); + if (!text) + goto fail; + + if ((file = fopen(ATTR_CONF, "r")) == NULL) { + if (errno == ENOENT) + return 0; + goto fail; + } + len = fread(text, 1, size_guess, file); + if (ferror(file)) + goto fail; + if (!feof(file)) { + fclose(file); + file = NULL; + free(text); + size_guess *= 2; + goto repeat; + } + fclose(file); + file = NULL; + + text[len] = 0; + t = text; + for (;;) { + t += strspn(t, " \t\n"); + len = strcspn(t, " \t\n#"); + if (t[len] == '#') { + if (len) + goto parse_error; + t += strcspn(t, "\n"); + continue; + } else if (t[len] == 0) + break; + else if (t[len] == '\n') + goto parse_error; + pattern = strndup(t, len); + if (!pattern) + goto fail; + t += len; + + t += strspn(t, " \t"); + len = strcspn(t, " \t\n#"); + if (len == 4 && !strncmp(t, "skip", 4)) + action = ATTR_ACTION_SKIP; + else if (len == 11 && !strncmp(t, "permissions", 11)) + action = ATTR_ACTION_PERMISSIONS; + else + goto parse_error; + t += len; + t += strspn(t, " \t"); + if (*t != '#' && *t != '\n') + goto parse_error; + + new = malloc(sizeof(struct attr_action)); + if (!new) + goto parse_error; + new->next = attr_actions; + new->pattern = pattern; + new->action = action; + attr_actions = new; + + t += strcspn(t, "\n"); + } + return 0; + +parse_error: + errno = EINVAL; + +fail: + { + const char *q = quote (ctx, ATTR_CONF); + error (ctx, "%s", q); + quote_free (ctx, q); + } + + free(pattern); + if (file) + fclose(file); + free(text); + free_attr_actions(); + return -1; +} + +int +attr_copy_action(const char *name, struct error_context *ctx) +{ + struct attr_action *action = attr_actions; + + if (!attr_parse_attr_conf(ctx)) { + for (action = attr_actions; action; action = action->next) { + if (!fnmatch(action->pattern, name, 0)) + return action->action; + } + } + return 0; +} Index: attr-2.4.39/libattr/attr_copy_fd.c =================================================================== --- attr-2.4.39.orig/libattr/attr_copy_fd.c +++ attr-2.4.39/libattr/attr_copy_fd.c @@ -119,7 +119,7 @@ attr_copy_fd(const char *src_path, int s quote_free (ctx, qname); quote_free (ctx, qpath); ret = -1; - continue; /* may not have permission to access */ + continue; } value = (char *) realloc (old_value = value, size); if (size != 0 && value == NULL) { @@ -136,6 +136,7 @@ attr_copy_fd(const char *src_path, int s quote_free (ctx, qname); quote_free (ctx, qpath); ret = -1; + continue; } if (fsetxattr (dst_fd, name, value, size, 0) != 0) { if (errno == ENOTSUP) Index: attr-2.4.39/libattr/attr_copy_file.c =================================================================== --- attr-2.4.39.orig/libattr/attr_copy_file.c +++ attr-2.4.39/libattr/attr_copy_file.c @@ -117,7 +117,7 @@ attr_copy_file(const char *src_path, con quote_free (ctx, qname); quote_free (ctx, qpath); ret = -1; - continue; /* may not have permission to access */ + continue; } value = (char *) realloc (old_value = value, size); if (size != 0 && value == NULL) { @@ -134,6 +134,7 @@ attr_copy_file(const char *src_path, con quote_free (ctx, qname); quote_free (ctx, qpath); ret = -1; + continue; } if (lsetxattr (dst_path, name, value, size, 0) != 0) { if (errno == ENOTSUP) Index: attr-2.4.39/libattr/attr_copy_check.c =================================================================== --- attr-2.4.39.orig/libattr/attr_copy_check.c +++ attr-2.4.39/libattr/attr_copy_check.c @@ -23,32 +23,6 @@ int attr_copy_check_permissions(const char *name, struct error_context *ctx) { - /* Skip POSIX ACLs. */ - if (strncmp(name, "system.posix_acl_", 17) == 0 && - (strcmp(name+17, "access") == 0 || - strcmp(name+17, "default") == 0)) - return 0; - - /* Skip permissions attributes which are used on IRIX, and - hence are part of the XFS ondisk format (incl. ACLs). - Also skip SGI DMF attributes as they are inappropriate - targets for copying over as well. */ - if (strncmp(name, "trusted.SGI_", 12) == 0 && - (strcmp(name+12, "ACL_DEFAULT") == 0 || - strcmp(name+12, "ACL_FILE") == 0 || - strcmp(name+12, "CAP_FILE") == 0 || - strcmp(name+12, "MAC_FILE") == 0 || - strncmp(name+12, "DMI_", 4) == 0)) - return 0; - - /* The xfsroot namespace mirrored attributes, some of which - are also also available via the system.* and trusted.* - namespaces. To avoid the problems this would cause, - we skip xfsroot altogether. - Note: xfsroot namespace has now been removed from XFS. */ - if (strncmp(name, "xfsroot.", 8) == 0) - return 0; - - return 1; + return attr_copy_action(name, ctx) == 0; } Index: attr-2.4.39/include/libattr.h =================================================================== --- attr-2.4.39.orig/include/libattr.h +++ attr-2.4.39/include/libattr.h @@ -14,9 +14,14 @@ extern int attr_copy_fd (const char *, i int (*) (const char *, struct error_context *), struct error_context *); -/* The default check function used by attr_copy_{fd,file}. */ +/* Keep this function for backwards compatibility. */ extern int attr_copy_check_permissions(const char *, struct error_context *); +#define ATTR_ACTION_SKIP 1 +#define ATTR_ACTION_PERMISSIONS 2 + +extern int attr_copy_action(const char *, struct error_context *); + #ifdef __cplusplus } #endif --Boundary-00=_CkMJHqRsX6Tc6k/-- From owner-xfs@oss.sgi.com Sun Oct 28 10:47:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 10:47:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.0-r574664 Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9SHlJfP013643 for ; Sun, 28 Oct 2007 10:47:20 -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 64FF815510; Sun, 28 Oct 2007 18:30:24 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: linux-xfs@oss.sgi.com, Tim Shimmin Subject: attr: Remove eaconv script Date: Sun, 28 Oct 2007 18:32:23 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_oeMJHI3uWU01Ia8" Message-Id: <200710281832.24153.agruen@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4614/Sun Oct 28 08:21:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13447 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs --Boundary-00=_oeMJHI3uWU01Ia8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, while updating our attr package I noticed that we still have eaconv, a script for converting between an xattr user-space representation which long since disappeared. Here is patch for removing this now-useless script. Any objections? Thanks, Andreas --Boundary-00=_oeMJHI3uWU01Ia8 Content-Type: text/x-diff; charset="us-ascii"; name="remove-ea-conv.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remove-ea-conv.diff" Index: attr-2.4.39/doc/Makefile =================================================================== --- attr-2.4.39.orig/doc/Makefile +++ attr-2.4.39/doc/Makefile @@ -5,8 +5,6 @@ TOPDIR = .. include $(TOPDIR)/include/builddefs -SUBDIRS = ea-conv - LSRCFILES = INSTALL PORTING CHANGES COPYING LDIRT = *.gz Index: attr-2.4.39/doc/ea-conv/Makefile =================================================================== --- attr-2.4.39.orig/doc/ea-conv/Makefile +++ /dev/null @@ -1,17 +0,0 @@ -# -# Copyright (c) 2000, 2002 Silicon Graphics, Inc. All Rights Reserved. -# - -TOPDIR = ../.. -include $(TOPDIR)/include/builddefs - -LSRCFILES = README ea-conv - -include $(BUILDRULES) - -install: default - $(INSTALL) -m 755 -d $(PKG_DOC_DIR)/ea-conv - $(INSTALL) -m 644 README $(PKG_DOC_DIR)/ea-conv - $(INSTALL) -m 755 ea-conv $(PKG_DOC_DIR)/ea-conv - -default install-dev install-lib: Index: attr-2.4.39/doc/ea-conv/README =================================================================== --- attr-2.4.39.orig/doc/ea-conv/README +++ /dev/null @@ -1,13 +0,0 @@ -ea-conv -- convert between aget and getfattr format - -This script converts between the extended attribute text formats of -getfattr and its predecessor, aget. To get all attributes with aget -and convert the result to getfattr format, use the following command: - - aget -Rds -e hex . | ea-conv - - -To get all attributes with getfattr and convert the result to aget -format, use the following command: - - getfattr -Rd -m - -e hex . | ea-conv - - Index: attr-2.4.39/doc/ea-conv/ea-conv =================================================================== --- attr-2.4.39.orig/doc/ea-conv/ea-conv +++ /dev/null @@ -1,119 +0,0 @@ -#!/usr/bin/perl -w - -use strict; -use FileHandle; - -sub convert_acl($) -{ - my ($value) = @_; - - local $_ = $value; - - die "ACL value must be hex encoded\n" unless (s/^0x//); - s/\s//g; - - my ($x4, $x8) = ('([0-9A-Fa-f]{4})', '([0-9A-Fa-f]{8})'); - - if (s/^01000000//) { - my $new_value = '0x02000000 '; - while ($_ ne '') { - if (s/^(0100|0400|1000|2000)$x4//) { - $new_value .= "$1$2ffffffff "; - } elsif (s/^(0200|0800)$x4$x8//) { - $new_value .= "$1$2$3 "; - } else { - die "ACL format not recognized\n" - } - } - return $new_value; - } elsif (s/^02000000//) { - my $new_value = '0x01000000 '; - while ($_ ne '') { - if (s/^(0100|0400|1000|2000)$x4$x8//) { - $new_value .= "$1$2 "; - } elsif (s/^(0200|0800)$x4$x8//) { - $new_value .= "$1$2$3 "; - } else { - die "ACL format not recognized\n" - } - } - return $new_value; - } else { - die "ACL format not recognized\n" - } -} - -sub check_name($) { - my ($name) = @_; - if ($name =~ m[^[^A-Za-z]]) { - print STDERR "Renaming attribute `user.$name' to `X$name'.\n"; - return "X$name"; - } - return $name; -} - -sub convert($) { - my ($file) = @_; - - eval { - while (<$file>) { - m[^(#.*)?$] || - s[^system\.posix_acl_access=(0x02.*)] - ['$acl=' . convert_acl($1)]e || - s[^system\.posix_acl_default=(0x02.*)] - ['$defacl=' . convert_acl($1)]e || - s[^user\.([^=]*)][check_name($1)]e || - - s[^\$acl=(0x01.*)] - ['system.posix_acl_access=' . - convert_acl($1)]e || - s[^\$defacl=(0x01.*)] - ['system.posix_acl_default=' . - convert_acl($1)]e || - s[^([A-Za-z][^=]*)][user.$1] || - - die "Input format error\n"; - - print; - } - }; - if ($@) { - chomp $@; - print STDERR "$@ in line $..\n"; - } - return (not $@); -} - -unless (@ARGV) { - printf STDERR <close unless ($arg eq '-'); -} -exit (not $good); --Boundary-00=_oeMJHI3uWU01Ia8-- From owner-xfs@oss.sgi.com Sun Oct 28 10:56:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 10:56:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_34, J_CHICKENPOX_36,J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45, J_CHICKENPOX_47,J_CHICKENPOX_64,J_CHICKENPOX_72,J_CHICKENPOX_84, RCVD_IN_DNSWL_MED,URIBL_OB_SURBL autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9SHuLpj016960 for ; Sun, 28 Oct 2007 10:56:23 -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 38A0C22B15; Sun, 28 Oct 2007 18:56:25 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: linux-xfs@oss.sgi.com, Timothy Shimmin Subject: acl and attr: Fix path walking code Date: Sun, 28 Oct 2007 18:58:24 +0100 User-Agent: KMail/1.9.5 Cc: Gerald Bringhurst , Brandon Philips MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_A3MJH2/pbEYYK1y" Message-Id: <200710281858.24428.agruen@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4614/Sun Oct 28 08:21:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13449 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs --Boundary-00=_A3MJH2/pbEYYK1y Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, the tree walking code in acl and attr broke when resolve_symlinks() was introduced (by me, unfortunately). Following symlinks passed in on the command line is the intended behavior for the tools (unless in -P mode). The first version was buggy, and so someone "fixed" it by replacing readlink() with realpath() in resolve_symlinks(). The result is that the output of getfattr and getfacl will show pathnames that may point anywhere. When processing a directory tree it sometimes is helpful to treat symlinks as regular files, but resolving the pathnames is totally wrong. After runnig into problem after problem with nftw and never ending up with even half-way clean code, I think it's time to ditch it altogether and replace it with sane code. So here are two patches, one for attr and one for acl, that does that. Files include/walk_tree.h and libmisc/walk_tree.c are identical in both patches; that code is shared between the two packages. Okay to apply? Thanks, Andreas --Boundary-00=_A3MJH2/pbEYYK1y Content-Type: text/x-diff; charset="us-ascii"; name="walk-acl.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="walk-acl.diff" Index: acl-2.2.45/getfacl/getfacl.c =================================================================== --- acl-2.2.45.orig/getfacl/getfacl.c +++ acl-2.2.45/getfacl/getfacl.c @@ -34,10 +34,10 @@ #include #include #include -#include #include #include "config.h" #include "user_group.h" +#include "walk_tree.h" #include "misc.h" #define POSIXLY_CORRECT_STR "POSIXLY_CORRECT" @@ -70,24 +70,22 @@ struct option long_options[] = { const char *progname; const char *cmd_line_options; -int opt_recursive; /* recurse into sub-directories? */ -int opt_walk_logical; /* always follow symbolic links */ -int opt_walk_physical; /* never follow symbolic links */ -int opt_print_acl = 0; -int opt_print_default_acl = 0; +int walk_flags = WALK_TREE_DEREFERENCE; +int opt_print_acl; +int opt_print_default_acl; int opt_strip_leading_slash = 1; int opt_comments = 1; /* include comments */ -int opt_skip_base = 0; /* skip files that only have the base entries */ -int opt_tabular = 0; /* tabular output format (alias `showacl') */ +int opt_skip_base; /* skip files that only have the base entries */ +int opt_tabular; /* tabular output format (alias `showacl') */ #if POSIXLY_CORRECT const int posixly_correct = 1; /* Posix compatible behavior! */ #else -int posixly_correct = 0; /* Posix compatible behavior? */ +int posixly_correct; /* Posix compatible behavior? */ #endif -int had_errors = 0; -int absolute_warning = 0; /* Absolute path warning was issued */ +int had_errors; +int absolute_warning; /* Absolute path warning was issued */ int print_options = TEXT_SOME_EFFECTIVE; -int opt_numeric = 0; /* don't convert id's to symbolic names */ +int opt_numeric; /* don't convert id's to symbolic names */ static const char *xquote(const char *str) @@ -425,12 +423,23 @@ acl_get_file_mode(const char *path_p) return acl_from_mode(st.st_mode); } -int do_print(const char *path_p, const struct stat *st) +int do_print(const char *path_p, const struct stat *st, int walk_flags, void *unused) { const char *default_prefix = NULL; acl_t acl = NULL, default_acl = NULL; int error = 0; + if (walk_flags & WALK_TREE_FAILED) { + fprintf(stderr, "%s: %s: %s\n", progname, xquote(path_p), + strerror(errno)); + return 1; + } + + if ((walk_flags & WALK_TREE_SYMLINK) && + ((walk_flags & WALK_TREE_PHYSICAL) || + !(walk_flags & (WALK_TREE_TOPLEVEL | WALK_TREE_LOGICAL)))) + return 0; + if (opt_print_acl) { acl = acl_get_file(path_p, ACL_TYPE_ACCESS); if (acl == NULL && (errno == ENOSYS || errno == ENOTSUP)) @@ -549,7 +558,7 @@ void help(void) " --skip-base skip files that only have the base entries\n" " -R, --recursive recurse into subdirectories\n" " -L, --logical logical walk, follow symbolic links\n" -" -P --physical physical walk, do not follow symbolic links\n" +" -P, --physical physical walk, do not follow symbolic links\n" " --tabular use tabular output format\n" " --numeric print numeric user/group identifiers\n" " --absolute-names don't strip leading '/' in pathnames\n")); @@ -560,75 +569,6 @@ void help(void) " --help this help text\n")); } - -static int __errors; -int __do_print(const char *file, const struct stat *stat, - int flag, struct FTW *ftw) -{ - int saved_errno = errno; - - /* Process the target of a symbolic link, and traverse the link, - only if doing a logical walk, or if the symbolic link was - specified on the command line. Always skip symbolic links if - doing a physical walk. */ - - if (S_ISLNK(stat->st_mode) && - (opt_walk_physical || (ftw->level > 0 && !opt_walk_logical))) - return 0; - - if (do_print(file, stat)) - __errors++; - - if (flag == FTW_DNR && opt_recursive) { - /* Item is a directory which can't be read. */ - fprintf(stderr, "%s: %s: %s\n", - progname, file, strerror(saved_errno)); - return 0; - } - - /* We also get here in non-recursive mode. In that case, - return something != 0 to abort nftw. */ - - if (!opt_recursive) - return 1; - - return 0; -} - -char *resolve_symlinks(const char *file) -{ - static char buffer[4096]; - struct stat stat; - char *path = NULL; - - if (lstat(file, &stat) == -1) - return path; - - if (S_ISLNK(stat.st_mode) && !opt_walk_physical) - path = realpath(file, buffer); - else - path = (char *)file; /* not a symlink, use given path */ - - return path; -} - -int walk_tree(const char *file) -{ - const char *p; - - __errors = 0; - if ((p = resolve_symlinks(file)) == NULL) { - fprintf(stderr, "%s: %s: %s\n", progname, - xquote(file), strerror(errno)); - __errors++; - } else if (nftw(p, __do_print, 0, opt_walk_logical? 0 : FTW_PHYS) < 0) { - fprintf(stderr, "%s: %s: %s\n", progname, xquote(file), - strerror(errno)); - __errors++; - } - return __errors; -} - int main(int argc, char *argv[]) { int opt; @@ -691,21 +631,21 @@ int main(int argc, char *argv[]) case 'R': /* recursive */ if (posixly_correct) goto synopsis; - opt_recursive = 1; + walk_flags |= WALK_TREE_RECURSIVE; break; case 'L': /* follow all symlinks */ if (posixly_correct) goto synopsis; - opt_walk_logical = 1; - opt_walk_physical = 0; + walk_flags |= WALK_TREE_LOGICAL; + walk_flags &= ~WALK_TREE_PHYSICAL; break; case 'P': /* skip all symlinks */ if (posixly_correct) goto synopsis; - opt_walk_logical = 0; - opt_walk_physical = 1; + walk_flags |= WALK_TREE_PHYSICAL; + walk_flags &= ~WALK_TREE_LOGICAL; break; case 's': /* skip files with only base entries */ @@ -762,7 +702,8 @@ int main(int argc, char *argv[]) if (*line == '\0') continue; - had_errors += walk_tree(line); + had_errors += walk_tree(line, walk_flags, 0, + do_print, NULL); } if (!feof(stdin)) { fprintf(stderr, _("%s: Standard input: %s\n"), @@ -770,7 +711,8 @@ int main(int argc, char *argv[]) had_errors++; } } else - had_errors += walk_tree(argv[optind]); + had_errors += walk_tree(argv[optind], walk_flags, 0, + do_print, NULL); optind++; } while (optind < argc); Index: acl-2.2.45/libmisc/Makefile =================================================================== --- acl-2.2.45.orig/libmisc/Makefile +++ acl-2.2.45/libmisc/Makefile @@ -8,7 +8,7 @@ include $(TOPDIR)/include/builddefs LTLIBRARY = libmisc.la LTLDFLAGS = -CFILES = quote.c unquote.c high_water_alloc.c next_line.c +CFILES = quote.c unquote.c high_water_alloc.c next_line.c walk_tree.c default: $(LTLIBRARY) install install-dev install-lib: Index: acl-2.2.45/setfacl/do_set.c =================================================================== --- acl-2.2.45.orig/setfacl/do_set.c +++ acl-2.2.45/setfacl/do_set.c @@ -36,10 +36,10 @@ #include "sequence.h" #include "parse.h" #include "config.h" +#include "walk_tree.h" extern const char *progname; -extern int opt_recursive; extern int opt_recalculate; extern int opt_test; extern int print_options; @@ -259,8 +259,10 @@ int do_set( const char *path_p, const struct stat *st, - const seq_t seq) + int walk_flags, + void *arg) { + const seq_t seq = (const seq_t)arg; acl_t old_acl = NULL, old_default_acl = NULL; acl_t acl = NULL, default_acl = NULL; acl_t *xacl, *old_xacl; @@ -272,6 +274,16 @@ do_set( int acl_modified = 0, default_acl_modified = 0; int acl_mask_provided = 0, default_acl_mask_provided = 0; + if (walk_flags & WALK_TREE_FAILED) { + fprintf(stderr, "%s: %s: %s\n", progname, path_p, strerror(errno)); + return 1; + } + + if ((walk_flags & WALK_TREE_SYMLINK) && + ((walk_flags & WALK_TREE_PHYSICAL) || + !(walk_flags & (WALK_TREE_TOPLEVEL | WALK_TREE_LOGICAL)))) + return 0; + /* Execute the commands in seq (read ACLs on demand) */ error = seq_get_cmd(seq, SEQ_FIRST_CMD, &cmd); if (error == 0) @@ -426,7 +438,7 @@ do_set( } /* Only directores can have default ACLs */ - if (default_acl && !S_ISDIR(st->st_mode) && opt_recursive) { + if (default_acl && !S_ISDIR(st->st_mode) && (walk_flags & WALK_TREE_RECURSIVE)) { /* In recursive mode, ignore default ACLs for files */ acl_free(default_acl); default_acl = NULL; Index: acl-2.2.45/setfacl/setfacl.c =================================================================== --- acl-2.2.45.orig/setfacl/setfacl.c +++ acl-2.2.45/setfacl/setfacl.c @@ -28,20 +28,15 @@ #include #include #include -#include #include #include #include "config.h" #include "sequence.h" #include "parse.h" +#include "walk_tree.h" #include "misc.h" -extern int -do_set( - const char *path_p, - const struct stat *stat_p, - const seq_t seq); - +extern int do_set(const char *path_p, const struct stat *stat_p, int flags, void *arg); #define POSIXLY_CORRECT_STR "POSIXLY_CORRECT" @@ -82,9 +77,7 @@ struct option long_options[] = { const char *progname; const char *cmd_line_options, *cmd_line_spec; -int opt_recursive; /* recurse into sub-directories? */ -int opt_walk_logical; /* always follow symbolic links */ -int opt_walk_physical; /* never follow symbolic links */ +int walk_flags = WALK_TREE_DEREFERENCE; int opt_recalculate; /* recalculate mask entry (0=default, 1=yes, -1=no) */ int opt_promote; /* promote access ACL to default ACL */ int opt_test; /* do not write to the file system. @@ -188,7 +181,7 @@ restore( stat.st_uid = uid; stat.st_gid = gid; - error = do_set(path_p, &stat, seq); + error = do_set(path_p, &stat, 0, seq); if (error != 0) { status = 1; goto resume; @@ -275,77 +268,6 @@ void help(void) } -static int __errors; -static seq_t __seq; - -int __do_set(const char *file, const struct stat *stat, - int flag, struct FTW *ftw) -{ - int saved_errno = errno; - - /* Process the target of a symbolic link, and traverse the link, - only if doing a logical walk, or if the symbolic link was - specified on the command line. Always skip symbolic links if - doing a physical walk. */ - - if (S_ISLNK(stat->st_mode) && - (opt_walk_physical || (ftw->level > 0 && !opt_walk_logical))) - return 0; - - if (do_set(file, stat, __seq)) - __errors++; - - if (flag == FTW_DNR && opt_recursive) { - /* Item is a directory which can't be read. */ - fprintf(stderr, "%s: %s: %s\n", - progname, file, strerror(saved_errno)); - return 0; - } - - /* We also get here in non-recursive mode. In that case, - return something != 0 to abort nftw. */ - - if (!opt_recursive) - return 1; - - return 0; -} - -char *resolve_symlinks(const char *file) -{ - static char buffer[4096]; - struct stat stat; - char *path = NULL; - - if (lstat(file, &stat) == -1) - return path; - - if (S_ISLNK(stat.st_mode) && !opt_walk_physical) - path = realpath(file, buffer); - else - path = (char *)file; /* not a symlink, use given path */ - - return path; -} - -int walk_tree(const char *file, seq_t seq) -{ - const char *p; - - __errors = 0; - __seq = seq; - if ((p = resolve_symlinks(file)) == NULL) { - fprintf(stderr, "%s: %s: %s\n", progname, - xquote(file), strerror(errno)); - __errors++; - } else if (nftw(p, __do_set, 0, opt_walk_logical ? 0 : FTW_PHYS) < 0) { - fprintf(stderr, "%s: %s: %s\n", progname, - xquote(file), strerror(errno)); - __errors++; - } - return __errors; -} - int next_file(const char *arg, seq_t seq) { char *line; @@ -353,14 +275,14 @@ int next_file(const char *arg, seq_t seq if (strcmp(arg, "-") == 0) { while ((line = next_line(stdin))) - errors = walk_tree(line, seq); + errors = walk_tree(line, walk_flags, 0, do_set, seq); if (!feof(stdin)) { fprintf(stderr, _("%s: Standard input: %s\n"), progname, strerror(errno)); errors = 1; } } else { - errors = walk_tree(arg, seq); + errors = walk_tree(arg, walk_flags, 0, do_set, seq); } return errors ? 1 : 0; } @@ -627,17 +549,17 @@ int main(int argc, char *argv[]) break; case 'R': /* recursive */ - opt_recursive = 1; + walk_flags |= WALK_TREE_RECURSIVE; break; case 'L': /* follow symlinks */ - opt_walk_logical = 1; - opt_walk_physical = 0; + walk_flags |= WALK_TREE_LOGICAL; + walk_flags &= ~WALK_TREE_PHYSICAL; break; case 'P': /* do not follow symlinks */ - opt_walk_logical = 0; - opt_walk_physical = 1; + walk_flags |= WALK_TREE_PHYSICAL; + walk_flags &= ~WALK_TREE_LOGICAL; break; case 't': /* test mode */ Index: acl-2.2.45/include/walk_tree.h =================================================================== --- /dev/null +++ acl-2.2.45/include/walk_tree.h @@ -0,0 +1,19 @@ +#ifndef __WALK_TREE_H +#define __WALK_TREE_H + +#define WALK_TREE_RECURSIVE 0x1 +#define WALK_TREE_PHYSICAL 0x2 +#define WALK_TREE_LOGICAL 0x4 +#define WALK_TREE_DEREFERENCE 0x8 + +#define WALK_TREE_TOPLEVEL 0x100 +#define WALK_TREE_SYMLINK 0x200 +#define WALK_TREE_FAILED 0x400 + +struct stat; + +extern int walk_tree(const char *path, int walk_flags, unsigned int num, + int (*func)(const char *, const struct stat *, int, + void *), void *arg); + +#endif Index: acl-2.2.45/libmisc/walk_tree.c =================================================================== --- /dev/null +++ acl-2.2.45/libmisc/walk_tree.c @@ -0,0 +1,188 @@ +/* + File: walk_tree.c + + Copyright (C) 2007 Andreas Gruenbacher + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with this library; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "walk_tree.h" + +struct entry_handle { + struct entry_handle *prev, *next; + struct stat st; + DIR *stream; + off_t pos; +}; + +struct entry_handle head = { + .next = &head, + .prev = &head, + /* The other fields are unused. */ +}; +struct entry_handle *closed = &head; +unsigned int num_dir_handles; + +static int walk_tree_rec(const char *path, int walk_flags, + int (*func)(const char *, const struct stat *, int, + void *), void *arg, int depth) +{ + int (*xstat)(const char *, struct stat *) = lstat; + int flags = walk_flags, err; + struct entry_handle dir; + + /* + * If (walk_flags & WALK_TREE_PHYSICAL), do not traverse symlinks. + * If (walk_flags & WALK_TREE_LOGICAL), traverse all symlinks. + * Otherwise, traverse only top-level symlinks. + */ + if (depth == 0) + flags |= WALK_TREE_TOPLEVEL; + +follow_symlink: + if (xstat(path, &dir.st) != 0) + return func(path, NULL, flags | WALK_TREE_FAILED, arg); + if (S_ISLNK(dir.st.st_mode)) { + flags |= WALK_TREE_SYMLINK; + if (flags & WALK_TREE_DEREFERENCE) { + xstat = stat; + goto follow_symlink; + } + } + err = func(path, &dir.st, flags, arg); + if ((flags & WALK_TREE_RECURSIVE) && + (S_ISDIR(dir.st.st_mode) || (S_ISLNK(dir.st.st_mode))) && + (!(flags & WALK_TREE_PHYSICAL) || !(flags & WALK_TREE_SYMLINK)) && + (flags & (WALK_TREE_LOGICAL | WALK_TREE_TOPLEVEL))) { + struct entry_handle *i; + struct dirent *entry; + + /* Check if we have already visited this directory. */ + for (i = head.next; i != &head; i = i->next) + if (i->st.st_dev == dir.st.st_dev && + i->st.st_ino == dir.st.st_ino) + return err; + + if (num_dir_handles == 0 && closed->prev != &head) { +close_another_dir: + /* Close the topmost directory handle still open. */ + closed = closed->prev; + closed->pos = telldir(closed->stream); + closedir(closed->stream); + closed->stream = NULL; + num_dir_handles++; + } + + dir.stream = opendir(path); + if (!dir.stream) { + if (errno == ENFILE && closed->prev != &head) { + /* Ran out of file descriptors. */ + num_dir_handles = 0; + goto close_another_dir; + } + + /* + * PATH may be a symlink to a regular file, or a dead + * symlink which we didn't follow above. + */ + if (errno != ENOTDIR && errno != ENOENT) + err += func(path, &dir.st, + flags | WALK_TREE_FAILED, arg); + return err; + } + + /* Insert into the list of handles. */ + dir.next = head.next; + dir.prev = &head; + dir.prev->next = &dir; + dir.next->prev = &dir; + num_dir_handles--; + + while ((entry = readdir(dir.stream)) != NULL) { + char *path_end; + + if (!strcmp(entry->d_name, ".") || + !strcmp(entry->d_name, "..")) + continue; + path_end = strchr(path, 0); + if ((path_end - path) + strlen(entry->d_name) + 1 >= + FILENAME_MAX) { + errno = ENAMETOOLONG; + err += func(path, NULL, + flags | WALK_TREE_FAILED, arg); + continue; + } + *path_end++ = '/'; + strcpy(path_end, entry->d_name); + err += walk_tree_rec(path, walk_flags, func, arg, + depth + 1); + *--path_end = 0; + if (!dir.stream) { + /* Reopen the directory handle. */ + dir.stream = opendir(path); + if (!dir.stream) + return err + func(path, &dir.st, flags | + WALK_TREE_FAILED, arg); + seekdir(dir.stream, dir.pos); + + closed = closed->next; + num_dir_handles--; + } + } + + if (closedir(dir.stream) != 0) + err += func(path, &dir.st, flags | WALK_TREE_FAILED, + arg); + + /* Remove from the list of handles. */ + dir.prev->next = dir.next; + dir.next->prev = dir.prev; + num_dir_handles++; + } + return err; +} + +int walk_tree(const char *path, int walk_flags, unsigned int num, + int (*func)(const char *, const struct stat *, int, void *), + void *arg) +{ + char path_copy[FILENAME_MAX]; + + num_dir_handles = num; + if (num_dir_handles < 1) { + struct rlimit rlimit; + + num_dir_handles = 1; + if (getrlimit(RLIMIT_NOFILE, &rlimit) == 0 && + rlimit.rlim_cur >= 2) + num_dir_handles = rlimit.rlim_cur / 2; + } + if (strlen(path) >= FILENAME_MAX) { + errno = ENAMETOOLONG; + return func(path, NULL, WALK_TREE_FAILED, arg); + } + strcpy(path_copy, path); + return walk_tree_rec(path_copy, walk_flags, func, arg, 0); +} --Boundary-00=_A3MJH2/pbEYYK1y Content-Type: text/x-diff; charset="us-ascii"; name="walk-attr.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="walk-attr.diff" SW5kZXg6IGF0dHItMi40LjM5L2dldGZhdHRyL2dldGZhdHRyLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gYXR0ci0yLjQuMzkub3JpZy9nZXRmYXR0 ci9nZXRmYXR0ci5jCisrKyBhdHRyLTIuNC4zOS9nZXRmYXR0ci9nZXRmYXR0 ci5jCkBAIC0yOCwxMSArMjgsMTEgQEAKICNpbmNsdWRlIDxjdHlwZS5oPgog I2luY2x1ZGUgPGdldG9wdC5oPgogI2luY2x1ZGUgPHJlZ2V4Lmg+Ci0jaW5j bHVkZSA8ZnR3Lmg+CiAjaW5jbHVkZSA8bG9jYWxlLmg+CiAKICNpbmNsdWRl IDxhdHRyL3hhdHRyLmg+CiAjaW5jbHVkZSAiY29uZmlnLmgiCisjaW5jbHVk ZSAid2Fsa190cmVlLmgiCiAjaW5jbHVkZSAibWlzYy5oIgogCiAjZGVmaW5l IENNRF9MSU5FX09QVElPTlMgIm46ZGU6bTpoUkxQIgpAQCAtNTQsMTEgKzU0 LDggQEAgc3RydWN0IG9wdGlvbiBsb25nX29wdGlvbnNbXSA9IHsKIAl7IE5V TEwsCQkJMCwgMCwgMCB9CiB9OwogCi1pbnQgb3B0X3JlY3Vyc2l2ZTsgIC8q IHJlY3Vyc2UgaW50byBzdWItZGlyZWN0b3JpZXM/ICovCi1pbnQgb3B0X3dh bGtfbG9naWNhbDsgIC8qIGFsd2F5cyBmb2xsb3cgc3ltYm9saWMgbGlua3Mg Ki8KLWludCBvcHRfd2Fsa19waHlzaWNhbDsgIC8qIG5ldmVyIGZvbGxvdyBz eW1ib2xpYyBsaW5rcyAqLworaW50IHdhbGtfZmxhZ3MgPSBXQUxLX1RSRUVf REVSRUZFUkVOQ0U7CiBpbnQgb3B0X2R1bXA7ICAvKiBkdW1wIGF0dHJpYnV0 ZSB2YWx1ZXMgKG9yIG9ubHkgbGlzdCB0aGUgbmFtZXMpICovCi1pbnQgb3B0 X2RlcmVmID0gMTsgIC8qIGRlcmVmZXJlbmNlIHN5bWJvbGljIGxpbmtzICov CiBjaGFyICpvcHRfbmFtZTsgIC8qIGR1bXAgbmFtZWQgYXR0cmlidXRlcyAq LwogY2hhciAqb3B0X25hbWVfcGF0dGVybiA9ICJedXNlclxcLiI7ICAvKiBp bmNsdWRlIG9ubHkgbWF0Y2hpbmcgbmFtZXMgKi8KIGNoYXIgKm9wdF9lbmNv ZGluZzsgIC8qIGVuY29kZSB2YWx1ZXMgYXV0b21hdGljYWxseSAoTlVMTCks IG9yIGFzICJ0ZXh0IiwKQEAgLTg0LDEyICs4MSwxNCBAQCBzdGF0aWMgY29u c3QgY2hhciAqeHF1b3RlKGNvbnN0IGNoYXIgKnN0CiAKIGludCBkb19nZXR4 YXR0cihjb25zdCBjaGFyICpwYXRoLCBjb25zdCBjaGFyICpuYW1lLCB2b2lk ICp2YWx1ZSwgc2l6ZV90IHNpemUpCiB7Ci0JcmV0dXJuIChvcHRfZGVyZWYg PyBnZXR4YXR0ciA6IGxnZXR4YXR0cikocGF0aCwgbmFtZSwgdmFsdWUsIHNp emUpOworCXJldHVybiAoKHdhbGtfZmxhZ3MgJiBXQUxLX1RSRUVfREVSRUZF UkVOQ0UpID8KKwkJZ2V0eGF0dHIgOiBsZ2V0eGF0dHIpKHBhdGgsIG5hbWUs IHZhbHVlLCBzaXplKTsKIH0KIAogaW50IGRvX2xpc3R4YXR0cihjb25zdCBj aGFyICpwYXRoLCBjaGFyICpsaXN0LCBzaXplX3Qgc2l6ZSkKIHsKLQlyZXR1 cm4gKG9wdF9kZXJlZiA/IGxpc3R4YXR0ciA6IGxsaXN0eGF0dHIpKHBhdGgs IGxpc3QsIHNpemUpOworCXJldHVybiAoKHdhbGtfZmxhZ3MgJiBXQUxLX1RS RUVfREVSRUZFUkVOQ0UpID8KKwkJbGlzdHhhdHRyIDogbGxpc3R4YXR0ciko cGF0aCwgbGlzdCwgc2l6ZSk7CiB9CiAKIGNvbnN0IGNoYXIgKnN0cmVycm9y X2VhKGludCBlcnIpCkBAIC0zNDcsMjEgKzM0NiwxOSBAQCBpbnQgbGlzdF9h dHRyaWJ1dGVzKGNvbnN0IGNoYXIgKnBhdGgsIGluCiAJcmV0dXJuIDA7CiB9 CiAKLWludCBkb19wcmludChjb25zdCBjaGFyICpwYXRoLCBjb25zdCBzdHJ1 Y3Qgc3RhdCAqc3RhdCwKLSAgICAgICAgICAgICBpbnQgZmxhZywgc3RydWN0 IEZUVyAqZnR3KQoraW50IGRvX3ByaW50KGNvbnN0IGNoYXIgKnBhdGgsIGNv bnN0IHN0cnVjdCBzdGF0ICpzdGF0LCBpbnQgd2Fsa19mbGFncywgdm9pZCAq dW51c2VkKQogewotCWludCBzYXZlZF9lcnJubyA9IGVycm5vOwogCWludCBo ZWFkZXJfcHJpbnRlZCA9IDA7CiAKLQkvKgotCSAqIFByb2Nlc3MgdGhlIHRh cmdldCBvZiBhIHN5bWJvbGljIGxpbmssIGFuZCB0cmF2ZXJzZSB0aGUKLQkg KiBsaW5rLCBvbmx5IGlmIGRvaW5nIGEgbG9naWNhbCB3YWxrLCBvciBpZiB0 aGUgc3ltYm9saWMgbGluawotCSAqIHdhcyBzcGVjaWZpZWQgb24gdGhlIGNv bW1hbmQgbGluZS4gQWx3YXlzIHNraXAgc3ltYm9saWMKLQkgKiBsaW5rcyBp ZiBkb2luZyBhIHBoeXNpY2FsIHdhbGsuCi0JICovCisJaWYgKHdhbGtfZmxh Z3MgJiBXQUxLX1RSRUVfRkFJTEVEKSB7CisJCWZwcmludGYoc3RkZXJyLCAi JXM6ICVzOiAlc1xuIiwgcHJvZ25hbWUsIHhxdW90ZShwYXRoKSwgc3RyZXJy b3IoZXJybm8pKTsKKwkJcmV0dXJuIDE7CisJfQogCi0JaWYgKFNfSVNMTkso c3RhdC0+c3RfbW9kZSkgJiYKLQkgICAgKG9wdF93YWxrX3BoeXNpY2FsIHx8 IChmdHctPmxldmVsID4gMCAmJiAhb3B0X3dhbGtfbG9naWNhbCkpKQorCWlm ICgod2Fsa19mbGFncyAmIFdBTEtfVFJFRV9TWU1MSU5LKSAmJgorCSAgICAo d2Fsa19mbGFncyAmIFdBTEtfVFJFRV9ERVJFRkVSRU5DRSkgJiYKKwkgICAg KCh3YWxrX2ZsYWdzICYgV0FMS19UUkVFX1BIWVNJQ0FMKSB8fAorCSAgICAh KHdhbGtfZmxhZ3MgJiAoV0FMS19UUkVFX1RPUExFVkVMIHwgV0FMS19UUkVF X0xPR0lDQUwpKSkpCiAJCXJldHVybiAwOwogCiAJaWYgKG9wdF9uYW1lKQpA QCAtMzcxLDIxICszNjgsNiBAQCBpbnQgZG9fcHJpbnQoY29uc3QgY2hhciAq cGF0aCwgY29uc3Qgc3RyCiAKIAlpZiAoaGVhZGVyX3ByaW50ZWQpCiAJCXB1 dHMoIiIpOwotCi0JaWYgKGZsYWcgPT0gRlRXX0ROUiAmJiBvcHRfcmVjdXJz aXZlKSB7Ci0JCS8qIEl0ZW0gaXMgYSBkaXJlY3Rvcnkgd2hpY2ggY2FuJ3Qg YmUgcmVhZC4gKi8KLQkJZnByaW50ZihzdGRlcnIsICIlczogJXM6ICVzXG4i LCBwcm9nbmFtZSwgeHF1b3RlKHBhdGgpLAotCQkJc3RyZXJyb3Ioc2F2ZWRf ZXJybm8pKTsKLQkJcmV0dXJuIDA7Ci0JfQotCi0JLyoKLQkgKiBXZSBhbHNv IGdldCBoZXJlIGluIG5vbi1yZWN1cnNpdmUgbW9kZS4gSW4gdGhhdCBjYXNl LAotCSAqICByZXR1cm4gc29tZXRoaW5nICE9IDAgdG8gYWJvcnQgbmZ0dy4K LQkgKi8KLQotCWlmICghb3B0X3JlY3Vyc2l2ZSkKLQkJcmV0dXJuIDE7CiAJ cmV0dXJuIDA7CiB9CiAKQEAgLTQxMCwzOSArMzkyLDYgQEAgdm9pZCBoZWxw KHZvaWQpCiAiICAgICAgLS1oZWxwICAgICAgICAgICAgICB0aGlzIGhlbHAg dGV4dFxuIikpOwogfQogCi1jaGFyICpyZXNvbHZlX3N5bWxpbmtzKGNvbnN0 IGNoYXIgKmZpbGUpCi17Ci0Jc3RhdGljIGNoYXIgYnVmZmVyWzQwOTZdOwot CXN0cnVjdCBzdGF0IHN0YXQ7Ci0JY2hhciAqcGF0aCA9IE5VTEw7Ci0KLQlp ZiAobHN0YXQoZmlsZSwgJnN0YXQpID09IC0xKQotCQlyZXR1cm4gcGF0aDsK LQotCWlmIChTX0lTTE5LKHN0YXQuc3RfbW9kZSkgJiYgIW9wdF93YWxrX3Bo eXNpY2FsKQotCQlwYXRoID0gcmVhbHBhdGgoZmlsZSwgYnVmZmVyKTsKLQll bHNlCi0JCXBhdGggPSAoY2hhciAqKWZpbGU7ICAgIC8qIG5vdCBhIHN5bWxp bmssIHVzZSBnaXZlbiBwYXRoICovCi0KLQlyZXR1cm4gcGF0aDsKLX0KLQot aW50IHdhbGtfdHJlZShjb25zdCBjaGFyICpmaWxlKQotewotCWNvbnN0IGNo YXIgKnA7Ci0KLQlpZiAoKHAgPSByZXNvbHZlX3N5bWxpbmtzKGZpbGUpKSA9 PSBOVUxMKSB7Ci0JCWZwcmludGYoc3RkZXJyLCAiJXM6ICVzOiAlc1xuIiwg cHJvZ25hbWUsCi0JCQl4cXVvdGUoZmlsZSksIHN0cmVycm9yKGVycm5vKSk7 Ci0JCXJldHVybiAxOwotCX0gZWxzZSBpZiAobmZ0dyhwLCBkb19wcmludCwg MCwgb3B0X3dhbGtfbG9naWNhbD8gMCA6IEZUV19QSFlTKSA8IDApIHsKLQkJ ZnByaW50ZihzdGRlcnIsICIlczogJXM6ICVzXG4iLCBwcm9nbmFtZSwgeHF1 b3RlKGZpbGUpLAotCQkJc3RyZXJyb3IoZXJybm8pKTsKLQkJcmV0dXJuIDE7 Ci0JfQotCXJldHVybiAwOwotfQotCiBpbnQgbWFpbihpbnQgYXJnYywgY2hh ciAqYXJndltdKQogewogCWludCBvcHQ7CkBAIC00NzgsNyArNDI3LDcgQEAg aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKIAkJCQlyZXR1cm4g MDsKIAogCQkJY2FzZSAnaCc6IC8qIGRvIG5vdCBkZXJlZmVyZW5jZSBzeW1s aW5rcyAqLwotCQkJCW9wdF9kZXJlZiA9IDA7CisJCQkJd2Fsa19mbGFncyAm PSB+V0FMS19UUkVFX0RFUkVGRVJFTkNFOwogCQkJCWJyZWFrOwogCiAJCQlj YXNlICduJzogIC8qIGdldCBuYW1lZCBhdHRyaWJ1dGUgKi8KQEAgLTQ5Nywx NyArNDQ2LDE3IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10p CiAJCQkJYnJlYWs7CiAKIAkJCWNhc2UgJ0wnOgotCQkJCW9wdF93YWxrX2xv Z2ljYWwgPSAxOwotCQkJCW9wdF93YWxrX3BoeXNpY2FsID0gMDsKKwkJCQl3 YWxrX2ZsYWdzIHw9IFdBTEtfVFJFRV9MT0dJQ0FMOworCQkJCXdhbGtfZmxh Z3MgJj0gfldBTEtfVFJFRV9QSFlTSUNBTDsKIAkJCQlicmVhazsKIAogCQkJ Y2FzZSAnUCc6Ci0JCQkJb3B0X3dhbGtfbG9naWNhbCA9IDA7Ci0JCQkJb3B0 X3dhbGtfcGh5c2ljYWwgPSAxOworCQkJCXdhbGtfZmxhZ3MgfD0gV0FMS19U UkVFX1BIWVNJQ0FMOworCQkJCXdhbGtfZmxhZ3MgJj0gfldBTEtfVFJFRV9M T0dJQ0FMOwogCQkJCWJyZWFrOwogCiAJCQljYXNlICdSJzoKLQkJCQlvcHRf cmVjdXJzaXZlID0gMTsKKwkJCQl3YWxrX2ZsYWdzIHw9IFdBTEtfVFJFRV9S RUNVUlNJVkU7CiAJCQkJYnJlYWs7CiAKIAkJCWNhc2UgJ1YnOgpAQCAtNTMx LDcgKzQ4MCw4IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10p CiAJfQogCiAJd2hpbGUgKG9wdGluZCA8IGFyZ2MpIHsKLQkJaGFkX2Vycm9y cyArPSB3YWxrX3RyZWUoYXJndltvcHRpbmRdKTsKKwkJaGFkX2Vycm9ycyAr PSB3YWxrX3RyZWUoYXJndltvcHRpbmRdLCB3YWxrX2ZsYWdzLCAwLAorCQkJ CQlkb19wcmludCwgTlVMTCk7CiAJCW9wdGluZCsrOwogCX0KIApJbmRleDog YXR0ci0yLjQuMzkvbGlibWlzYy9NYWtlZmlsZQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBhdHRyLTIuNC4zOS5vcmlnL2xpYm1pc2MvTWFrZWZpbGUK KysrIGF0dHItMi40LjM5L2xpYm1pc2MvTWFrZWZpbGUKQEAgLTgsNyArOCw3 IEBAIGluY2x1ZGUgJChUT1BESVIpL2luY2x1ZGUvYnVpbGRkZWZzCiBMVExJ QlJBUlkgPSBsaWJtaXNjLmxhCiBMVExERkxBR1MgPQogCi1DRklMRVMgPSBx dW90ZS5jIHVucXVvdGUuYyBoaWdoX3dhdGVyX2FsbG9jLmMgbmV4dF9saW5l LmMKK0NGSUxFUyA9IHF1b3RlLmMgdW5xdW90ZS5jIGhpZ2hfd2F0ZXJfYWxs b2MuYyBuZXh0X2xpbmUuYyB3YWxrX3RyZWUuYwogCiBkZWZhdWx0OiAkKExU TElCUkFSWSkKIGluc3RhbGwgaW5zdGFsbC1kZXYgaW5zdGFsbC1saWI6Cklu ZGV4OiBhdHRyLTIuNC4zOS90ZXN0L2F0dHIudGVzdAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBhdHRyLTIuNC4zOS5vcmlnL3Rlc3QvYXR0ci50ZXN0 CisrKyBhdHRyLTIuNC4zOS90ZXN0L2F0dHIudGVzdApAQCAtMTAsNiArMTAs OSBAQCBFeGVjdXRlIHRoaXMgdGVzdCB1c2luZyB0aGUgYHJ1bicgc2NyaXB0 CiAKIFRyeSB2YXJpb3VzIHZhbGlkIGFuZCBpbnZhbGlkIG5hbWVzCiAJCisJ JCBta2RpciBkCisJJCBjZCBkCisKIAkkIHRvdWNoIGYKIAkkIHNldGZhdHRy IC1uIHVzZXIgLXYgdmFsdWUgZgogCT4gc2V0ZmF0dHI6IGY6IE9wZXJhdGlv biBub3Qgc3VwcG9ydGVkCkBAIC0yOSw4ICszMiw4IEBAIFRyeSB2YXJpb3Vz IHZhbGlkIGFuZCBpbnZhbGlkIG5hbWVzCiBTaXplIGNoZWNrcywgZm9yIGFu IGV4dDIvZXh0MyBmaWxlIHN5c3RlbSB3aXRoIGEgYmxvY2sgc2l6ZSBvZiA0 SwogCiAJJCB0b3VjaCBmCi0JJCBzZXRmYXR0ciAtbiB1c2VyLm5hbWUgLXYg NDA0MCsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysgZgotCSQgc2V0ZmF0 dHIgLW4gdXNlci5uYW1lIC12IDQwNDErKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKyBmCisJJCBzZXRmYXR0ciAtbiB1c2VyLm5hbWUgLXYgNDA0MCsr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrIGYKKwkkIHNldGZhdHRyIC1u IHVzZXIubmFtZSAtdiA0MDQxKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysgZgogCT4gc2V0ZmF0dHI6IGY6IE5vIHNwYWNlIGxlZnQgb24gZGV2 aWNlCiAJCiAJJCBybSBmCkBAIC04NiwxMyArODksNiBAQCBWYWx1ZSBlbmNv ZGluZ3MKIAk+IHVzZXIubmFtZTM9MHMzdnJPCiAJPiAKIAkKLQkkIGdldGZh dHRyIC1kIC1lIHRleHQgZgotCT4gIyBmaWxlOiBmCi0JPiB1c2VyLm5hbWU9 Irq+IgotCT4gdXNlci5uYW1lMj0i3q2+7yIKLQk+IHVzZXIubmFtZTM9It76 ziIKLQk+IAotCQogCSQgcm0gZgogCiBFdmVyeXRoaW5nIHdpdGggb25lIGZp bGUKQEAgLTEwNSw3ICsxMDEsNyBAQCBFdmVyeXRoaW5nIHdpdGggb25lIGZp bGUKIAkkIHNldGZhdHRyIC1uIHVzZXIuc2hvcnQgLXYgdmFsdWUgZgogCSQg c2V0ZmF0dHIgLW4gdXNlci5ub3ZhbHVlLXlldCBmCiAJJCBscyAtcyBmCi0J PiAgICA0IGYKKwk+IDQgZgogCQogCSQgZ2V0ZmF0dHIgLWQgZgogCT4gIyBm aWxlOiBmCkBAIC0xNDMsNyArMTM5LDcgQEAgRXZlcnl0aGluZyB3aXRoIG9u ZSBmaWxlCiAJJCBzZXRmYXR0ciAteCB1c2VyLm5vdmFsdWUteWV0IGYKIAkk IGdldGZhdHRyIC1kIGYKIAkkIGxzIC1zIGYKLQk+ICAgIDAgZgorCT4gMCBm CiAJCiAJJCBybSBmCiAKQEAgLTE1MiwxNSArMTQ4LDE1IEBAIFRlc3QgZXh0 ZW5kZWQgYXR0cmlidXRlIGJsb2NrIHNoYXJpbmcKIAkkIHRvdWNoIGYgZyBo CiAJJCBzZXRmYXR0ciAtbiB1c2VyLm5vdmFsdWUgZiBnIGgKIAkkIGxzIC1z IGYgZyBoCi0JPiAgICA0IGYKLQk+ICAgIDQgZwotCT4gICAgNCBoCisJPiA0 IGYKKwk+IDQgZworCT4gNCBoCiAJCiAJJCBzZXRmYXR0ciAtbiB1c2VyLm5h bWUgLXYgdmFsdWUgZgogCSQgbHMgLXMgZiBnIGgKLQk+ICAgIDQgZgotCT4g ICAgNCBnCi0JPiAgICA0IGgKKwk+IDQgZgorCT4gNCBnCisJPiA0IGgKIAkK IAkkIGdldGZhdHRyIC1kIGYgZyBoCiAJPiAjIGZpbGU6IGYKQEAgLTE3Niwx NSArMTcyLDE1IEBAIFRlc3QgZXh0ZW5kZWQgYXR0cmlidXRlIGJsb2NrIHNo YXJpbmcKIAkKIAkkIHNldGZhdHRyIC1uIHVzZXIubmFtZSAtdiB2YWx1ZSBn CiAJJCBscyAtcyBmIGcgaAotCT4gICAgNCBmCi0JPiAgICA0IGcKLQk+ICAg IDQgaAorCT4gNCBmCisJPiA0IGcKKwk+IDQgaAogCQogCSQgc2V0ZmF0dHIg LXggdXNlci5ub3ZhbHVlIGgKIAkkIGxzIC1zIGYgZyBoCi0JPiAgICA0IGYK LQk+ICAgIDQgZwotCT4gICAgMCBoCisJPiA0IGYKKwk+IDQgZworCT4gMCBo CiAJCiAJJCBnZXRmYXR0ciAtZCBmIGcgaAogCT4gIyBmaWxlOiBmCkBAIC0y MDEsOSArMTk3LDkgQEAgVGVzdCBleHRlbmRlZCBhdHRyaWJ1dGUgYmxvY2sg c2hhcmluZwogCSQgc2V0ZmF0dHIgLXggdXNlci5uYW1lIGYgZwogCSQgc2V0 ZmF0dHIgLXggdXNlci5ub3ZhbHVlIGYgZwogCSQgbHMgLXMgZiBnIGgKLQk+ ICAgIDAgZgotCT4gICAgMCBnCi0JPiAgICAwIGgKKwk+IDAgZgorCT4gMCBn CisJPiAwIGgKIAkKIAkkIHJtIGYgZyBoCiAKQEAgLTI2MCw2ICsyNTYsNSBA QCBUZXN0cyBmb3IgYXR0cmlidXRlIG5hbWVzIHRoYXQgY29udGFpbnMgCiAJ JCBzZXRmYXR0ciAteCAidXNlci5zcGVjaWFsXFwwMDciIGYKIAkkIHJtIGYK IAotU29tZSBQT1NJWCBBQ0wgdGVzdHMuLi4KLQotCSQgdG91Y2ggZgorCSQg Y2QgLi4KKwkkIHJtIC1yZiBkCkluZGV4OiBhdHRyLTIuNC4zOS9pbmNsdWRl L3dhbGtfdHJlZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIC9kZXYv bnVsbAorKysgYXR0ci0yLjQuMzkvaW5jbHVkZS93YWxrX3RyZWUuaApAQCAt MCwwICsxLDE5IEBACisjaWZuZGVmIF9fV0FMS19UUkVFX0gKKyNkZWZpbmUg X19XQUxLX1RSRUVfSAorCisjZGVmaW5lIFdBTEtfVFJFRV9SRUNVUlNJVkUJ MHgxCisjZGVmaW5lIFdBTEtfVFJFRV9QSFlTSUNBTAkweDIKKyNkZWZpbmUg V0FMS19UUkVFX0xPR0lDQUwJMHg0CisjZGVmaW5lIFdBTEtfVFJFRV9ERVJF RkVSRU5DRQkweDgKKworI2RlZmluZSBXQUxLX1RSRUVfVE9QTEVWRUwJMHgx MDAKKyNkZWZpbmUgV0FMS19UUkVFX1NZTUxJTksJMHgyMDAKKyNkZWZpbmUg V0FMS19UUkVFX0ZBSUxFRAkweDQwMAorCitzdHJ1Y3Qgc3RhdDsKKworZXh0 ZXJuIGludCB3YWxrX3RyZWUoY29uc3QgY2hhciAqcGF0aCwgaW50IHdhbGtf ZmxhZ3MsIHVuc2lnbmVkIGludCBudW0sCisJCSAgICAgaW50ICgqZnVuYyko Y29uc3QgY2hhciAqLCBjb25zdCBzdHJ1Y3Qgc3RhdCAqLCBpbnQsCisJCQkJ IHZvaWQgKiksIHZvaWQgKmFyZyk7CisKKyNlbmRpZgpJbmRleDogYXR0ci0y LjQuMzkvbGlibWlzYy93YWxrX3RyZWUuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSAvZGV2L251bGwKKysrIGF0dHItMi40LjM5L2xpYm1pc2Mvd2Fs a190cmVlLmMKQEAgLTAsMCArMSwxODggQEAKKy8qCisgIEZpbGU6IHdhbGtf dHJlZS5jCisKKyAgQ29weXJpZ2h0IChDKSAyMDA3IEFuZHJlYXMgR3J1ZW5i YWNoZXIgPGEuZ3J1ZW5iYWNoZXJAY29tcHV0ZXIub3JnPgorCisgIFRoaXMg cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0 ZSBpdCBhbmQvb3IKKyAgbW9kaWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0 aGUgR05VIExpYnJhcnkgR2VuZXJhbCBQdWJsaWMKKyAgTGljZW5zZSBhcyBw dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0 aGVyCisgIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIg b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KKworICBUaGlzIHByb2dyYW0g aXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVz ZWZ1bCwKKyAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2 ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKyAgTUVSQ0hBTlRBQklMSVRZ IG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRo ZSBHTlUKKyAgTGlicmFyeSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBt b3JlIGRldGFpbHMuCisKKyAgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEg Y29weSBvZiB0aGUgR05VIExpYnJhcnkgR2VuZXJhbCBQdWJsaWMKKyAgTGlj ZW5zZSBhbG9uZyB3aXRoIHRoaXMgbGlicmFyeTsgaWYgbm90LCB3cml0ZSB0 byB0aGUgRnJlZSBTb2Z0d2FyZQorICBGb3VuZGF0aW9uLCBJbmMuLCA1OSBU ZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEtMTMw NywgVVNBLgorKi8KKworI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1 ZGUgPHN5cy9zdGF0Lmg+CisjaW5jbHVkZSA8dW5pc3RkLmg+CisjaW5jbHVk ZSA8c3lzL3RpbWUuaD4KKyNpbmNsdWRlIDxzeXMvcmVzb3VyY2UuaD4KKyNp bmNsdWRlIDxkaXJlbnQuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1 ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGVycm5vLmg+CisKKyNpbmNsdWRl ICJ3YWxrX3RyZWUuaCIKKworc3RydWN0IGVudHJ5X2hhbmRsZSB7CisJc3Ry dWN0IGVudHJ5X2hhbmRsZSAqcHJldiwgKm5leHQ7CisJc3RydWN0IHN0YXQg c3Q7CisJRElSICpzdHJlYW07CisJb2ZmX3QgcG9zOworfTsKKworc3RydWN0 IGVudHJ5X2hhbmRsZSBoZWFkID0geworCS5uZXh0ID0gJmhlYWQsCisJLnBy ZXYgPSAmaGVhZCwKKwkvKiBUaGUgb3RoZXIgZmllbGRzIGFyZSB1bnVzZWQu ICovCit9Oworc3RydWN0IGVudHJ5X2hhbmRsZSAqY2xvc2VkID0gJmhlYWQ7 Cit1bnNpZ25lZCBpbnQgbnVtX2Rpcl9oYW5kbGVzOworCitzdGF0aWMgaW50 IHdhbGtfdHJlZV9yZWMoY29uc3QgY2hhciAqcGF0aCwgaW50IHdhbGtfZmxh Z3MsCisJCQkgaW50ICgqZnVuYykoY29uc3QgY2hhciAqLCBjb25zdCBzdHJ1 Y3Qgc3RhdCAqLCBpbnQsCisJCQkgCSAgICAgdm9pZCAqKSwgdm9pZCAqYXJn LCBpbnQgZGVwdGgpCit7CisJaW50ICgqeHN0YXQpKGNvbnN0IGNoYXIgKiwg c3RydWN0IHN0YXQgKikgPSBsc3RhdDsKKwlpbnQgZmxhZ3MgPSB3YWxrX2Zs YWdzLCBlcnI7CisJc3RydWN0IGVudHJ5X2hhbmRsZSBkaXI7CisKKwkvKgor CSAqIElmICh3YWxrX2ZsYWdzICYgV0FMS19UUkVFX1BIWVNJQ0FMKSwgZG8g bm90IHRyYXZlcnNlIHN5bWxpbmtzLgorCSAqIElmICh3YWxrX2ZsYWdzICYg V0FMS19UUkVFX0xPR0lDQUwpLCB0cmF2ZXJzZSBhbGwgc3ltbGlua3MuCisJ ICogT3RoZXJ3aXNlLCB0cmF2ZXJzZSBvbmx5IHRvcC1sZXZlbCBzeW1saW5r cy4KKwkgKi8KKwlpZiAoZGVwdGggPT0gMCkKKwkJZmxhZ3MgfD0gV0FMS19U UkVFX1RPUExFVkVMOworCitmb2xsb3dfc3ltbGluazoKKwlpZiAoeHN0YXQo cGF0aCwgJmRpci5zdCkgIT0gMCkKKwkJcmV0dXJuIGZ1bmMocGF0aCwgTlVM TCwgZmxhZ3MgfCBXQUxLX1RSRUVfRkFJTEVELCBhcmcpOworCWlmIChTX0lT TE5LKGRpci5zdC5zdF9tb2RlKSkgeworCQlmbGFncyB8PSBXQUxLX1RSRUVf U1lNTElOSzsKKwkJaWYgKGZsYWdzICYgV0FMS19UUkVFX0RFUkVGRVJFTkNF KSB7CisJCQl4c3RhdCA9IHN0YXQ7CisJCQlnb3RvIGZvbGxvd19zeW1saW5r OworCQl9CisJfQorCWVyciA9IGZ1bmMocGF0aCwgJmRpci5zdCwgZmxhZ3Ms IGFyZyk7CisJaWYgKChmbGFncyAmIFdBTEtfVFJFRV9SRUNVUlNJVkUpICYm CisJICAgIChTX0lTRElSKGRpci5zdC5zdF9tb2RlKSB8fCAoU19JU0xOSyhk aXIuc3Quc3RfbW9kZSkpKSAmJgorCSAgICAoIShmbGFncyAmIFdBTEtfVFJF RV9QSFlTSUNBTCkgfHwgIShmbGFncyAmIFdBTEtfVFJFRV9TWU1MSU5LKSkg JiYKKwkgICAgKGZsYWdzICYgKFdBTEtfVFJFRV9MT0dJQ0FMIHwgV0FMS19U UkVFX1RPUExFVkVMKSkpIHsKKwkJc3RydWN0IGVudHJ5X2hhbmRsZSAqaTsK KwkJc3RydWN0IGRpcmVudCAqZW50cnk7CisKKwkJLyogQ2hlY2sgaWYgd2Ug aGF2ZSBhbHJlYWR5IHZpc2l0ZWQgdGhpcyBkaXJlY3RvcnkuICovCisJCWZv ciAoaSA9IGhlYWQubmV4dDsgaSAhPSAmaGVhZDsgaSA9IGktPm5leHQpCisJ CQlpZiAoaS0+c3Quc3RfZGV2ID09IGRpci5zdC5zdF9kZXYgJiYKKwkJCSAg ICBpLT5zdC5zdF9pbm8gPT0gZGlyLnN0LnN0X2lubykKKwkJCQlyZXR1cm4g ZXJyOworCisJCWlmIChudW1fZGlyX2hhbmRsZXMgPT0gMCAmJiBjbG9zZWQt PnByZXYgIT0gJmhlYWQpIHsKK2Nsb3NlX2Fub3RoZXJfZGlyOgorCQkJLyog Q2xvc2UgdGhlIHRvcG1vc3QgZGlyZWN0b3J5IGhhbmRsZSBzdGlsbCBvcGVu LiAqLworCQkJY2xvc2VkID0gY2xvc2VkLT5wcmV2OworCQkJY2xvc2VkLT5w b3MgPSB0ZWxsZGlyKGNsb3NlZC0+c3RyZWFtKTsKKwkJCWNsb3NlZGlyKGNs b3NlZC0+c3RyZWFtKTsKKwkJCWNsb3NlZC0+c3RyZWFtID0gTlVMTDsKKwkJ CW51bV9kaXJfaGFuZGxlcysrOworCQl9CisKKwkJZGlyLnN0cmVhbSA9IG9w ZW5kaXIocGF0aCk7CisJCWlmICghZGlyLnN0cmVhbSkgeworCQkJaWYgKGVy cm5vID09IEVORklMRSAmJiBjbG9zZWQtPnByZXYgIT0gJmhlYWQpIHsKKwkJ CQkvKiBSYW4gb3V0IG9mIGZpbGUgZGVzY3JpcHRvcnMuICovCisJCQkJbnVt X2Rpcl9oYW5kbGVzID0gMDsKKwkJCQlnb3RvIGNsb3NlX2Fub3RoZXJfZGly OworCQkJfQorCisJCQkvKgorCQkJICogUEFUSCBtYXkgYmUgYSBzeW1saW5r IHRvIGEgcmVndWxhciBmaWxlLCBvciBhIGRlYWQKKwkJCSAqIHN5bWxpbmsg d2hpY2ggd2UgZGlkbid0IGZvbGxvdyBhYm92ZS4KKwkJCSAqLworCQkJaWYg KGVycm5vICE9IEVOT1RESVIgJiYgZXJybm8gIT0gRU5PRU5UKQorCQkJCWVy ciArPSBmdW5jKHBhdGgsICZkaXIuc3QsCisJCQkJCSAgICBmbGFncyB8IFdB TEtfVFJFRV9GQUlMRUQsIGFyZyk7CisJCQlyZXR1cm4gZXJyOworCQl9CisK KwkJLyogSW5zZXJ0IGludG8gdGhlIGxpc3Qgb2YgaGFuZGxlcy4gKi8KKwkJ ZGlyLm5leHQgPSBoZWFkLm5leHQ7CisJCWRpci5wcmV2ID0gJmhlYWQ7CisJ CWRpci5wcmV2LT5uZXh0ID0gJmRpcjsKKwkJZGlyLm5leHQtPnByZXYgPSAm ZGlyOworCQludW1fZGlyX2hhbmRsZXMtLTsKKworCQl3aGlsZSAoKGVudHJ5 ID0gcmVhZGRpcihkaXIuc3RyZWFtKSkgIT0gTlVMTCkgeworCQkJY2hhciAq cGF0aF9lbmQ7CisKKwkJCWlmICghc3RyY21wKGVudHJ5LT5kX25hbWUsICIu IikgfHwKKwkJCSAgICAhc3RyY21wKGVudHJ5LT5kX25hbWUsICIuLiIpKQor CQkJCWNvbnRpbnVlOworCQkJcGF0aF9lbmQgPSBzdHJjaHIocGF0aCwgMCk7 CisJCQlpZiAoKHBhdGhfZW5kIC0gcGF0aCkgKyBzdHJsZW4oZW50cnktPmRf bmFtZSkgKyAxID49CisJCQkgICAgRklMRU5BTUVfTUFYKSB7CisJCQkJZXJy bm8gPSBFTkFNRVRPT0xPTkc7CisJCQkJZXJyICs9IGZ1bmMocGF0aCwgTlVM TCwKKwkJCQkJICAgIGZsYWdzIHwgV0FMS19UUkVFX0ZBSUxFRCwgYXJnKTsK KwkJCQljb250aW51ZTsKKwkJCX0KKwkJCSpwYXRoX2VuZCsrID0gJy8nOwor CQkJc3RyY3B5KHBhdGhfZW5kLCBlbnRyeS0+ZF9uYW1lKTsKKwkJCWVyciAr PSB3YWxrX3RyZWVfcmVjKHBhdGgsIHdhbGtfZmxhZ3MsIGZ1bmMsIGFyZywK KwkJCQkJICAgICBkZXB0aCArIDEpOworCQkJKi0tcGF0aF9lbmQgPSAwOwor CQkJaWYgKCFkaXIuc3RyZWFtKSB7CisJCQkJLyogUmVvcGVuIHRoZSBkaXJl Y3RvcnkgaGFuZGxlLiAqLworCQkJCWRpci5zdHJlYW0gPSBvcGVuZGlyKHBh dGgpOworCQkJCWlmICghZGlyLnN0cmVhbSkKKwkJCQkJcmV0dXJuIGVyciAr IGZ1bmMocGF0aCwgJmRpci5zdCwgZmxhZ3MgfAorCQkJCQkJICAgIFdBTEtf VFJFRV9GQUlMRUQsIGFyZyk7CisJCQkJc2Vla2RpcihkaXIuc3RyZWFtLCBk aXIucG9zKTsKKworCQkJCWNsb3NlZCA9IGNsb3NlZC0+bmV4dDsKKwkJCQlu dW1fZGlyX2hhbmRsZXMtLTsKKwkJCX0KKwkJfQorCisJCWlmIChjbG9zZWRp cihkaXIuc3RyZWFtKSAhPSAwKQorCQkJZXJyICs9IGZ1bmMocGF0aCwgJmRp ci5zdCwgZmxhZ3MgfCBXQUxLX1RSRUVfRkFJTEVELAorCQkJCSAgICBhcmcp OworCisJCS8qIFJlbW92ZSBmcm9tIHRoZSBsaXN0IG9mIGhhbmRsZXMuICov CisJCWRpci5wcmV2LT5uZXh0ID0gZGlyLm5leHQ7CisJCWRpci5uZXh0LT5w cmV2ID0gZGlyLnByZXY7CisJCW51bV9kaXJfaGFuZGxlcysrOworCX0KKwly ZXR1cm4gZXJyOworfQorCitpbnQgd2Fsa190cmVlKGNvbnN0IGNoYXIgKnBh dGgsIGludCB3YWxrX2ZsYWdzLCB1bnNpZ25lZCBpbnQgbnVtLAorCSAgICAg IGludCAoKmZ1bmMpKGNvbnN0IGNoYXIgKiwgY29uc3Qgc3RydWN0IHN0YXQg KiwgaW50LCB2b2lkICopLAorCSAgICAgIHZvaWQgKmFyZykKK3sKKwljaGFy IHBhdGhfY29weVtGSUxFTkFNRV9NQVhdOworCisJbnVtX2Rpcl9oYW5kbGVz ID0gbnVtOworCWlmIChudW1fZGlyX2hhbmRsZXMgPCAxKSB7CisJCXN0cnVj dCBybGltaXQgcmxpbWl0OworCisJCW51bV9kaXJfaGFuZGxlcyA9IDE7CisJ CWlmIChnZXRybGltaXQoUkxJTUlUX05PRklMRSwgJnJsaW1pdCkgPT0gMCAm JgorCQkgICAgcmxpbWl0LnJsaW1fY3VyID49IDIpCisJCQludW1fZGlyX2hh bmRsZXMgPSBybGltaXQucmxpbV9jdXIgLyAyOworCX0KKwlpZiAoc3RybGVu KHBhdGgpID49IEZJTEVOQU1FX01BWCkgeworCQllcnJubyA9IEVOQU1FVE9P TE9ORzsKKwkJcmV0dXJuIGZ1bmMocGF0aCwgTlVMTCwgV0FMS19UUkVFX0ZB SUxFRCwgYXJnKTsKKwl9CisJc3RyY3B5KHBhdGhfY29weSwgcGF0aCk7CisJ cmV0dXJuIHdhbGtfdHJlZV9yZWMocGF0aF9jb3B5LCB3YWxrX2ZsYWdzLCBm dW5jLCBhcmcsIDApOworfQpJbmRleDogYXR0ci0yLjQuMzkvdGVzdC9nZXRm YXR0ci50ZXN0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIC9kZXYvbnVs bAorKysgYXR0ci0yLjQuMzkvdGVzdC9nZXRmYXR0ci50ZXN0CkBAIC0wLDAg KzEsNTIgQEAKKwkkIG1rZGlyIGQKKwkkIGNkIGQKKworCSQgdG91Y2ggZgor CSQgc2V0ZmF0dHIgLW4gdXNlci50ZXN0IC12IHRlc3QgZgorCSQgbG4gLXMg ZiBsCisKK1RoaXMgY2FzZSBzaG91bGQgYmUgb2J2aW91czoKKwkkIGdldGZh dHRyIC1kIGYKKwk+ICMgZmlsZTogZgorCT4gdXNlci50ZXN0PSJ0ZXN0Igor CT4KKworSWYgYSBzeW1saW5rIGlzIGV4cGxpY2l0bHkgc3BlY2lmaWVkIG9u IHRoZSBjb21tYW5kIGxpbmUsIGZvbGxvdyBpdAorKC1IIGJlaGF2aW9yKToK KwkkIGdldGZhdHRyIC1kIGwKKwk+ICMgZmlsZTogbAorCT4gdXNlci50ZXN0 PSJ0ZXN0IgorCT4KKworVW5sZXNzIHdlIGFyZSBleHBsaWNpdGx5IHRvbGQg bm90IHRvIGRlcmVmZXJlbmNlIHN5bWxpbmtzOgorCSQgZ2V0ZmF0dHIgLWhk IGwKKworV2hlbiB3YWxraW5nIGEgdHJlZSwgaXQgZG9lcyBub3QgbWFrZSBz ZW5zZSB0byBmb2xsb3cgc3ltbGlua3MuIFdlIHNob3VsZAorb25seSBzZWUg ZidzIGF0dHJpYnV0ZXMgaGVyZSAtLSB0aGF0J3MgYSBidWc6CisJJCBnZXRm YXR0ciAtUmQgLgorCT4gIyBmaWxlOiBmCisJPiB1c2VyLnRlc3Q9InRlc3Qi CisJPgorCitUaGlzIGNhc2Ugd29ya3MgYXMgZXhwZWN0ZWQ6CisJJCBnZXRm YXR0ciAtUmhkIC4KKwk+ICMgZmlsZTogZgorCT4gdXNlci50ZXN0PSJ0ZXN0 IgorCT4KKworSW4gdGhlc2UgdHdvIGNhc2VzLCBnZXRmYXR0ciBzaG91bGQg ZGVyZWZlcmVuY2UgdGhlIHN5bWxpbmsgcGFzc2VkIG9uIHRoZQorY29tbWFu ZCBsaW5lLCBidXQgbm90IGwuIFRoaXMgZG9lc24ndCB3b3JrIGNvcnJlY3Rs eSwgZWl0aGVyOyBpdCdzIHRoZSBzYW1lCitidWc6CisJJCBsbiAtcyAuIGhl cmUKKwkkIGdldGZhdHRyIC1SZCBoZXJlCisJPiAjIGZpbGU6IGhlcmUvZgor CT4gdXNlci50ZXN0PSJ0ZXN0IgorCT4KKworCSQgZ2V0ZmF0dHIgLVJoZCBo ZXJlCisJPiAjIGZpbGU6IGhlcmUvZgorCT4gdXNlci50ZXN0PSJ0ZXN0Igor CT4KKworCSQgY2QgLi4KKwkkIHJtIC1yZiBkCg== --Boundary-00=_A3MJH2/pbEYYK1y-- From owner-xfs@oss.sgi.com Sun Oct 28 11:02:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 11:02:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, J_CHICKENPOX_72,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9SI21i8018117 for ; Sun, 28 Oct 2007 11:02:02 -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 D28CB22D4A; Sun, 28 Oct 2007 19:02:04 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: linux-xfs@oss.sgi.com, Timothy Shimmin Subject: acl and attr: libmisc linkage Date: Sun, 28 Oct 2007 19:04:04 +0100 User-Agent: KMail/1.9.5 Cc: Gerald Bringhurst , Brandon Philips MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710281904.04818.agruen@suse.de> X-Virus-Scanned: ClamAV 0.91.2/4614/Sun Oct 28 08:21:34 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13450 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs Hello, I noticed that in some cases, gcc is unhappy when libmisc.a is specified after libattr.so and libacl.so, and doesn't link in stuff from libmisc.a (specifically, walk_tree). I don't know the exact reason for this behavior, but putting libmisc.a before the dynamic libraries fixes the problem, i.e., like this: -LLDLIBS = $(LIBACL) $(LIBATTR) $(LIBMISC) -LTDEPENDENCIES = $(LIBACL) $(LIBMISC) +LLDLIBS = $(LIBMISC) $(LIBACL) $(LIBATTR) +LTDEPENDENCIES = $(LIBMISC) $(LIBACL) Is that acceptable? Thanks, Andreas From owner-xfs@oss.sgi.com Sun Oct 28 17:54:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 28 Oct 2007 17:55:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9T0srOQ026419 for ; Sun, 28 Oct 2007 17:54:56 -0700 Received: from [134.15.251.4] (melb-sw-corp-251-4.corp.sgi.com [134.15.251.4]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13632; Mon, 29 Oct 2007 11:54:50 +1100 Message-ID: <47252F62.6030503@sgi.com> Date: Mon, 29 Oct 2007 11:54:58 +1100 From: Tim Shimmin User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Roger Willcocks CC: xfs@oss.sgi.com Subject: Re: bug: truncate to zero + setuid References: <47249E7A.7060709@filmlight.ltd.uk> In-Reply-To: <47249E7A.7060709@filmlight.ltd.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4616/Sun Oct 28 10:25:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13451 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 Hi Roger, Roger Willcocks wrote: > The nfsv3 setattr call permits a simultaneous truncate + setuid/gid > operation. Normally XFS handles this fine, but if the file's being > truncated to zero, and the file's already empty, XFS simply ignores the > setuid/gid part, returning 'success'. > > The error's in xfs_vnodeops.c/xfs_setattr below the comment 'Short > circuit the truncate case for zero length files', which bypasses all > other changes. > > The simplest fix is to test whether this is the only change that's > happening, otherwise you get tangled in transactions. > > if (mask & XFS_AT_SIZE) { > /* Short circuit the truncate case for zero length files */ > - if ((vap->va_size == 0) && > + if (((mask & ~XFS_AT_SIZE) == 0) && (vap->va_size == 0) && > (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == 0)) { > > > -- > Roger > Yeah, I see your problem. It is interesting to know how much of multiple actions (different bits of mask) are supported. XFS_AT_UPDTIMES doesn't support anything else and will return quickly. As far as code which goes via error_return, it looks like the only non-error case is the short-circuit one mentioned above - truncating to zero an already zeroed file. I see your fix will get what we want although, it will mean that we will go thru the truncating path when we don't need to. It would be nice if we could act like the XFS_AT_SIZE was never set on the call in the case that other bits are set. Though when we first test the AT_SIZE, we don't have the inode locked. And I presume in that case we don't necessarily need to send a DMAPI truncate event? So I wonder if before the 1st AT_SIZE test that we have now, in the AT_SIZE case and with other bits set, we could lock the inode and test for the zero truncate of zero-len file and if so then remove the AT_SIZE bit and then go on to the other testing as if AT_SIZE was never set. Hmmm, may be that just complicates things too much. --Tim From owner-xfs@oss.sgi.com Mon Oct 29 00:56:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 00:57:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9T7utKA004659 for ; Mon, 29 Oct 2007 00:56:57 -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 SAA21597 for ; Mon, 29 Oct 2007 18:56:58 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9T7uvdD84049573 for ; Mon, 29 Oct 2007 18:56:58 +1100 (AEDT) Received: (from xaiki@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9T7uvCs85357075 for xfs@oss.sgi.com; Mon, 29 Oct 2007 18:56:57 +1100 (AEDT) Date: Mon, 29 Oct 2007 18:56:57 +1100 From: Niv Sardi To: xfs@oss.sgi.com Subject: Default mount options (that suck less). Message-ID: <20071029075657.GA84369978@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4616/Sun Oct 28 10:25:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13452 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Hello, XFS's default mount options are in most cases sub-optimal, we should try to have more sensible defaults, so far I'm following some quick dave-powered recomendations: - version 2 logs - attr2 - lazy superblock counters - less allocation groups for single disk configs - imaxpct default can be reduced it is currently 25, what would be reasonable ? - dropping the ability to turn unwritten extents off completely please submit your pet-idea for better defaults here. Cheers, -- Niv From owner-xfs@oss.sgi.com Mon Oct 29 01:55:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 01:55:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9T8t55v014478 for ; Mon, 29 Oct 2007 01:55:08 -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 TAA22772; Mon, 29 Oct 2007 19:55:04 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9T8t4dD83911638; Mon, 29 Oct 2007 19:55:04 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9T8t2DC85463963; Mon, 29 Oct 2007 19:55:02 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 29 Oct 2007 19:55:02 +1100 From: David Chinner To: Niv Sardi Cc: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071029085502.GI995458@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029075657.GA84369978@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4619/Mon Oct 29 01:23:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13453 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 On Mon, Oct 29, 2007 at 06:56:57PM +1100, Niv Sardi wrote: > Hello, > > XFS's default mount options are in most cases sub-optimal, we should try Mkfs options ;) > to have more sensible defaults, so far I'm following some quick dave-powered > recomendations: > > - version 2 logs > - attr2 > - lazy superblock counters > - less allocation groups for single disk configs > > - imaxpct default can be reduced > > it is currently 25, what would be reasonable ? Given that 25% on a 4GB filesystem will allow about 5million inodes, I think it's probably reasonable to bring it down to 5% by the time we pass 1TB and 1% by 50TB..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 02:28:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 02:28:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9T9S21W021204 for ; Mon, 29 Oct 2007 02:28:03 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id 2059B300CF17; Mon, 29 Oct 2007 10:14:20 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/4619/Mon Oct 29 01:23:49 2007 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqc1LR1NChJP; Mon, 29 Oct 2007 10:14:20 +0100 (CET) Received: by sargon.lncsa.com (Postfix, from userid 1053) id 05F74300CF0B; Mon, 29 Oct 2007 10:14:19 +0100 (CET) Date: Mon, 29 Oct 2007 10:14:19 +0100 From: Laurent Caron To: drbd-user@linbit.com, xfs@oss.sgi.com Subject: Crash with XFS on top of DRBD (DRBD 8.0.6 svn / Kernel 2.6.22) Message-ID: <20071029101329.ietaisee@trusted.lncsa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) X-Virus-Status: Clean X-archive-position: 13454 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lcaron@lncsa.fr Precedence: bulk X-list: xfs Hi, I'm back with my crash, oomkiller..... problems on my DRBD cluster of 2 servers. I compiled a 2.6.22 kernel with slab/slab debugging turned on. Here is the last oom-killer message I got on that server. I couldn't wait until a crash since a lot of users are working on it: ----------------------------------------------- kernel: procmail invoked oom-killer: gfp_mask=0xd0, order=1, oomkilladj=0 kernel: [] out_of_memory+0x69/0x197 kernel: [] __alloc_pages+0x20a/0x294 kernel: [] __get_free_pages+0x2c/0x3a kernel: [] copy_process+0xa4/0x102d kernel: [] alloc_pid+0x16/0x240 kernel: [] kmem_cache_alloc+0x80/0x8a kernel: [] alloc_pid+0x16/0x240 kernel: [] do_fork+0x9a/0x1c2 kernel: [] sys_clone+0x36/0x3b kernel: [] sysenter_past_esp+0x6b/0xa1 kernel: ======================= kernel: Mem-info: kernel: DMA per-cpu: kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 kernel: Normal per-cpu: kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 63 Cold: hi: 62, btch: 15 usd: 51 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 97 Cold: hi: 62, btch: 15 usd: 54 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 26 Cold: hi: 62, btch: 15 usd: 47 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 61 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 53 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 0 Cold: hi: 62, btch: 15 usd: 60 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 6 Cold: hi: 62, btch: 15 usd: 57 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 28 Cold: hi: 62, btch: 15 usd: 59 kernel: HighMem per-cpu: kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 98 Cold: hi: 62, btch: 15 usd: 8 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 7 Cold: hi: 62, btch: 15 usd: 12 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 85 Cold: hi: 62, btch: 15 usd: 4 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 72 Cold: hi: 62, btch: 15 usd: 0 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 21 Cold: hi: 62, btch: 15 usd: 6 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 19 Cold: hi: 62, btch: 15 usd: 12 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 175 Cold: hi: 62, btch: 15 usd: 12 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 137 Cold: hi: 62, btch: 15 usd: 2 kernel: Active:381850 inactive:9157 dirty:256 writeback:97 unstable:0 kernel: free:2519061 slab:22044 mapped:7487 pagetables:2163 bounce:0 kernel: DMA free:3564kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes kernel: lowmem_reserve[]: 0 873 12938 kernel: Normal free:7756kB min:3744kB low:4680kB high:5616kB active:116kB inactive:0kB present:894080kB pages_scanned:192 all_unreclaimable? yes kernel: lowmem_reserve[]: 0 0 96520 kernel: HighMem free:10064924kB min:512kB low:13456kB high:26404kB active:1527284kB inactive:36804kB present:12354560kB pages_scanned:0 all_unreclaimable? no kernel: lowmem_reserve[]: 0 0 0 kernel: DMA: 9*4kB 15*8kB 3*16kB 1*32kB 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3564kB kernel: Normal: 1495*4kB 10*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 7804kB kernel: HighMem: 39234*4kB 109305*8kB 80630*16kB 52420*32kB 27267*64kB 9904*128kB 2822*256kB 871*512kB 377*1024kB 218*2048kB 257*4096kB = 10065264kB kernel: Swap cache: add 43, delete 42, find 0/0, race 0+0 kernel: Free swap = 393204kB kernel: Total swap = 393208kB kernel: Free swap: 393204kB kernel: 3342335 pages of RAM kernel: 3112959 pages of HIGHMEM kernel: 224356 reserved pages kernel: 221558 pages shared kernel: 1 pages swap cached kernel: 256 pages dirty kernel: 97 pages writeback kernel: 7487 pages mapped kernel: 22044 pages slab kernel: 2163 pages pagetables kernel: Out of memory: kill process 12069 (slapd) score 62386 or a child kernel: Killed process 12069 (slapd) --------------------------------------------- Do anyone have any clue about what's happening ? Thanks Laurent From owner-xfs@oss.sgi.com Mon Oct 29 03:43:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 03:43:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TAhXC6031931 for ; Mon, 29 Oct 2007 03:43:37 -0700 Received: from mail.aconex.com (castle.yarra.acx [192.168.3.3]) by postoffice.aconex.com (Postfix) with ESMTP id 70A4992C5C0; Mon, 29 Oct 2007 21:43:37 +1100 (EST) Received: from 192.168.3.1 (proxying for 58.107.42.33) (SquirrelMail authenticated user nscott) by mail.aconex.com with HTTP; Mon, 29 Oct 2007 21:44:01 +1100 (EST) Message-ID: <41805.192.168.3.1.1193654641.squirrel@mail.aconex.com> In-Reply-To: <20071029085502.GI995458@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <20071029085502.GI995458@sgi.com> Date: Mon, 29 Oct 2007 21:44:01 +1100 (EST) Subject: Re: Default mount options (that suck less). From: nscott@aconex.com To: "Niv Sardi" , "David Chinner" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.91.2/4619/Mon Oct 29 01:23:49 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13455 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs > On Mon, Oct 29, 2007 at 06:56:57PM +1100, Niv Sardi wrote: >> Hello, >> >> XFS's default mount options are in most cases sub-optimal, we should try > > Mkfs options ;) > >> to have more sensible defaults, so far I'm following some quick >> dave-powered >> recomendations: >> >> - version 2 logs >> - attr2 >> - lazy superblock counters >> - less allocation groups for single disk configs > Version 2 inodes should always be created by default (there are both userspace and kernel changes required for that). cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Oct 29 07:03:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 07:04:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TE3rI6021876 for ; Mon, 29 Oct 2007 07:03:56 -0700 Received: from liberator.sandeen.net (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 B180218013845; Mon, 29 Oct 2007 09:03:57 -0500 (CDT) Message-ID: <4725E84D.3030609@sandeen.net> Date: Mon, 29 Oct 2007 09:03:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> In-Reply-To: <20071029075657.GA84369978@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4621/Mon Oct 29 03:25:54 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13457 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 Niv Sardi wrote: > Hello, > > XFS's default mount options are in most cases sub-optimal, we should try > to have more sensible defaults, so far I'm following some quick dave-powered > recomendations: > > - version 2 logs > - attr2 FWIW any anaconda-installed xfs filesystems have been using attr2 since FC6, and after the initial pain, I haven't heard any reports of problems. > - lazy superblock counters > - less allocation groups for single disk configs > > - imaxpct default can be reduced > > it is currently 25, what would be reasonable ? > > - dropping the ability to turn unwritten extents off completely > > please submit your pet-idea for better defaults here. larger logbuf count/size seems to be the other tuning that's thrown around a lot. -Eric From owner-xfs@oss.sgi.com Mon Oct 29 07:01:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 07:01:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TE1n5H021294 for ; Mon, 29 Oct 2007 07:01:53 -0700 Received: from liberator.sandeen.net (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 99727185FC83A; Mon, 29 Oct 2007 09:01:52 -0500 (CDT) Message-ID: <4725E7D0.8090400@sandeen.net> Date: Mon, 29 Oct 2007 09:01:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <20071029085502.GI995458@sgi.com> In-Reply-To: <20071029085502.GI995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4621/Mon Oct 29 03:25:54 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13456 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 David Chinner wrote: > On Mon, Oct 29, 2007 at 06:56:57PM +1100, Niv Sardi wrote: >> Hello, >> >> XFS's default mount options are in most cases sub-optimal, we should try > > Mkfs options ;) > >> to have more sensible defaults, so far I'm following some quick dave-powered >> recomendations: >> >> - version 2 logs >> - attr2 >> - lazy superblock counters >> - less allocation groups for single disk configs >> >> - imaxpct default can be reduced >> >> it is currently 25, what would be reasonable ? > > Given that 25% on a 4GB filesystem will allow about 5million inodes, > I think it's probably reasonable to bring it down to 5% by the time we > pass 1TB and 1% by 50TB..... But what does this affect? It's a cap, but it doesn't affect allocation policy or anything does it? What's the downside to 25%? -Eric From owner-xfs@oss.sgi.com Mon Oct 29 08:05:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 08:05:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=AWL,BAYES_40,RCVD_ILLEGAL_IP autolearn=no version=3.3.0-r574664 Received: from mailout3.imos.net (mailout3.imos.net [212.87.132.34]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TF5V80032493 for ; Mon, 29 Oct 2007 08:05:33 -0700 Received: from homer.imos.net (homer.imos.net [212.87.132.35]) by mailout3.imos.net (8.14.1/8.14.1) with ESMTP id l9TF5YM5025465; Mon, 29 Oct 2007 16:05:34 +0100 Received: from lstyd.imos.net (lstyd.imos.net [212.87.130.122]) by homer.imos.net (8.14.1/8.14.1) with ESMTP id l9TF5XZV008992; Mon, 29 Oct 2007 16:05:33 +0100 Received: from [5.15.153.128] ([5.15.153.128]) by lstyd.imos.net (8.14.0/8.13.7) with ESMTP id l9TF7Rg3018716; Mon, 29 Oct 2007 16:07:27 +0100 Message-ID: <4725F6C0.3020303@theendofthetunnel.de> Date: Mon, 29 Oct 2007 16:05:36 +0100 From: Hannes Dorbath User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eric Sandeen CC: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> In-Reply-To: <4725E84D.3030609@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4622/Mon Oct 29 06:09:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13458 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: light@theendofthetunnel.de Precedence: bulk X-list: xfs On 29.10.2007 15:03, Eric Sandeen wrote: > Niv Sardi wrote: >> XFS's default mount options are in most cases sub-optimal, we should try >> to have more sensible defaults, so far I'm following some quick dave-powered >> recomendations: Is there any reason to not set the default inode size to 512 bytes? ..as suggested in: http://www.suse.de/~agruen/acl/linux-acls/online/ -- Regards, Hannes Dorbath From owner-xfs@oss.sgi.com Mon Oct 29 08:07:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 08:07:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TF7Qla000464 for ; Mon, 29 Oct 2007 08:07:27 -0700 Received: from liberator.sandeen.net (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 A53AA18028D46; Mon, 29 Oct 2007 10:07:30 -0500 (CDT) Message-ID: <4725F732.2060509@sandeen.net> Date: Mon, 29 Oct 2007 10:07:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Hannes Dorbath CC: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> <4725F6C0.3020303@theendofthetunnel.de> In-Reply-To: <4725F6C0.3020303@theendofthetunnel.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4622/Mon Oct 29 06:09:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13459 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 Hannes Dorbath wrote: > On 29.10.2007 15:03, Eric Sandeen wrote: >> Niv Sardi wrote: >>> XFS's default mount options are in most cases sub-optimal, we should try >>> to have more sensible defaults, so far I'm following some quick dave-powered >>> recomendations: > > Is there any reason to not set the default inode size to 512 bytes? ..as > suggested in: > > http://www.suse.de/~agruen/acl/linux-acls/online/ attr2 should help with the problem now... unless there is some common case where attr2+256 still spills out a lot? -Eric From owner-xfs@oss.sgi.com Mon Oct 29 08:26:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 08:26:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TFQetW007552 for ; Mon, 29 Oct 2007 08:26:41 -0700 Received: from liberator.sandeen.net (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 C2605187B8C0F; Mon, 29 Oct 2007 10:26:44 -0500 (CDT) Message-ID: <4725FBB4.1010400@sandeen.net> Date: Mon, 29 Oct 2007 10:26:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> In-Reply-To: <20071029075657.GA84369978@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4622/Mon Oct 29 06:09:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13460 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 Niv Sardi wrote: > Hello, > > XFS's default mount options are in most cases sub-optimal, we should try > to have more sensible defaults, so far I'm following some quick dave-powered > recomendations: > > - version 2 logs > - attr2 > - lazy superblock counters > - less allocation groups for single disk configs > > - imaxpct default can be reduced > > it is currently 25, what would be reasonable ? > > - dropping the ability to turn unwritten extents off completely > > please submit your pet-idea for better defaults here. Sorry for all the replies ;-) What would you think of a mkfs conf file like e2fsprogs has, which defines filesystem classes, and defaults for each? (small, news, largefile, etc...) -Eric From owner-xfs@oss.sgi.com Mon Oct 29 08:44:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 08:45:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TFisj3010581 for ; Mon, 29 Oct 2007 08:44:56 -0700 Received: (qmail 55749 invoked from network); 29 Oct 2007 15:44:58 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 29 Oct 2007 15:44:58 -0000 X-YMail-OSG: r4t60bgVM1n7SCzUHYRCjLMT0lXYY_j2ztJeb0nwiI24mDzR5UKVdpsgbCxGqWfFo2muLmDI2g-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C3FF42848DFE; Mon, 29 Oct 2007 08:44:56 -0700 (PDT) Date: Mon, 29 Oct 2007 08:44:56 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071029154456.GA25142@puku.stupidest.org> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4725FBB4.1010400@sandeen.net> X-Virus-Scanned: ClamAV 0.91.2/4622/Mon Oct 29 06:09:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13461 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 On Mon, Oct 29, 2007 at 10:26:44AM -0500, Eric Sandeen wrote: > What would you think of a mkfs conf file like e2fsprogs has, which > defines filesystem classes, and defaults for each? (small, news, > largefile, etc...) That makes more sense for ext2/3 where some meta-data isn't dynamically allocated as needed, for example, historically nntp servers used one file per article and would often run out of inodes. From owner-xfs@oss.sgi.com Mon Oct 29 08:51:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 08:51:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TFp01S011849 for ; Mon, 29 Oct 2007 08:51:04 -0700 Received: from liberator.sandeen.net (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 E86FB18C90F71; Mon, 29 Oct 2007 10:51:04 -0500 (CDT) Message-ID: <47260168.3000003@sandeen.net> Date: Mon, 29 Oct 2007 10:51:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Chris Wedgwood CC: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <20071029154456.GA25142@puku.stupidest.org> In-Reply-To: <20071029154456.GA25142@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4622/Mon Oct 29 06:09:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13462 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 Chris Wedgwood wrote: > On Mon, Oct 29, 2007 at 10:26:44AM -0500, Eric Sandeen wrote: > >> What would you think of a mkfs conf file like e2fsprogs has, which >> defines filesystem classes, and defaults for each? (small, news, >> largefile, etc...) > > That makes more sense for ext2/3 where some meta-data isn't > dynamically allocated as needed, for example, historically nntp > servers used one file per article and would often run out of inodes. well, anything that is fixed at mkfs time could use this... inode size, ag count, etc. If there are common use cases which would want different mkfs-fixed defaults, it might make sense. -Eric From owner-xfs@oss.sgi.com Mon Oct 29 11:56:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 11:56:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from b.mx.filmlight.ltd.uk (bongo.filmlight.ltd.uk [217.40.27.26]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TIuDHB021939 for ; Mon, 29 Oct 2007 11:56:15 -0700 Received: (dqd 25701 invoked from network); 29 Oct 2007 18:56:17 -0000 Received: from unknown (HELO ?10.44.0.101?) (roger@10.44.0.101) by b.mx.filmlight.ltd.uk with SMTP; 29 Oct 2007 18:56:17 -0000 Message-ID: <47262CD0.5010708@filmlight.ltd.uk> Date: Mon, 29 Oct 2007 18:56:16 +0000 From: Roger Willcocks User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Tim Shimmin CC: xfs@oss.sgi.com Subject: Re: bug: truncate to zero + setuid References: <47249E7A.7060709@filmlight.ltd.uk> <47252F62.6030503@sgi.com> In-Reply-To: <47252F62.6030503@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13463 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: roger@filmlight.ltd.uk Precedence: bulk X-list: xfs Tim Shimmin wrote: > Hi Roger, > > Roger Willcocks wrote: >> The nfsv3 setattr call permits a simultaneous truncate + setuid/gid >> operation. Normally XFS handles this fine, but if the file's being >> truncated to zero, and the file's already empty, XFS simply ignores >> the setuid/gid part, returning 'success'. >> >> The error's in xfs_vnodeops.c/xfs_setattr below the comment 'Short >> circuit the truncate case for zero length files', which bypasses all >> other changes. >> >> The simplest fix is to test whether this is the only change that's >> happening, otherwise you get tangled in transactions. >> >> if (mask & XFS_AT_SIZE) { >> /* Short circuit the truncate case for zero length >> files */ >> - if ((vap->va_size == 0) && >> + if (((mask & ~XFS_AT_SIZE) == 0) && (vap->va_size == >> 0) && >> (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == >> 0)) { >> >> >> -- >> Roger >> > > Yeah, I see your problem. > It is interesting to know how much of multiple actions (different > bits of mask) are supported. > XFS_AT_UPDTIMES doesn't support anything else and will return quickly. > As far as code which goes via error_return, it looks like the > only non-error case is the short-circuit one mentioned above - > truncating to zero an already zeroed file. > > I see your fix will get what we want although, it will mean that we > will go thru the truncating path when we don't need to. > It would be nice if we could act like the XFS_AT_SIZE was never set > on the call in the case that other bits are set. > Though when we first test the AT_SIZE, we don't have the inode locked. > And I presume in that case we don't necessarily need to send a > DMAPI truncate event? > So I wonder if before the 1st AT_SIZE test that we have now, > in the AT_SIZE case and with other bits set, > we could lock the inode and test > for the zero truncate of zero-len file and if so then remove the > AT_SIZE bit > and then go on to the other testing as if AT_SIZE was never set. > Hmmm, may be that just complicates things too much. > Yes I looked at simply unsetting the XFS_AT_SIZE bit (you'd also need to set timeflags appropriately) but the problem is the bit's used to check when to create a transaction - either up front as XFS_TRANS_SETATTR_NOT_SIZE, or later on, after the inode's been locked and unlocked again, as XFS_TRANS_SETATTR_SIZE. So if you unset the bit (and there's still more to do) you need to build a not_size transaction, at which point you might as well rewrite the whole routine... -- Roger From owner-xfs@oss.sgi.com Mon Oct 29 13:14:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 13:14:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_40,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from mail.clusterfs.com (mail.clusterfs.com [74.0.229.162]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TKEETK003878 for ; Mon, 29 Oct 2007 13:14:15 -0700 Received: from webber.adilger.int (S0106000bdb95b39c.cg.shawcable.net [70.72.213.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id 0619D4E455D; Mon, 29 Oct 2007 12:45:09 -0700 (MST) Received: by webber.adilger.int (Postfix, from userid 1000) id B654442E8E; Mon, 29 Oct 2007 13:45:07 -0600 (MDT) Date: Mon, 29 Oct 2007 13:45:07 -0600 From: Andreas Dilger To: linux-fsdevel@vger.kernel.org Cc: David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029194507.GA8578@webber.adilger.int> Mail-Followup-To: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison References: <20070412110550.GM5967@schatzie.adilger.int> <20070416112252.GJ48531920@melbourne.sgi.com> <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13464 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adilger@sun.com Precedence: bulk X-list: xfs By request on #linuxfs, here is the FIEMAP spec that we used to implement the FIEMAP support for ext4. There was an ext4 patch posted on August 29 to linux-ext4 entitled "[PATCH] FIEMAP ioctl". I've asked Kalpak to post an updated version of that patch along with the changes to the "filefrag" tool to use FIEMAP. ======================== FIEMAP_1.0.txt ================================== File Mapping Interface 18 June 2007 Andreas Dilger, Kalpak Shah Introduction This document covers the user interface and internal implementation of an efficient fragmentation reporting tool. This will include addition of a FIEMAP ioctl to fetch extents and changes to filefrag to use this ioctl. The main objective of this tool is to efficiently and easily allow inspection of the disk layout of one or more files without requiring user access to the underlying storage device(s). 1 Requirements The tool should be efficient in its use of resources, even for large files. The FIBMAP ioctl is not suitable for use on large files, as this can result in millions or even billions of ioctls to get the mapping information for a single file. It should be possible to get the information about an arbitrary-sized extent in a single call, and the kernel component and user tool should efficiently use this information. The user interface should be simple, and the output should be easily understood - by default the filename(s), a count of extents (for each file), and the optimal number of extents for a file with the given striping parameters. The user interface will be "filefrag [options] {filename ...}" and will allow retrieving the fragmentation information for one or more files specified on the command-line. The output will be of the form: /path/to/file1: extents=2 optimal=1 /path/to/file2: extents=10 optimal=4 .......... 2 Functional specification The FIEMAP ioctl (FIle Extent MAP) is similar to the existing FIBMAP ioctl block device ioctl used for mapping an individual logical block address in a file to a physical block address in the block device. The FIEMAP ioctl will return the logical to physical mapping for the extent that contains the specified logical byte address. struct fiemap_extent { __u64 fe_offset;/* offset in bytes for the start of the extent */ __u64 fe_length;/* length in bytes for the extent */ __u32 fe_flags; /* returned FIEMAP_EXTENT_* flags for the extent */ __u32 fe_lun; /* logical device number for extent(starting at 0)*/ }; struct fiemap { __u64 fm_start; /* logical byte offset (in/out) */ __u64 fm_length; /* logical length of map (in/out) */ __u32 fm_flags; /* FIEMAP_FLAG_* flags (in/out) */ __u32 fm_extent_count; /* extents in fm_extents (in/out) */ __u64 fm_unused; struct fiemap_extent fm_extents[0]; }; In the ioctl request, the fiemap struct is initialized with the desired mapping information. fiemap.fm_start = {desired start byte offset, 0 if whole file}; fiemap.fm_length = {length of mapping in bytes, ~0ULL if whole file} fiemap.fm_extent_count = {number of fiemap_extents in fm_extents array}; fiemap.fm_flags = {flags from FIEMPA_FLAG_* array, if needed}; ioctl(fd, FIEMAP, &fiemap); {verify fiemap flags are understood } for (i = 0; i < fiemap.fm_extent_count; i++) { { process extent fiemap.fm_extents[i]}; } The logic for the filefrag would be similar to above. The size of the extent array will be extrapolated from the filesize and multiple ioctls of increasing extent count may be called for very large files. filefrag can easily call the FIEMAP ioctls repeatedly using the end of the last extent as the start offset for the next ioctl: fm_start = fm_extents[fm_extent_count - 1].fe_offset + fm_extents[fm_extent_count - 1].fe_length + 1; We do this until we find an extent with FIEMAP_EXTENT_LAST flag set. We will also need to re-initialise the fiemap flags, fm_extent_count, fm_end. The FIEMAP_FLAG_* values are specified below. If FIEMAP_FLAG_NO_EXTENTS is given then the fm_extents array is not filled, and only fm_extent_count is returned with the total number of extents in the file. Any new flags that introduce and/or require an incompatible behaviour in an application or in the kernel need to be in the range specified by FIEMAP_FLAG_INCOMPAT (e.g. FIEMAP_FLAG_SYNC and FIEMAP_FLAG_NO_EXTENTS would fall into that range if they were not part of the original specification). This is currently only for future use. If it turns out that FIEMAP_FLAG_INCOMPAT is not large enough then it is possible to use the last INCOMPAT flag 0x01000000 to incidate that more of the flag range contains incompatible flags. #define FIEMAP_FLAG_SYNC 0x00000001 /* sync file data before map */ #define FIEMAP_FLAG_HSM_READ 0x00000002 /* get data from HSM before map */ #define FIEMAP_FLAG_NUM_EXTENTS 0x00000004 /* return only number of extents */ #define FIEMAP_FLAG_INCOMPAT 0xff000000 /* error for unknown flags in here */ The returned data from the FIEMAP ioctl is an array of fiemap_extent elements, one per extent in the file. The first extent will contain the byte specified by fm_start and the last extent will contain the byte specified by fm_start + fm_len, unless there are more than the passed-in fm_extent_count extents in the file, or this is beyond the EOF in which case the last extent will be marked with FIEMAP_EXTENT_LAST. Each extent returned has a set of flags associated with it that provide additional information about the extent. Not all filesystems will support all flags. FIEMAP_FLAG_NUM_EXTENTS will return only the number of extents used by the file. It will be used by default for filefrag since the specific extent information is not required in many cases. #define FIEMAP_EXTENT_HOLE 0x00000001 /* has no data or space allocation */ #define FIEMAP_EXTENT_UNWRITTEN 0x00000002 /* space allocated, but no data */ #define FIEMAP_EXTENT_UNMAPPED 0x00000004 /* has data but no space allocated */ #define FIEMAP_EXTENT_ERROR 0x00000008 /* map error, errno in fe_offset. */ #define FIEMAP_EXTENT_NO_DIRECT 0x00000010 /* cannot access data directly */ #define FIEMAP_EXTENT_LAST 0x00000020 /* last extent in the file */ #define FIEMAP_EXTENT_DELALLOC 0x00000040 /* has data but not yet written */ #define FIEMAP_EXTENT_SECONDARY 0x00000080 /* data in secondary storage */ #define FIEMAP_EXTENT_EOF 0x00000100 /* fm_start + fm_len beyond EOF */ #define FIEMAP_EXTENT_UNKNOWN 0x00000200 /* in use but location is unknown */ FIEMAP_EXTENT_NO_DIRECT means data cannot be directly accessed (maybe encrypted, compressed, etc.) FIEMAP_EXTENT_ERROR and FIEMAP_EXTENT_DELALLOC flags should always be returned with FIEMAP_EXTENT_UNMAPPED also set. So some flags are a superset of other flags. FIEMAP_EXTENT_SECONDARY may optionally include FIEMAP_EXTENT_UNMAPPED. Inside ext4, this can be implemented for extent-mapped files by calling something similar to the existing ext4_ext_ioctl() for EXT4_IOC_GET_EXTENTS but with a different callback function. Or the ext4_fiemap() function can be called directly from the ioctl code if the latest extents patches do not have ext4_ext_ioctl(). 3 Use cases 1) Files containing holes including an all-hole file. 2) File having an extent which is not yet allocated. 3) Proper working with fm_start + fm_len beyond EOF. 4) Test proper reporting of preallocated extents. 5) Have non-zero fm_start and non-~0ULL fm_end. This can be tested by having fm_count = 1 and forcing many ioctls. 6) If there is an error mapping an in-between extent then the later extents should be returned. Cheers, Andreas -- Andreas Dilger Sr. Software Engineer, Lustre Group Sun Microsystems of Canada, Inc. From owner-xfs@oss.sgi.com Mon Oct 29 14:06:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 14:06:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TL61T6009505 for ; Mon, 29 Oct 2007 14:06:04 -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 IAA11566; Tue, 30 Oct 2007 08:05:56 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TL5tdD86283828; Tue, 30 Oct 2007 08:05:56 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TL5r2X86374047; Tue, 30 Oct 2007 08:05:53 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 08:05:53 +1100 From: David Chinner To: Eric Sandeen Cc: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071029210553.GJ995458@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4725E84D.3030609@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13465 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 On Mon, Oct 29, 2007 at 09:03:57AM -0500, Eric Sandeen wrote: > Niv Sardi wrote: > > please submit your pet-idea for better defaults here. > > larger logbuf count/size seems to be the other tuning that's thrown > around a lot. Well, we already default to 8 logbufs, and 256k log buffers are not a win in a lot of situations. The log buffer size is a mount option, so it's much easier to tweak once we default to v2 logs... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 14:10:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 14:10:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TLAUrr010243 for ; Mon, 29 Oct 2007 14:10:33 -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 IAA11681; Tue, 30 Oct 2007 08:10:27 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TLAPdD86471203; Tue, 30 Oct 2007 08:10:25 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TLAMQF83491402; Tue, 30 Oct 2007 08:10:22 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 08:10:22 +1100 From: David Chinner To: Laurent Caron Cc: drbd-user@linbit.com, xfs@oss.sgi.com Subject: Re: Crash with XFS on top of DRBD (DRBD 8.0.6 svn / Kernel 2.6.22) Message-ID: <20071029211021.GK995458@sgi.com> References: <20071029101329.ietaisee@trusted.lncsa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029101329.ietaisee@trusted.lncsa.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13466 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 On Mon, Oct 29, 2007 at 10:14:19AM +0100, Laurent Caron wrote: > Hi, > > I'm back with my crash, oomkiller..... problems on my DRBD cluster of 2 > servers. > > I compiled a 2.6.22 kernel with slab/slab debugging turned on. > > Here is the last oom-killer message I got on that server. You ran out of low memory. Slab didn't use it all, so I'm not sure what would be using it. You should post OOM invokations to LKML. Given DRDB is te unusual thing your are using, I'd be looking there first... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 14:26:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 14:26:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TLQnBV012360 for ; Mon, 29 Oct 2007 14:26:52 -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 IAA12277; Tue, 30 Oct 2007 08:26:52 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TLQodD86439881; Tue, 30 Oct 2007 08:26:51 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TLQnLD86364296; Tue, 30 Oct 2007 08:26:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 08:26:49 +1100 From: David Chinner To: Eric Sandeen Cc: David Chinner , Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071029212649.GL995458@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <20071029085502.GI995458@sgi.com> <4725E7D0.8090400@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4725E7D0.8090400@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13467 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 On Mon, Oct 29, 2007 at 09:01:52AM -0500, Eric Sandeen wrote: > David Chinner wrote: > > On Mon, Oct 29, 2007 at 06:56:57PM +1100, Niv Sardi wrote: > >> Hello, > >> > >> XFS's default mount options are in most cases sub-optimal, we should try > > > > Mkfs options ;) > > > >> to have more sensible defaults, so far I'm following some quick dave-powered > >> recomendations: > >> > >> - version 2 logs > >> - attr2 > >> - lazy superblock counters > >> - less allocation groups for single disk configs > >> > >> - imaxpct default can be reduced > >> > >> it is currently 25, what would be reasonable ? > > > > Given that 25% on a 4GB filesystem will allow about 5million inodes, > > I think it's probably reasonable to bring it down to 5% by the time we > > pass 1TB and 1% by 50TB..... > > But what does this affect? It's a cap, but it doesn't affect allocation > policy or anything does it? What's the downside to 25%? It reserves allocation groups as "metadata only" for inode32 filesystems so data doesn't get placed in them untill all other space is full. So at 1TB, we don't use 25% of the filesystem until the other 75% is full, yet to hold 4 million inodes we only need about 1GB of space. so 5GB out of 1TB gives us space in the filesystem for ~20m million inodes by default. AFAICT, this is the only place it is used. Likewise, at 50TB, we're only going to be able to use 2% of the filesystem for inodes with inode32. At 100TB, it's meaningless..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 15:13:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 15:13:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from mail.clusterfs.com (mail.clusterfs.com [74.0.229.162]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TMD0QY018048 for ; Mon, 29 Oct 2007 15:13:01 -0700 Received: from webber.adilger.int (S0106000bdb95b39c.cg.shawcable.net [70.72.213.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id 0CEE34E455D; Mon, 29 Oct 2007 15:13:04 -0700 (MST) Received: by webber.adilger.int (Postfix, from userid 1000) id EBA8242E8F; Mon, 29 Oct 2007 16:13:02 -0600 (MDT) Date: Mon, 29 Oct 2007 16:13:02 -0600 From: Andreas Dilger To: Mark Fasheh Cc: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029221302.GD3042@webber.adilger.int> Mail-Followup-To: Mark Fasheh , linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com References: <20070416112252.GJ48531920@melbourne.sgi.com> <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> <20071029205744.GB28607@ca-server1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029205744.GB28607@ca-server1.us.oracle.com> X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13468 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adilger@sun.com Precedence: bulk X-list: xfs On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote: > Thanks for posting this. I believe that an interface such as FIEMAP > would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail) I tried to make it as Lustre-agnostic as possible... > On Mon, Oct 29, 2007 at 01:45:07PM -0600, Andreas Dilger wrote: > > The FIEMAP ioctl (FIle Extent MAP) is similar to the existing FIBMAP > > ioctl block device ioctl used for mapping an individual logical block > > address in a file to a physical block address in the block device. The > > FIEMAP ioctl will return the logical to physical mapping for the extent > > that contains the specified logical byte address. > > > > struct fiemap_extent { > > __u64 fe_offset;/* offset in bytes for the start of the extent */ > > I'm a little bit confused by fe_offset. Is it a physical offset, or a > logical offset? The reason I ask is that your description above says "FIEMAP > ioctl will return the logical to physical mapping for the extent that > contains the specified logical byte address." Which seems to imply physical, > but your math to get to the next logical start in a very fragmented file, > implies that fe_offset is a logical offset: > > fm_start = fm_extents[fm_extent_count - 1].fe_offset + > fm_extents[fm_extent_count - 1].fe_length + 1; Note the distinction between "fe_offset" (which is a physical offset for a single extent) and "fm_offset" (which is a logical offset for that file). > > We do this until we find an extent with FIEMAP_EXTENT_LAST flag set. We > > will also need to re-initialise the fiemap flags, fm_extent_count, fm_end. > > I think you meant 'fm_length' instead of 'fm_end' there. You're right, thanks. > > #define FIEMAP_EXTENT_LAST 0x00000020 /* last extent in the file */ > > #define FIEMAP_EXTENT_EOF 0x00000100 /* fm_start + fm_len beyond EOF*/ > > Is "EOF" here considering "beyond i_size" or "beyond allocation"? _EOF == beyond i_size. _LAST == last extent in the file. In most cases FIEMAP_EXTENT_EOF will be set at the same time as FIEMAP_EXTENT_LAST, but in case of e.g. prealloc beyond i_size the EOF flag may be set on one or more earlier extents. > > FIEMAP_EXTENT_NO_DIRECT means data cannot be directly accessed (maybe > > encrypted, compressed, etc.) > > Would it be valid to use FIEMAP_EXTENT_NO_DIRECT for marking in-inode data? > Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode > blocks. Hmm, but part of the issue would be how to request the extra data, and what offset it would be given? One could, for example, use negative offsets to represent metadata or something, or add a FIEMAP_EXTENT_META or similar, I hadn't given that much thought. The other issue is that I'd like to get the basics of the API in place before it gets too complex. We can always add functionality with more FIEMAP_FLAG_* (whether in the INCOMPAT range or not, depending on what is being done). Cheers, Andreas -- Andreas Dilger Sr. Software Engineer, Lustre Group Sun Microsystems of Canada, Inc. From owner-xfs@oss.sgi.com Mon Oct 29 15:17:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 15:17:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TMH0nj018905 for ; Mon, 29 Oct 2007 15:17:03 -0700 Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by agminet02.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9TKw1rY028720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2007 15:58:02 -0500 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9TKvja3017505; Mon, 29 Oct 2007 15:57:46 -0500 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l9TKvjKC019003; Mon, 29 Oct 2007 14:57:45 -0600 Received: from mfasheh by ca-server1.us.oracle.com with local (Exim 4.67) (envelope-from ) id 1Imbg8-0008Mi-S0; Mon, 29 Oct 2007 13:57:44 -0700 Date: Mon, 29 Oct 2007 13:57:44 -0700 From: Mark Fasheh To: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029205744.GB28607@ca-server1.us.oracle.com> Reply-To: Mark Fasheh References: <20070412110550.GM5967@schatzie.adilger.int> <20070416112252.GJ48531920@melbourne.sgi.com> <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029194507.GA8578@webber.adilger.int> Organization: Oracle Corporation User-Agent: Mutt/1.5.16 (2007-06-11) X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13469 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mark.fasheh@oracle.com Precedence: bulk X-list: xfs Hi Andreas, Thanks for posting this. I believe that an interface such as FIEMAP would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail) My comments below are generally geared towards understanding the ioctl interface. On Mon, Oct 29, 2007 at 01:45:07PM -0600, Andreas Dilger wrote: > 2 Functional specification > > The FIEMAP ioctl (FIle Extent MAP) is similar to the existing FIBMAP > ioctl block device ioctl used for mapping an individual logical block > address in a file to a physical block address in the block device. The > FIEMAP ioctl will return the logical to physical mapping for the extent > that contains the specified logical byte address. > > struct fiemap_extent { > __u64 fe_offset;/* offset in bytes for the start of the extent */ I'm a little bit confused by fe_offset. Is it a physical offset, or a logical offset? The reason I ask is that your description above says "FIEMAP ioctl will return the logical to physical mapping for the extent that contains the specified logical byte address." Which seems to imply physical, but your math to get to the next logical start in a very fragmented file, implies that fe_offset is a logical offset: fm_start = fm_extents[fm_extent_count - 1].fe_offset + fm_extents[fm_extent_count - 1].fe_length + 1; > The logic for the filefrag would be similar to above. The size of the > extent array will be extrapolated from the filesize and multiple ioctls > of increasing extent count may be called for very large files. filefrag > can easily call the FIEMAP ioctls repeatedly using the end of the last > extent as the start offset for the next ioctl: > > fm_start = fm_extents[fm_extent_count - 1].fe_offset + > fm_extents[fm_extent_count - 1].fe_length + 1; > > We do this until we find an extent with FIEMAP_EXTENT_LAST flag set. We > will also need to re-initialise the fiemap flags, fm_extent_count, fm_end. I think you meant 'fm_length' instead of 'fm_end' there. > The FIEMAP_FLAG_* values are specified below. If FIEMAP_FLAG_NO_EXTENTS is > given then the fm_extents array is not filled, and only fm_extent_count is > returned with the total number of extents in the file. Any new flags that > introduce and/or require an incompatible behaviour in an application or > in the kernel need to be in the range specified by FIEMAP_FLAG_INCOMPAT > (e.g. FIEMAP_FLAG_SYNC and FIEMAP_FLAG_NO_EXTENTS would fall into that > range if they were not part of the original specification). This is > currently only for future use. If it turns out that FIEMAP_FLAG_INCOMPAT > is not large enough then it is possible to use the last INCOMPAT flag > 0x01000000 to incidate that more of the flag range contains incompatible > flags. > > #define FIEMAP_FLAG_SYNC 0x00000001 /* sync file data before map */ > #define FIEMAP_FLAG_HSM_READ 0x00000002 /* get data from HSM before map */ > #define FIEMAP_FLAG_NUM_EXTENTS 0x00000004 /* return only number of extents */ > #define FIEMAP_FLAG_INCOMPAT 0xff000000 /* error for unknown flags in here */ > > The returned data from the FIEMAP ioctl is an array of fiemap_extent > elements, one per extent in the file. The first extent will contain the > byte specified by fm_start and the last extent will contain the byte > specified by fm_start + fm_len, unless there are more than the passed-in > fm_extent_count extents in the file, or this is beyond the EOF in which > case the last extent will be marked with FIEMAP_EXTENT_LAST. Each extent > returned has a set of flags associated with it that provide additional > information about the extent. Not all filesystems will support all flags. > > FIEMAP_FLAG_NUM_EXTENTS will return only the number of extents used by > the file. It will be used by default for filefrag since the specific > extent information is not required in many cases. > > #define FIEMAP_EXTENT_HOLE 0x00000001 /* has no data or space allocation */ Btw, I really like that holes are explicitely marked. > #define FIEMAP_EXTENT_UNWRITTEN 0x00000002 /* space allocated, but no data */ > #define FIEMAP_EXTENT_UNMAPPED 0x00000004 /* has data but no space allocated */ > #define FIEMAP_EXTENT_ERROR 0x00000008 /* map error, errno in fe_offset. */ > #define FIEMAP_EXTENT_NO_DIRECT 0x00000010 /* cannot access data directly */ > #define FIEMAP_EXTENT_LAST 0x00000020 /* last extent in the file */ > #define FIEMAP_EXTENT_DELALLOC 0x00000040 /* has data but not yet written */ > #define FIEMAP_EXTENT_SECONDARY 0x00000080 /* data in secondary storage */ > #define FIEMAP_EXTENT_EOF 0x00000100 /* fm_start + fm_len beyond EOF */ Is "EOF" here considering "beyond i_size" or "beyond allocation"? > #define FIEMAP_EXTENT_UNKNOWN 0x00000200 /* in use but location is unknown */ > > > FIEMAP_EXTENT_NO_DIRECT means data cannot be directly accessed (maybe > encrypted, compressed, etc.) Would it be valid to use FIEMAP_EXTENT_NO_DIRECT for marking in-inode data? Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode blocks. Thanks, --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com From owner-xfs@oss.sgi.com Mon Oct 29 15:25:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 15:25:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TMPlmt019957 for ; Mon, 29 Oct 2007 15:25:51 -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 JAA14040; Tue, 30 Oct 2007 09:25:39 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TMPbdD86476077; Tue, 30 Oct 2007 09:25:38 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TMPXLi86438386; Tue, 30 Oct 2007 09:25:33 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 09:25:33 +1100 From: David Chinner To: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029222533.GO995458@sgi.com> References: <20070412110550.GM5967@schatzie.adilger.int> <20070416112252.GJ48531920@melbourne.sgi.com> <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029194507.GA8578@webber.adilger.int> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13470 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 On Mon, Oct 29, 2007 at 01:45:07PM -0600, Andreas Dilger wrote: > By request on #linuxfs, here is the FIEMAP spec that we used to implement > the FIEMAP support for ext4. There was an ext4 patch posted on August 29 > to linux-ext4 entitled "[PATCH] FIEMAP ioctl". Link: http://marc.info/?l=linux-ext4&m=118838241209683&w=2 That's a very ext4 specific ioctl interface. Can we get this made generic like the FIBMAP interface so we don't have to replicate all the copyin/copyout handling and interface definitions everywhere? i.e. a ->extent_map aops callout to the filesystem in generic code just like ->bmap? > I've asked Kalpak to post > an updated version of that patch along with the changes to the "filefrag" > tool to use FIEMAP. Where can I find the test program that validates the implementation? Also, following the fallocate model, can we get the interface definition turned into a man page before anything is submitted upstream? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 15:29:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 15:29:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from mail.clusterfs.com (mail.clusterfs.com [74.0.229.162]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TMT4NN020561 for ; Mon, 29 Oct 2007 15:29:05 -0700 Received: from webber.adilger.int (S0106000bdb95b39c.cg.shawcable.net [70.72.213.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id B8E534E455D; Mon, 29 Oct 2007 15:29:08 -0700 (MST) Received: by webber.adilger.int (Postfix, from userid 1000) id 853B342E8F; Mon, 29 Oct 2007 16:29:07 -0600 (MDT) Date: Mon, 29 Oct 2007 16:29:07 -0600 From: Andreas Dilger To: Mark Fasheh , linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029222907.GF3042@webber.adilger.int> Mail-Followup-To: Mark Fasheh , linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com References: <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> <20071029205744.GB28607@ca-server1.us.oracle.com> <20071029221302.GD3042@webber.adilger.int> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029221302.GD3042@webber.adilger.int> X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: ClamAV 0.91.2/4624/Mon Oct 29 09:32:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13471 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adilger@sun.com Precedence: bulk X-list: xfs On Oct 29, 2007 16:13 -0600, Andreas Dilger wrote: > On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote: > > I'm a little bit confused by fe_offset. Is it a physical offset, or a > > logical offset? The reason I ask is that your description above says "FIEMAP > > ioctl will return the logical to physical mapping for the extent that > > contains the specified logical byte address." Which seems to imply physical, > > but your math to get to the next logical start in a very fragmented file, > > implies that fe_offset is a logical offset: > > > > fm_start = fm_extents[fm_extent_count - 1].fe_offset + > > fm_extents[fm_extent_count - 1].fe_length + 1; > > Note the distinction between "fe_offset" (which is a physical offset for > a single extent) and "fm_offset" (which is a logical offset for that file). Actually, that is completely bunk. What it should say is something like: "filefrag can easily call the FIEMAP ioctls repeatedly using the returned fm_start and fm_length as the start offset for the next ioctl: fiemap.fm_start = fiemap.fm_start + fiemap.fm_length + 1; Cheers, Andreas -- Andreas Dilger Sr. Software Engineer, Lustre Group Sun Microsystems of Canada, Inc. From owner-xfs@oss.sgi.com Mon Oct 29 16:35:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:35:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNZfOO031905 for ; Mon, 29 Oct 2007 16:35:43 -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 KAA16262; Tue, 30 Oct 2007 10:35:44 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNZhdD86403814; Tue, 30 Oct 2007 10:35:44 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNZhIC86220197; Tue, 30 Oct 2007 10:35:43 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:35:43 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] show all mount args in /proc/mounts Message-ID: <20071029233543.GQ995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13473 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 There are several mount options that don't show up in /proc/mounts. Add them in and clean up the showargs code at the same time. Signed-off-by: Dave Chinner --- fs/xfs/xfs_vfsops.c | 74 ++++++++++++++++++++++++++-------------------------- 1 file changed, 37 insertions(+), 37 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-10-25 10:09:35.025053878 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-10-25 10:34:08.177844260 +1000 @@ -1838,15 +1838,17 @@ done: return 0; } +struct proc_xfs_info { + int flag; + char *str; +}; + int xfs_showargs( struct xfs_mount *mp, struct seq_file *m) { - static struct proc_xfs_info { - int flag; - char *str; - } xfs_info[] = { + static struct proc_xfs_info xfs_info_set[] = { /* the few simple ones we can get from the mount struct */ { XFS_MOUNT_WSYNC, "," MNTOPT_WSYNC }, { XFS_MOUNT_INO64, "," MNTOPT_INO64 }, @@ -1855,14 +1857,30 @@ xfs_showargs( { XFS_MOUNT_NOUUID, "," MNTOPT_NOUUID }, { XFS_MOUNT_NORECOVERY, "," MNTOPT_NORECOVERY }, { XFS_MOUNT_OSYNCISOSYNC, "," MNTOPT_OSYNCISOSYNC }, + { XFS_MOUNT_ATTR2, "," MNTOPT_ATTR2 }, + { XFS_MOUNT_FILESTREAMS, "," MNTOPT_FILESTREAM }, + { XFS_MOUNT_DMAPI, "," MNTOPT_DMAPI }, + { XFS_MOUNT_GRPID, "," MNTOPT_GRPID }, + { 0, NULL } + }; + static struct proc_xfs_info xfs_info_unset[] = { + /* the few simple ones we can get from the mount struct */ + { XFS_MOUNT_IDELETE, "," MNTOPT_IKEEP }, + { XFS_MOUNT_COMPAT_IOSIZE, "," MNTOPT_LARGEIO }, + { XFS_MOUNT_BARRIER, "," MNTOPT_NOBARRIER }, + { XFS_MOUNT_SMALL_INUMS, "," MNTOPT_64BITINODE }, { 0, NULL } }; struct proc_xfs_info *xfs_infop; - for (xfs_infop = xfs_info; xfs_infop->flag; xfs_infop++) { + for (xfs_infop = xfs_info_set; xfs_infop->flag; xfs_infop++) { if (mp->m_flags & xfs_infop->flag) seq_puts(m, xfs_infop->str); } + for (xfs_infop = xfs_info_unset; xfs_infop->flag; xfs_infop++) { + if (!(mp->m_flags & xfs_infop->flag)) + seq_puts(m, xfs_infop->str); + } if (mp->m_flags & XFS_MOUNT_DFLT_IOSIZE) seq_printf(m, "," MNTOPT_ALLOCSIZE "=%dk", @@ -1885,41 +1903,23 @@ xfs_showargs( seq_printf(m, "," MNTOPT_SWIDTH "=%d", (int)XFS_FSB_TO_BB(mp, mp->m_swidth)); - if (!(mp->m_flags & XFS_MOUNT_IDELETE)) - seq_printf(m, "," MNTOPT_IKEEP); - if (!(mp->m_flags & XFS_MOUNT_COMPAT_IOSIZE)) - seq_printf(m, "," MNTOPT_LARGEIO); - - if (!(mp->m_flags & XFS_MOUNT_SMALL_INUMS)) - seq_printf(m, "," MNTOPT_64BITINODE); - if (mp->m_flags & XFS_MOUNT_GRPID) - seq_printf(m, "," MNTOPT_GRPID); - - if (mp->m_qflags & XFS_UQUOTA_ACCT) { - if (mp->m_qflags & XFS_UQUOTA_ENFD) - seq_puts(m, "," MNTOPT_USRQUOTA); - else - seq_puts(m, "," MNTOPT_UQUOTANOENF); - } - - if (mp->m_qflags & XFS_PQUOTA_ACCT) { - if (mp->m_qflags & XFS_OQUOTA_ENFD) - seq_puts(m, "," MNTOPT_PRJQUOTA); - else - seq_puts(m, "," MNTOPT_PQUOTANOENF); - } - - if (mp->m_qflags & XFS_GQUOTA_ACCT) { - if (mp->m_qflags & XFS_OQUOTA_ENFD) - seq_puts(m, "," MNTOPT_GRPQUOTA); - else - seq_puts(m, "," MNTOPT_GQUOTANOENF); - } + if (mp->m_qflags & (XFS_UQUOTA_ACCT|XFS_UQUOTA_ENFD)) + seq_puts(m, "," MNTOPT_USRQUOTA); + else if (mp->m_qflags & XFS_UQUOTA_ACCT) + seq_puts(m, "," MNTOPT_UQUOTANOENF); + + if (mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD)) + seq_puts(m, "," MNTOPT_PRJQUOTA); + else if (mp->m_qflags & XFS_PQUOTA_ACCT) + seq_puts(m, "," MNTOPT_PQUOTANOENF); + + if (mp->m_qflags & (XFS_GQUOTA_ACCT|XFS_OQUOTA_ENFD)) + seq_puts(m, "," MNTOPT_GRPQUOTA); + else if (mp->m_qflags & XFS_GQUOTA_ACCT) + seq_puts(m, "," MNTOPT_GQUOTANOENF); if (!(mp->m_qflags & XFS_ALL_QUOTA_ACCT)) seq_puts(m, "," MNTOPT_NOQUOTA); - if (mp->m_flags & XFS_MOUNT_DMAPI) - seq_puts(m, "," MNTOPT_DMAPI); return 0; } From owner-xfs@oss.sgi.com Mon Oct 29 16:34:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:34:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNYfRt031698 for ; Mon, 29 Oct 2007 16:34:42 -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 KAA16244; Tue, 30 Oct 2007 10:34:44 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNYhdD86508016; Tue, 30 Oct 2007 10:34:44 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNYglP85683014; Tue, 30 Oct 2007 10:34:42 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:34:42 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] Clean up sparse warnings Message-ID: <20071029233442.GP995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13472 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 Clean up most outstanding sparse warnings. These are mostly locking annotations, marking things static, casts where needed and declaring stuff in header files. Signed-Off-By: Dave Chinner --- fs/xfs/linux-2.6/xfs_globals.c | 3 ++- fs/xfs/linux-2.6/xfs_ioctl.c | 2 +- fs/xfs/linux-2.6/xfs_ioctl32.c | 1 + fs/xfs/xfs_attr.c | 2 +- fs/xfs/xfs_bmap.c | 6 +++--- fs/xfs/xfs_bmap.h | 2 ++ fs/xfs/xfs_btree.h | 2 ++ fs/xfs/xfs_buf_item.h | 2 ++ fs/xfs/xfs_da_btree.h | 1 + fs/xfs/xfs_dir2.c | 1 + fs/xfs/xfs_filestream.c | 2 +- fs/xfs/xfs_log.c | 24 ++++++++++++------------ fs/xfs/xfs_log_recover.c | 18 +++++------------- fs/xfs/xfs_mount.c | 2 +- fs/xfs/xfs_mru_cache.c | 18 ++++++++++++++---- fs/xfs/xfs_rename.c | 1 + fs/xfs/xfs_trans.h | 2 ++ fs/xfs/xfs_trans_item.c | 1 + fs/xfs/xfs_vfsops.c | 11 ----------- 19 files changed, 53 insertions(+), 48 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_globals.c 2007-10-02 16:01:46.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c 2007-10-26 10:08:57.901694193 +1000 @@ -47,5 +47,6 @@ xfs_param_t xfs_params = { /* * Global system credential structure. */ -cred_t sys_cred_val, *sys_cred = &sys_cred_val; +static cred_t sys_cred_val; +cred_t *sys_cred = &sys_cred_val; Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-10-02 16:01:47.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl.c 2007-10-26 10:08:57.901694193 +1000 @@ -512,7 +512,7 @@ xfs_attrmulti_attr_get( if (!kbuf) return ENOMEM; - error = xfs_attr_get(XFS_I(inode), name, kbuf, len, flags, NULL); + error = xfs_attr_get(XFS_I(inode), name, kbuf, (int *)len, flags, NULL); if (error) goto out_kfree; Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl32.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_ioctl32.c 2007-10-15 09:58:18.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl32.c 2007-10-26 10:08:57.905693678 +1000 @@ -44,6 +44,7 @@ #include "xfs_error.h" #include "xfs_dfrag.h" #include "xfs_vnodeops.h" +#include "xfs_ioctl32.h" #define _NATIVE_IOC(cmd, type) \ _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(type)) Index: 2.6.x-xfs-new/fs/xfs/xfs_attr.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_attr.c 2007-08-24 22:25:22.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_attr.c 2007-10-26 10:08:57.905693678 +1000 @@ -929,7 +929,7 @@ xfs_attr_shortform_addname(xfs_da_args_t * This leaf block cannot have a "remote" value, we only call this routine * if bmap_one_block() says there is only one block (ie: no remote blks). */ -int +STATIC int xfs_attr_leaf_addname(xfs_da_args_t *args) { xfs_inode_t *dp; Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.c 2007-10-02 16:01:47.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.c 2007-10-26 10:08:57.909693163 +1000 @@ -6393,7 +6393,7 @@ xfs_bmap_count_blocks( * Recursively walks each level of a btree * to count total fsblocks is use. */ -int /* error */ +STATIC int /* error */ xfs_bmap_count_tree( xfs_mount_t *mp, /* file system mount point */ xfs_trans_t *tp, /* transaction pointer */ @@ -6469,7 +6469,7 @@ xfs_bmap_count_tree( /* * Count leaf blocks given a range of extent records. */ -int +STATIC int xfs_bmap_count_leaves( xfs_ifork_t *ifp, xfs_extnum_t idx, @@ -6489,7 +6489,7 @@ xfs_bmap_count_leaves( * Count leaf blocks given a range of extent records originally * in btree format. */ -int +STATIC int xfs_bmap_disk_count_leaves( xfs_extnum_t idx, xfs_bmbt_block_t *block, Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.h 2007-08-24 22:25:22.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.h 2007-10-26 10:08:57.909693163 +1000 @@ -25,6 +25,8 @@ struct xfs_inode; struct xfs_mount; struct xfs_trans; +extern kmem_zone_t *xfs_bmap_free_item_zone; + /* * DELTA: describe a change to the in-core extent list. * Index: 2.6.x-xfs-new/fs/xfs/xfs_btree.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_btree.h 2007-06-20 15:54:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_btree.h 2007-10-26 10:08:57.913692649 +1000 @@ -24,6 +24,8 @@ struct xfs_inode; struct xfs_mount; struct xfs_trans; +extern kmem_zone_t *xfs_btree_cur_zone; + /* * This nonsense is to make -wlint happy. */ Index: 2.6.x-xfs-new/fs/xfs/xfs_buf_item.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_buf_item.h 2007-10-02 16:01:47.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_buf_item.h 2007-10-26 10:08:57.913692649 +1000 @@ -18,6 +18,8 @@ #ifndef __XFS_BUF_ITEM_H__ #define __XFS_BUF_ITEM_H__ +extern kmem_zone_t *xfs_buf_item_zone; + /* * This is the structure used to lay out a buf log item in the * log. The data map describes which 128 byte chunks of the buffer Index: 2.6.x-xfs-new/fs/xfs/xfs_da_btree.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_da_btree.h 2007-02-07 13:24:33.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_da_btree.h 2007-10-26 10:08:57.913692649 +1000 @@ -260,6 +260,7 @@ void xfs_da_binval(struct xfs_trans *tp, xfs_daddr_t xfs_da_blkno(xfs_dabuf_t *dabuf); extern struct kmem_zone *xfs_da_state_zone; +extern struct kmem_zone *xfs_dabuf_zone; #endif /* __KERNEL__ */ #endif /* __XFS_DA_BTREE_H__ */ Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2.c 2007-09-12 15:41:22.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2.c 2007-10-26 10:08:57.913692649 +1000 @@ -42,6 +42,7 @@ #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" #include "xfs_error.h" +#include "xfs_vnodeops.h" void Index: 2.6.x-xfs-new/fs/xfs/xfs_filestream.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_filestream.c 2007-10-02 16:01:22.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_filestream.c 2007-10-26 10:08:57.917692134 +1000 @@ -348,7 +348,7 @@ _xfs_filestream_update_ag( } /* xfs_fstrm_free_func(): callback for freeing cached stream items. */ -void +STATIC void xfs_fstrm_free_func( unsigned long ino, void *data) Index: 2.6.x-xfs-new/fs/xfs/xfs_log.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_log.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_log.c 2007-10-26 10:08:57.917692134 +1000 @@ -907,7 +907,7 @@ xlog_assign_tail_lsn(xfs_mount_t *mp) * the tail. The details of this case are described below, but the end * result is that we return the size of the log as the amount of space left. */ -int +STATIC int xlog_space_left(xlog_t *log, int cycle, int bytes) { int free_bytes; @@ -1289,7 +1289,7 @@ xlog_commit_record(xfs_mount_t *mp, * pushes on an lsn which is further along in the log once we reach the high * water mark. In this manner, we would be creating a low water mark. */ -void +STATIC void xlog_grant_push_ail(xfs_mount_t *mp, int need_bytes) { @@ -1372,7 +1372,7 @@ xlog_grant_push_ail(xfs_mount_t *mp, * is added immediately before calling bwrite(). */ -int +STATIC int xlog_sync(xlog_t *log, xlog_in_core_t *iclog) { @@ -1516,7 +1516,7 @@ xlog_sync(xlog_t *log, /* * Deallocate a log structure */ -void +STATIC void xlog_dealloc_log(xlog_t *log) { xlog_in_core_t *iclog, *next_iclog; @@ -1738,7 +1738,7 @@ xlog_print_tic_res(xfs_mount_t *mp, xlog * we don't update ic_offset until the end when we know exactly how many * bytes have been written out. */ -int +STATIC int xlog_write(xfs_mount_t * mp, xfs_log_iovec_t reg[], int nentries, @@ -2280,7 +2280,7 @@ xlog_state_do_callback( * global state machine log lock. Assume that the calls to cvsema won't * take a long time. At least we know it won't sleep. */ -void +STATIC void xlog_state_done_syncing( xlog_in_core_t *iclog, int aborted) @@ -2340,7 +2340,7 @@ xlog_state_done_syncing( * needs to be incremented, depending on the amount of data which * is copied. */ -int +STATIC int xlog_state_get_iclog_space(xlog_t *log, int len, xlog_in_core_t **iclogp, @@ -2776,7 +2776,7 @@ xlog_ungrant_log_space(xlog_t *log, /* * Atomically put back used ticket. */ -void +STATIC void xlog_state_put_ticket(xlog_t *log, xlog_ticket_t *tic) { @@ -2794,7 +2794,7 @@ xlog_state_put_ticket(xlog_t *log, * * */ -int +STATIC int xlog_state_release_iclog(xlog_t *log, xlog_in_core_t *iclog) { @@ -3024,7 +3024,7 @@ no_sleep: * If filesystem activity goes to zero, the iclog will get flushed only by * bdflush(). */ -int +STATIC int xlog_state_sync(xlog_t *log, xfs_lsn_t lsn, uint flags, @@ -3129,7 +3129,7 @@ try_again: * Called when we want to mark the current iclog as being ready to sync to * disk. */ -void +STATIC void xlog_state_want_sync(xlog_t *log, xlog_in_core_t *iclog) { spin_lock(&log->l_icloglock); @@ -3241,7 +3241,7 @@ xlog_ticket_put(xlog_t *log, /* * Grab ticket off freelist or allocation some more */ -xlog_ticket_t * +STATIC xlog_ticket_t * xlog_ticket_get(xlog_t *log, int unit_bytes, int cnt, Index: 2.6.x-xfs-new/fs/xfs/xfs_log_recover.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_log_recover.c 2007-10-15 09:58:18.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_log_recover.c 2007-10-26 10:08:57.921691620 +1000 @@ -293,7 +293,7 @@ xlog_recover_iodone( * Note that the algorithm can not be perfect because the disk will not * necessarily be perfect. */ -int +STATIC int xlog_find_cycle_start( xlog_t *log, xfs_buf_t *bp, @@ -986,7 +986,7 @@ exit: * -1 => use *blk_no as the first block of the log * >0 => error has occurred */ -int +STATIC int xlog_find_zeroed( xlog_t *log, xfs_daddr_t *blk_no) @@ -2733,21 +2733,13 @@ xlog_recover_do_efd_trans( * AIL lock. */ xfs_trans_delete_ail(mp, lip); - break; + xfs_efi_item_free(efip); + return; } } lip = xfs_trans_next_ail(mp, lip, &gen, NULL); } - - /* - * If we found it, then free it up. If it wasn't there, it - * must have been overwritten in the log. Oh well. - */ - if (lip != NULL) { - xfs_efi_item_free(efip); - } else { - spin_unlock(&mp->m_ail_lock); - } + spin_unlock(&mp->m_ail_lock); } /* Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-10-16 08:52:58.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-10-26 10:08:57.925691105 +1000 @@ -2343,7 +2343,7 @@ out: spin_unlock(&mp->m_sb_lock); } -int +STATIC int xfs_icsb_modify_counters( xfs_mount_t *mp, xfs_sb_field_t field, Index: 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mru_cache.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c 2007-10-26 10:08:57.925691105 +1000 @@ -225,10 +225,14 @@ _xfs_mru_cache_list_insert( * list need to be deleted. For each element this involves removing it from the * data store, removing it from the reap list, calling the client's free * function and deleting the element from the element zone. + * + * We get called holding the mru->lock, which we drop and then reacquire. + * Sparse need special help with this to tell it we know what we are doing. */ STATIC void _xfs_mru_cache_clear_reap_list( - xfs_mru_cache_t *mru) + xfs_mru_cache_t *mru) __releases(mru->lock) __acquires(mru->lock) + { xfs_mru_cache_elem_t *elem, *next; struct list_head tmp; @@ -528,6 +532,10 @@ xfs_mru_cache_delete( * * If the element isn't found, this function returns NULL and the spinlock is * released. xfs_mru_cache_done() should NOT be called when this occurs. + * + * Because sparse isn't smart enough to know about conditional lock return + * status, we need to help it get it right by annotating the path that does + * not release the lock. */ void * xfs_mru_cache_lookup( @@ -545,8 +553,8 @@ xfs_mru_cache_lookup( if (elem) { list_del(&elem->list_node); _xfs_mru_cache_list_insert(mru, elem); - } - else + __release(mru_lock); /* help sparse not be stupid */ + } else spin_unlock(&mru->lock); return elem ? elem->value : NULL; @@ -575,6 +583,8 @@ xfs_mru_cache_peek( elem = radix_tree_lookup(&mru->store, key); if (!elem) spin_unlock(&mru->lock); + else + __release(mru_lock); /* help sparse not be stupid */ return elem ? elem->value : NULL; } @@ -586,7 +596,7 @@ xfs_mru_cache_peek( */ void xfs_mru_cache_done( - xfs_mru_cache_t *mru) + xfs_mru_cache_t *mru) __releases(mru->lock) { spin_unlock(&mru->lock); } Index: 2.6.x-xfs-new/fs/xfs/xfs_rename.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_rename.c 2007-09-12 15:41:22.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_rename.c 2007-10-26 10:08:57.925691105 +1000 @@ -39,6 +39,7 @@ #include "xfs_refcache.h" #include "xfs_utils.h" #include "xfs_trans_space.h" +#include "xfs_vnodeops.h" /* Index: 2.6.x-xfs-new/fs/xfs/xfs_trans.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_trans.h 2007-10-02 16:01:23.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_trans.h 2007-10-26 10:08:57.929690591 +1000 @@ -1001,6 +1001,8 @@ xfs_log_busy_slot_t *xfs_trans_add_busy( xfs_agnumber_t ag, xfs_extlen_t idx); +extern kmem_zone_t *xfs_trans_zone; + #endif /* __KERNEL__ */ #endif /* __XFS_TRANS_H__ */ Index: 2.6.x-xfs-new/fs/xfs/xfs_trans_item.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_trans_item.c 2007-01-16 10:54:19.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_trans_item.c 2007-10-26 10:08:57.929690591 +1000 @@ -21,6 +21,7 @@ #include "xfs_log.h" #include "xfs_inum.h" #include "xfs_trans.h" +#include "xfs_trans_priv.h" STATIC int xfs_trans_unlock_chunk(xfs_log_item_chunk_t *, int, int, xfs_lsn_t); Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-10-25 10:34:08.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-10-26 10:08:57.929690591 +1000 @@ -61,11 +61,6 @@ int xfs_init(void) { - extern kmem_zone_t *xfs_bmap_free_item_zone; - extern kmem_zone_t *xfs_btree_cur_zone; - extern kmem_zone_t *xfs_trans_zone; - extern kmem_zone_t *xfs_buf_item_zone; - extern kmem_zone_t *xfs_dabuf_zone; #ifdef XFS_DABUF_DEBUG extern spinlock_t xfs_dabuf_global_lock; spin_lock_init(&xfs_dabuf_global_lock); @@ -155,15 +150,9 @@ xfs_init(void) void xfs_cleanup(void) { - extern kmem_zone_t *xfs_bmap_free_item_zone; - extern kmem_zone_t *xfs_btree_cur_zone; extern kmem_zone_t *xfs_inode_zone; - extern kmem_zone_t *xfs_trans_zone; - extern kmem_zone_t *xfs_da_state_zone; - extern kmem_zone_t *xfs_dabuf_zone; extern kmem_zone_t *xfs_efd_zone; extern kmem_zone_t *xfs_efi_zone; - extern kmem_zone_t *xfs_buf_item_zone; extern kmem_zone_t *xfs_icluster_zone; xfs_cleanup_procfs(); From owner-xfs@oss.sgi.com Mon Oct 29 16:36:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:36:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNaXPh032247 for ; Mon, 29 Oct 2007 16:36:36 -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 KAA16328; Tue, 30 Oct 2007 10:36:37 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNaadD86255294; Tue, 30 Oct 2007 10:36:36 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNaZOZ86440430; Tue, 30 Oct 2007 10:36:35 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:36:35 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] Clean up bitops Message-ID: <20071029233635.GR995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13474 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 Use the generic bitops rather than implementing them ourselves. Patch inspired by Andi Kleen. Signed-off-by: Dave Chinner --- fs/xfs/xfs_bit.c | 103 --------------------------------------------------- fs/xfs/xfs_bit.h | 27 ++++++++++--- fs/xfs/xfs_rtalloc.c | 19 +++------ 3 files changed, 29 insertions(+), 120 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.c 2007-06-20 15:54:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.c 2007-10-05 08:48:48.107390247 +1000 @@ -25,109 +25,6 @@ * XFS bit manipulation routines, used in non-realtime code. */ -#ifndef HAVE_ARCH_HIGHBIT -/* - * Index of high bit number in byte, -1 for none set, 0..7 otherwise. - */ -static const char xfs_highbit[256] = { - -1, 0, 1, 1, 2, 2, 2, 2, /* 00 .. 07 */ - 3, 3, 3, 3, 3, 3, 3, 3, /* 08 .. 0f */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 10 .. 17 */ - 4, 4, 4, 4, 4, 4, 4, 4, /* 18 .. 1f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 20 .. 27 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 28 .. 2f */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 30 .. 37 */ - 5, 5, 5, 5, 5, 5, 5, 5, /* 38 .. 3f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 40 .. 47 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 48 .. 4f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 50 .. 57 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 58 .. 5f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 60 .. 67 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 68 .. 6f */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 70 .. 77 */ - 6, 6, 6, 6, 6, 6, 6, 6, /* 78 .. 7f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 80 .. 87 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 88 .. 8f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 90 .. 97 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* 98 .. 9f */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a0 .. a7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* a8 .. af */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b0 .. b7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* b8 .. bf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c0 .. c7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* c8 .. cf */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d0 .. d7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* d8 .. df */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e0 .. e7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* e8 .. ef */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f0 .. f7 */ - 7, 7, 7, 7, 7, 7, 7, 7, /* f8 .. ff */ -}; -#endif - -/* - * xfs_highbit32: get high bit set out of 32-bit argument, -1 if none set. - */ -inline int -xfs_highbit32( - __uint32_t v) -{ -#ifdef HAVE_ARCH_HIGHBIT - return highbit32(v); -#else - int i; - - if (v & 0xffff0000) - if (v & 0xff000000) - i = 24; - else - i = 16; - else if (v & 0x0000ffff) - if (v & 0x0000ff00) - i = 8; - else - i = 0; - else - return -1; - return i + xfs_highbit[(v >> i) & 0xff]; -#endif -} - -/* - * xfs_lowbit64: get low bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_lowbit64( - __uint64_t v) -{ - __uint32_t w = (__uint32_t)v; - int n = 0; - - if (w) { /* lower bits */ - n = ffs(w); - } else { /* upper bits */ - w = (__uint32_t)(v >> 32); - if (w && (n = ffs(w))) - n += 32; - } - return n - 1; -} - -/* - * xfs_highbit64: get high bit set out of 64-bit argument, -1 if none set. - */ -int -xfs_highbit64( - __uint64_t v) -{ - __uint32_t h = (__uint32_t)(v >> 32); - - if (h) - return xfs_highbit32(h) + 32; - return xfs_highbit32((__uint32_t)v); -} - - /* * Return whether bitmap is empty. * Size is number of words in the bitmap, which is padded to word boundary Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-06-20 15:54:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-10-05 09:07:20.574761334 +1000 @@ -47,13 +47,30 @@ static inline __uint64_t xfs_mask64lo(in } /* Get high bit set out of 32-bit argument, -1 if none set */ -extern int xfs_highbit32(__uint32_t v); - -/* Get low bit set out of 64-bit argument, -1 if none set */ -extern int xfs_lowbit64(__uint64_t v); +static inline int xfs_highbit32(__uint32_t v) +{ + return fls(v) - 1; +} /* Get high bit set out of 64-bit argument, -1 if none set */ -extern int xfs_highbit64(__uint64_t); +static inline int xfs_highbit64(__uint64_t v) +{ + return fls64(v) - 1; +} + +/* Get low bit set out of 32-bit argument, -1 if none set */ +static inline int xfs_lowbit32(__uint32_t v) +{ + unsigned long t = v; + return (v) ? find_first_bit(&t, 32) : -1; +} + +/* Get low bit set out of 64-bit argument, -1 if none set */ +static inline int xfs_lowbit64(__uint64_t v) +{ + unsigned long t = v; + return (v) ? find_first_bit(&t, 64) : -1; +} /* Return whether bitmap is empty (1 == empty) */ extern int xfs_bitmap_empty(uint *map, uint size); Index: 2.6.x-xfs-new/fs/xfs/xfs_rtalloc.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_rtalloc.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_rtalloc.c 2007-10-05 09:08:04.365058330 +1000 @@ -73,18 +73,6 @@ STATIC int xfs_rtmodify_summary(xfs_moun */ /* - * xfs_lowbit32: get low bit set out of 32-bit argument, -1 if none set. - */ -STATIC int -xfs_lowbit32( - __uint32_t v) -{ - if (v) - return ffs(v) - 1; - return -1; -} - -/* * Allocate space to the bitmap or summary file, and zero it, for growfs. */ STATIC int /* error */ @@ -444,6 +432,7 @@ xfs_rtallocate_extent_near( } bbno = XFS_BITTOBLOCK(mp, bno); i = 0; + ASSERT(minlen != 0); log2len = xfs_highbit32(minlen); /* * Loop over all bitmap blocks (bbno + i is current block). @@ -612,6 +601,8 @@ xfs_rtallocate_extent_size( xfs_suminfo_t sum; /* summary information for extents */ ASSERT(minlen % prod == 0 && maxlen % prod == 0); + ASSERT(maxlen != 0); + /* * Loop over all the levels starting with maxlen. * At each level, look at all the bitmap blocks, to see if there @@ -669,6 +660,9 @@ xfs_rtallocate_extent_size( *rtblock = NULLRTBLOCK; return 0; } + ASSERT(minlen != 0); + ASSERT(maxlen != 0); + /* * Loop over sizes, from maxlen down to minlen. * This time, when we do the allocations, allow smaller ones @@ -1954,6 +1948,7 @@ xfs_growfs_rt( nsbp->sb_blocksize * nsbp->sb_rextsize); nsbp->sb_rextents = nsbp->sb_rblocks; do_div(nsbp->sb_rextents, nsbp->sb_rextsize); + ASSERT(nsbp->sb_rextents != 0); nsbp->sb_rextslog = xfs_highbit32(nsbp->sb_rextents); nrsumlevels = nmp->m_rsumlevels = nsbp->sb_rextslog + 1; nrsumsize = From owner-xfs@oss.sgi.com Mon Oct 29 16:37:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:37:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNbeSB000367 for ; Mon, 29 Oct 2007 16:37:44 -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 KAA16386; Tue, 30 Oct 2007 10:37:44 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNbhdD86339397; Tue, 30 Oct 2007 10:37:43 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNbgDm86524703; Tue, 30 Oct 2007 10:37:42 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:37:42 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] fix inode allocation latency Message-ID: <20071029233742.GS995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13475 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 The log force added in xfs_iget_core() has been a performance issue since it was introduced for tight loops that allocate then unlink a single file. under heavy writeback, this can introduce unnecessary latency due tothe log I/o getting stuck behind bulk data writes. Fix this latency problem by avoinding the need for the log force by moving the place we mark linux inode dirty to the transaction commit rather than on transaction completion. This also closes a potential hole in the sync code where a linux inode is not dirty betwen the time it is modified and the time the log buffer has been written to disk. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_iops.c | 16 ++++++++++++++++ fs/xfs/xfs_iget.c | 18 ------------------ fs/xfs/xfs_inode.c | 34 +--------------------------------- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_inode_item.c | 5 +++++ 5 files changed, 23 insertions(+), 51 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-10-02 16:01:47.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-10-12 09:54:12.466194814 +1000 @@ -71,6 +71,22 @@ xfs_synchronize_atime( } /* + * If the linux inode exists, mark it dirty. + * Used when commiting a dirty inode into a transaction so that + * the inode will get written back by the linux code + */ +void +xfs_mark_inode_dirty_sync( + xfs_inode_t *ip) +{ + bhv_vnode_t *vp; + + vp = XFS_ITOV_NULL(ip); + if (vp) + mark_inode_dirty_sync(vn_to_inode(vp)); +} + +/* * Change the requested timestamp in the given inode. * We don't lock across timestamp updates, and we don't log them but * we do record the fact that there is dirty information in core. Index: 2.6.x-xfs-new/fs/xfs/xfs_iget.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iget.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_iget.c 2007-10-12 09:58:38.263910771 +1000 @@ -140,27 +140,9 @@ again: return ENOENT; } - /* - * There may be transactions sitting in the - * incore log buffers or being flushed to disk - * at this time. We can't clear the - * XFS_IRECLAIMABLE flag until these - * transactions have hit the disk, otherwise we - * will void the guarantee the flag provides - * xfs_iunpin() - */ - if (xfs_ipincount(ip)) { - read_unlock(&pag->pag_ici_lock); - xfs_log_force(mp, 0, - XFS_LOG_FORCE|XFS_LOG_SYNC); - XFS_STATS_INC(xs_ig_frecycle); - goto again; - } - xfs_itrace_exit_tag(ip, "xfs_iget.alloc"); XFS_STATS_INC(xs_ig_found); - xfs_iflags_clear(ip, XFS_IRECLAIMABLE); read_unlock(&pag->pag_ici_lock); Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.c 2007-10-11 09:53:53.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.c 2007-10-12 09:56:49.721912637 +1000 @@ -2807,40 +2807,8 @@ xfs_iunpin( { ASSERT(atomic_read(&ip->i_pincount) > 0); - if (atomic_dec_and_lock(&ip->i_pincount, &ip->i_flags_lock)) { - - /* - * If the inode is currently being reclaimed, the link between - * the bhv_vnode and the xfs_inode will be broken after the - * XFS_IRECLAIM* flag is set. Hence, if these flags are not - * set, then we can move forward and mark the linux inode dirty - * knowing that it is still valid as it won't freed until after - * the bhv_vnode<->xfs_inode link is broken in xfs_reclaim. The - * i_flags_lock is used to synchronise the setting of the - * XFS_IRECLAIM* flags and the breaking of the link, and so we - * can execute atomically w.r.t to reclaim by holding this lock - * here. - * - * However, we still need to issue the unpin wakeup call as the - * inode reclaim may be blocked waiting for the inode to become - * unpinned. - */ - - if (!__xfs_iflags_test(ip, XFS_IRECLAIM|XFS_IRECLAIMABLE)) { - bhv_vnode_t *vp = XFS_ITOV_NULL(ip); - struct inode *inode = NULL; - - BUG_ON(vp == NULL); - inode = vn_to_inode(vp); - BUG_ON(inode->i_state & I_CLEAR); - - /* make sync come back and flush this inode */ - if (!(inode->i_state & (I_NEW|I_FREEING))) - mark_inode_dirty_sync(inode); - } - spin_unlock(&ip->i_flags_lock); + if (atomic_dec_and_test(&ip->i_pincount)) wake_up(&ip->i_ipin_wait); - } } /* Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.h 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.h 2007-10-12 10:00:10.979948827 +1000 @@ -532,6 +532,7 @@ xfs_fsize_t xfs_file_last_byte(xfs_inode void xfs_lock_inodes(xfs_inode_t **, int, int, uint); void xfs_synchronize_atime(xfs_inode_t *); +void xfs_mark_inode_dirty_sync(xfs_inode_t *); xfs_bmbt_rec_host_t *xfs_iext_get_ext(xfs_ifork_t *, xfs_extnum_t); void xfs_iext_insert(xfs_ifork_t *, xfs_extnum_t, xfs_extnum_t, Index: 2.6.x-xfs-new/fs/xfs/xfs_inode_item.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode_item.c 2007-10-02 16:01:48.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode_item.c 2007-10-12 09:54:18.053474268 +1000 @@ -274,6 +274,11 @@ xfs_inode_item_format( */ xfs_synchronize_atime(ip); + /* + * make sure the linux inode is dirty + */ + xfs_mark_inode_dirty_sync(ip); + vecp->i_addr = (xfs_caddr_t)&ip->i_d; vecp->i_len = sizeof(xfs_dinode_core_t); XLOG_VEC_SET_TYPE(vecp, XLOG_REG_TYPE_ICORE); From owner-xfs@oss.sgi.com Mon Oct 29 16:38:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:38:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNcdoo000900 for ; Mon, 29 Oct 2007 16:38:42 -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 KAA16444; Tue, 30 Oct 2007 10:38:42 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNcfdD83559737; Tue, 30 Oct 2007 10:38:42 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNcf2F86352385; Tue, 30 Oct 2007 10:38:41 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:38:41 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] Implement fallocate Message-ID: <20071029233841.GT995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13476 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 XFS fallocate() callout. Allocate the range requested as unwritten extents. Atomically change the file size if requested. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_iops.c | 45 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-10-30 10:18:59.061735503 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-10-30 10:19:26.498185998 +1100 @@ -52,6 +52,7 @@ #include #include #include +#include /* * Bring the atime in the XFS inode uptodate. @@ -796,6 +797,49 @@ xfs_vn_removexattr( return namesp->attr_remove(vp, attr, xflags); } +/* + * generic space allocation vector. + */ +STATIC long +xfs_vn_fallocate( + struct inode *inode, + int mode, + loff_t offset, + loff_t len) +{ + long error; + loff_t new_size = 0; + xfs_flock64_t bf; + + /* preallocation on directories not yet supported */ + error = -ENODEV; + if (S_ISDIR(inode->i_mode)) + goto out_error; + + bf.l_whence = 0; + bf.l_start = offset; + bf.l_len = len; + + xfs_ilock(XFS_I(inode), XFS_IOLOCK_EXCL); + error = xfs_change_file_space(XFS_I(inode), XFS_IOC_RESVSP, &bf, + 0, NULL, ATTR_NOLOCK); + if (!error && !(mode & FALLOC_FL_KEEP_SIZE) && + offset + len > i_size_read(inode)) + new_size = offset + len; + + /* Change file size if needed */ + if (new_size) { + bhv_vattr_t va; + + va.va_mask = XFS_AT_SIZE; + va.va_size = new_size; + error = xfs_setattr(XFS_I(inode), &va, ATTR_NOLOCK, NULL); + } + + xfs_iunlock(XFS_I(inode), XFS_IOLOCK_EXCL); +out_error: + return error; +} const struct inode_operations xfs_inode_operations = { .permission = xfs_vn_permission, @@ -806,6 +850,7 @@ const struct inode_operations xfs_inode_ .getxattr = xfs_vn_getxattr, .listxattr = xfs_vn_listxattr, .removexattr = xfs_vn_removexattr, + .fallocate = xfs_vn_fallocate, }; const struct inode_operations xfs_dir_inode_operations = { From owner-xfs@oss.sgi.com Mon Oct 29 16:40:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:40:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNe8TJ001535 for ; Mon, 29 Oct 2007 16:40:11 -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 KAA16522; Tue, 30 Oct 2007 10:40:12 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNeBdD86543115; Tue, 30 Oct 2007 10:40:11 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNeAEl81421861; Tue, 30 Oct 2007 10:40:10 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:40:10 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com Subject: [PATCH] fix transaction overrun during writeback Message-ID: <20071029234010.GU995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13477 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 Prevent transaction overrun in xfs_iomap_write_allocate() if we rce with a truncate that overlaps the delalloc range we were planning to allocate. If we race, we may allocate into a hole and that requires block allocation. At this point in time we don't have a reservation for block allocation (apart from metadata blocks) and so allocating into a hole rather than a delalloc region results in overflowing the transaction block reservation. Fix it by only allowing a single extent to be allocated at a time. Signed-Off-By: Dave Chinner --- fs/xfs/xfs_iomap.c | 75 +++++++++++++++++++++++++++++++++++------------------ 1 file changed, 50 insertions(+), 25 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-10-30 10:18:58.777772241 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-10-30 10:19:30.365685668 +1100 @@ -702,6 +702,9 @@ retry: * the originating callers request. * * Called without a lock on the inode. + * + * We no longer bother to look at the incoming map - all we have to + * guarantee is that whatever we allocate fills the required range. */ int xfs_iomap_write_allocate( @@ -717,9 +720,9 @@ xfs_iomap_write_allocate( xfs_fsblock_t first_block; xfs_bmap_free_t free_list; xfs_filblks_t count_fsb; - xfs_bmbt_irec_t imap[XFS_STRAT_WRITE_IMAPS]; + xfs_bmbt_irec_t imap; xfs_trans_t *tp; - int i, nimaps, committed; + int nimaps, committed; int error = 0; int nres; @@ -766,13 +769,38 @@ xfs_iomap_write_allocate( XFS_BMAP_INIT(&free_list, &first_block); - nimaps = XFS_STRAT_WRITE_IMAPS; /* - * Ensure we don't go beyond eof - it is possible - * the extents changed since we did the read call, - * we dropped the ilock in the interim. + * it is possible that the extents have changed since + * we did the read call as we dropped the ilock for a + * while. We have to be careful about truncates or hole + * punchs here - we are not allowed to allocate + * non-delalloc blocks here. + * + * The only protection against truncation is the pages + * for the range we are being asked to convert are + * locked and hence a truncate will block on them + * first. + * + * As a result, if we go beyond the range we really + * need and hit an delalloc extent boundary followed by + * a hole while we have excess blocks in the map, we + * will fill the hole incorrectly and overrun the + * transaction reservation. + * + * Using a single map prevents this as we are forced to + * check each map we look for overlap with the desired + * range and abort as soon as we find it. Also, given + * that we only return a single map, having one beyond + * what we can return is probably a bit silly. + * + * We also need to check that we don't go beyond EOF; + * this is a truncate optimisation as a truncate sets + * the new file size before block on the pages we + * currently have locked under writeback. Because they + * are about to be tossed, we don't need to write them + * back.... */ - + nimaps = 1; end_fsb = XFS_B_TO_FSB(mp, ip->i_size); xfs_bmap_last_offset(NULL, ip, &last_block, XFS_DATA_FORK); @@ -788,7 +816,7 @@ xfs_iomap_write_allocate( /* Go get the actual blocks */ error = xfs_bmapi(tp, ip, map_start_fsb, count_fsb, XFS_BMAPI_WRITE, &first_block, 1, - imap, &nimaps, &free_list, NULL); + &imap, &nimaps, &free_list, NULL); if (error) goto trans_cancel; @@ -807,27 +835,24 @@ xfs_iomap_write_allocate( * See if we were able to allocate an extent that * covers at least part of the callers request */ - for (i = 0; i < nimaps; i++) { - if (unlikely(!imap[i].br_startblock && - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) - return xfs_cmn_err_fsblock_zero(ip, &imap[i]); - if ((offset_fsb >= imap[i].br_startoff) && - (offset_fsb < (imap[i].br_startoff + - imap[i].br_blockcount))) { - *map = imap[i]; - *retmap = 1; - XFS_STATS_INC(xs_xstrat_quick); - return 0; - } - count_fsb -= imap[i].br_blockcount; + if (unlikely(!imap.br_startblock && + XFS_IS_REALTIME_INODE(ip))) + return xfs_cmn_err_fsblock_zero(ip, &imap); + if ((offset_fsb >= imap.br_startoff) && + (offset_fsb < (imap.br_startoff + + imap.br_blockcount))) { + *map = imap; + *retmap = 1; + XFS_STATS_INC(xs_xstrat_quick); + return 0; } - /* So far we have not mapped the requested part of the + /* + * So far we have not mapped the requested part of the * file, just surrounding data, try again. */ - nimaps--; - map_start_fsb = imap[nimaps].br_startoff + - imap[nimaps].br_blockcount; + count_fsb -= imap.br_blockcount; + map_start_fsb = imap.br_startoff + imap.br_blockcount; } trans_cancel: From owner-xfs@oss.sgi.com Mon Oct 29 16:42:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:42:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from rgminet02.oracle.com (rgminet02.oracle.com [148.87.113.119]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9TNg0eM002037 for ; Mon, 29 Oct 2007 16:42:00 -0700 Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by rgminet02.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9TMeSiD015342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2007 16:40:32 -0600 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l9TMeCHJ017424; Mon, 29 Oct 2007 16:40:12 -0600 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l9TMeCF0005130; Mon, 29 Oct 2007 16:40:12 -0600 Received: from mfasheh by ca-server1.us.oracle.com with local (Exim 4.67) (envelope-from ) id 1ImdHH-0001fe-R0; Mon, 29 Oct 2007 15:40:11 -0700 Date: Mon, 29 Oct 2007 15:40:11 -0700 From: Mark Fasheh To: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071029224011.GC28607@ca-server1.us.oracle.com> Reply-To: Mark Fasheh References: <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> <20071029205744.GB28607@ca-server1.us.oracle.com> <20071029221302.GD3042@webber.adilger.int> <20071029222907.GF3042@webber.adilger.int> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029222907.GF3042@webber.adilger.int> Organization: Oracle Corporation User-Agent: Mutt/1.5.16 (2007-06-11) X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13478 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mark.fasheh@oracle.com Precedence: bulk X-list: xfs On Mon, Oct 29, 2007 at 04:29:07PM -0600, Andreas Dilger wrote: > On Oct 29, 2007 16:13 -0600, Andreas Dilger wrote: > > On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote: > > > I'm a little bit confused by fe_offset. Is it a physical offset, or a > > > logical offset? The reason I ask is that your description above says "FIEMAP > > > ioctl will return the logical to physical mapping for the extent that > > > contains the specified logical byte address." Which seems to imply physical, > > > but your math to get to the next logical start in a very fragmented file, > > > implies that fe_offset is a logical offset: > > > > > > fm_start = fm_extents[fm_extent_count - 1].fe_offset + > > > fm_extents[fm_extent_count - 1].fe_length + 1; > > > > Note the distinction between "fe_offset" (which is a physical offset for > > a single extent) and "fm_offset" (which is a logical offset for that file). > > Actually, that is completely bunk. What it should say is something like: > "filefrag can easily call the FIEMAP ioctls repeatedly using the returned > fm_start and fm_length as the start offset for the next ioctl: > > fiemap.fm_start = fiemap.fm_start + fiemap.fm_length + 1; Yeah - that's where I was going with my question. This is much more clear now, thanks. --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com From owner-xfs@oss.sgi.com Mon Oct 29 16:48:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 16:48:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9TNmk9M002911 for ; Mon, 29 Oct 2007 16:48:50 -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 KAA16831; Tue, 30 Oct 2007 10:48:47 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9TNmhdD64784421; Tue, 30 Oct 2007 10:48:47 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9TNmh9Z85583188; Tue, 30 Oct 2007 10:48:43 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 30 Oct 2007 10:48:43 +1100 From: David Chinner To: Niv Sardi Cc: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071029234843.GV995458@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029075657.GA84369978@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13479 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 On Mon, Oct 29, 2007 at 06:56:57PM +1100, Niv Sardi wrote: > Hello, > > XFS's default mount options are in most cases sub-optimal, we should try > to have more sensible defaults, so far I'm following some quick dave-powered > recomendations: > > - version 2 logs > - attr2 > - lazy superblock counters > - less allocation groups for single disk configs > > - imaxpct default can be reduced > > it is currently 25, what would be reasonable ? > > - dropping the ability to turn unwritten extents off completely > > please submit your pet-idea for better defaults here. Another one for you - make the log larger. The kernel code supports a log of up to 2GB, so mkfs could making a larger log without requiring changes elsewhere. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Oct 29 17:11:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 17:11:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9U0Baeo004973 for ; Mon, 29 Oct 2007 17:11:38 -0700 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l9U0BRqo017697; Mon, 29 Oct 2007 19:11:27 -0500 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l9U0BQ6Z014878; Mon, 29 Oct 2007 18:11:26 -0600 Received: from mfasheh by ca-server1.us.oracle.com with local (Exim 4.67) (envelope-from ) id 1Imeha-0003Kf-Bk; Mon, 29 Oct 2007 17:11:26 -0700 Date: Mon, 29 Oct 2007 17:11:26 -0700 From: Mark Fasheh To: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071030001126.GD28607@ca-server1.us.oracle.com> Reply-To: Mark Fasheh References: <20070419002139.GK5967@schatzie.adilger.int> <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> <20071029205744.GB28607@ca-server1.us.oracle.com> <20071029221302.GD3042@webber.adilger.int> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029221302.GD3042@webber.adilger.int> Organization: Oracle Corporation User-Agent: Mutt/1.5.16 (2007-06-11) X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13480 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mark.fasheh@oracle.com Precedence: bulk X-list: xfs On Mon, Oct 29, 2007 at 04:13:02PM -0600, Andreas Dilger wrote: > On Oct 29, 2007 13:57 -0700, Mark Fasheh wrote: > > Thanks for posting this. I believe that an interface such as FIEMAP > > would be very useful to Ocfs2 as well. (I added ocfs2-devel to the e-mail) > > I tried to make it as Lustre-agnostic as possible... IMHO, your description succeeded at that. I'm hoping that the final patch can have mostly generic code, like FIBMAP does today. > > > #define FIEMAP_EXTENT_LAST 0x00000020 /* last extent in the file */ > > > #define FIEMAP_EXTENT_EOF 0x00000100 /* fm_start + fm_len beyond EOF*/ > > > > Is "EOF" here considering "beyond i_size" or "beyond allocation"? > > _EOF == beyond i_size. > _LAST == last extent in the file. > > In most cases FIEMAP_EXTENT_EOF will be set at the same time as > FIEMAP_EXTENT_LAST, but in case of e.g. prealloc beyond i_size the > EOF flag may be set on one or more earlier extents. Oh, ok great - I was primarily looking for a way to say "there's allocation past i_size" and it looks like we have it. > > > FIEMAP_EXTENT_NO_DIRECT means data cannot be directly accessed (maybe > > > encrypted, compressed, etc.) > > > > Would it be valid to use FIEMAP_EXTENT_NO_DIRECT for marking in-inode data? > > Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode > > blocks. > > Hmm, but part of the issue would be how to request the extra data, and > what offset it would be given? One could, for example, use negative > offsets to represent metadata or something, or add a FIEMAP_EXTENT_META > or similar, I hadn't given that much thought. Well, fe_offset and fe_length are already expressed in bytes, so we could just put the byte offset to where the inline data starts in there. fe_length is just used as the length allocated for inline-data. If fe_offset is required to be block aligned, then we could add a field to express an offset within the block where data would be found - say 'fe_data_start_offset'. In the non-inline case, we could guarantee that fe_data_start_offset is zero. That way software which doesn't want to care whether something is inline-data (for example, a backup program) or not could just blidly add it to fe_offset before looking at the data. Regardless, I think we also want to explicitely flag this: #define FIEMAP_EXTENT_DATA_IN_INODE 0x00000400 /* extent data is stored in inode block */ I'm going to pretend that I completely understand reiserfs tail-packing and say that my approaches above looks like they could work for that case too. We'd want to add a seperate flag for tail packed data though. > The other issue is that I'd like to get the basics of the API in place > before it gets too complex. We can always add functionality with more > FIEMAP_FLAG_* (whether in the INCOMPAT range or not, depending on what is > being done). Sure, but I think whatever goes upstream should be able to handle this case - there's file systems in use _today_ which put data in inode blocks and pack file tails. Thanks, --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com From owner-xfs@oss.sgi.com Mon Oct 29 17:26:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 17:26:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from mail.clusterfs.com (mail.clusterfs.com [74.0.229.162]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9U0PvBN006687 for ; Mon, 29 Oct 2007 17:26:00 -0700 Received: from webber.adilger.int (S0106000bdb95b39c.cg.shawcable.net [70.72.213.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id 85D004E455D; Mon, 29 Oct 2007 17:26:00 -0700 (MST) Received: by webber.adilger.int (Postfix, from userid 1000) id 0B9BD42E90; Mon, 29 Oct 2007 18:25:59 -0600 (MDT) Date: Mon, 29 Oct 2007 18:25:59 -0600 From: Andreas Dilger To: Mark Fasheh Cc: linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com Subject: Re: [RFC] add FIEMAP ioctl to efficiently map file allocation Message-ID: <20071030002559.GH3042@webber.adilger.int> Mail-Followup-To: Mark Fasheh , linux-fsdevel@vger.kernel.org, David Chinner , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org, Anton Altaparmakov , Mike Waychison , ocfs2-devel@oss.oracle.com References: <20070419015426.GM48531920@melbourne.sgi.com> <20070430224401.GX5967@schatzie.adilger.int> <20070501042254.GD77450368@melbourne.sgi.com> <1FA8E92B-954D-4624-A089-80D4AA7399FD@cam.ac.uk> <20070502000654.GK77450368@melbourne.sgi.com> <8464EA47-03AC-4162-A2D0-683517568640@cam.ac.uk> <20071029194507.GA8578@webber.adilger.int> <20071029205744.GB28607@ca-server1.us.oracle.com> <20071029221302.GD3042@webber.adilger.int> <20071030001126.GD28607@ca-server1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030001126.GD28607@ca-server1.us.oracle.com> X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13481 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adilger@sun.com Precedence: bulk X-list: xfs On Oct 29, 2007 17:11 -0700, Mark Fasheh wrote: > On Mon, Oct 29, 2007 at 04:13:02PM -0600, Andreas Dilger wrote: > > > Btrfs, Ocfs2, and Gfs2 pack small amounts of user data directly in inode > > > blocks. > > > > Hmm, but part of the issue would be how to request the extra data, and > > what offset it would be given? One could, for example, use negative > > offsets to represent metadata or something, or add a FIEMAP_EXTENT_META > > or similar, I hadn't given that much thought. > > Well, fe_offset and fe_length are already expressed in bytes, so we could > just put the byte offset to where the inline data starts in there. fe_length > is just used as the length allocated for inline-data. > > If fe_offset is required to be block aligned, then we could add a field to > express an offset within the block where data would be found - say > 'fe_data_start_offset'. In the non-inline case, we could guarantee that > fe_data_start_offset is zero. That way software which doesn't want to care > whether something is inline-data (for example, a backup program) or not > could just blidly add it to fe_offset before looking at the data. Oh, I was confused as to what you are asking. Mapping in-inode data is just fine using the existing interface. The byte offset of the data is given, and the "FIEMAP_EXTENT_NO_DIRECT" flag is set to indicate that it isn't necessarily safe to do IO directly to that byte offset in the file (e.g. tail packed, compressed data, etc). I was thinking you were asking how to map metadata (e.g. indirect blocks). Cheers, Andreas -- Andreas Dilger Sr. Software Engineer, Lustre Group Sun Microsystems of Canada, Inc. From owner-xfs@oss.sgi.com Mon Oct 29 17:46:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 17:46:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9U0k41w008782 for ; Mon, 29 Oct 2007 17:46:06 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18413; Tue, 30 Oct 2007 11:46:01 +1100 Message-ID: <47267EC7.8000906@sgi.com> Date: Tue, 30 Oct 2007 11:45:59 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Sandeen CC: Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> In-Reply-To: <4725FBB4.1010400@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13482 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 Eric Sandeen wrote: > Niv Sardi wrote: >> Hello, >> >> XFS's default mount options are in most cases sub-optimal, we should try >> to have more sensible defaults, so far I'm following some quick dave-powered >> recomendations: >> >> - version 2 logs >> - attr2 >> - lazy superblock counters >> - less allocation groups for single disk configs >> >> - imaxpct default can be reduced >> >> it is currently 25, what would be reasonable ? >> >> - dropping the ability to turn unwritten extents off completely >> >> please submit your pet-idea for better defaults here. > > Sorry for all the replies ;-) > > What would you think of a mkfs conf file like e2fsprogs has, which > defines filesystem classes, and defaults for each? (small, news, > largefile, etc...) > > -Eric > It might be interesting if people let us know what non-default mkfs and mount options that they are using for their various configurations/classes. Didn't Russell C. have some survey years ago - can't remember if that was for h/ware or what now. Maybe Dave C. or others have some suggestions from performance runs for various types of workloads. Do we have this compiled somewhere? --Tim From owner-xfs@oss.sgi.com Mon Oct 29 21:06:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 29 Oct 2007 21:06:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9U469nL031039 for ; Mon, 29 Oct 2007 21:06:12 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA22480; Tue, 30 Oct 2007 15:06:07 +1100 Message-ID: <4726ADAE.9070206@sgi.com> Date: Tue, 30 Oct 2007 15:06:06 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Roger Willcocks CC: xfs@oss.sgi.com Subject: Re: bug: truncate to zero + setuid References: <47249E7A.7060709@filmlight.ltd.uk> <47252F62.6030503@sgi.com> <47262CD0.5010708@filmlight.ltd.uk> In-Reply-To: <47262CD0.5010708@filmlight.ltd.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4625/Mon Oct 29 15:24:30 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13483 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 Roger Willcocks wrote: > Tim Shimmin wrote: >> Hi Roger, >> >> Roger Willcocks wrote: >>> The nfsv3 setattr call permits a simultaneous truncate + setuid/gid >>> operation. Normally XFS handles this fine, but if the file's being >>> truncated to zero, and the file's already empty, XFS simply ignores >>> the setuid/gid part, returning 'success'. >>> >>> The error's in xfs_vnodeops.c/xfs_setattr below the comment 'Short >>> circuit the truncate case for zero length files', which bypasses all >>> other changes. >>> >>> The simplest fix is to test whether this is the only change that's >>> happening, otherwise you get tangled in transactions. >>> >>> if (mask & XFS_AT_SIZE) { >>> /* Short circuit the truncate case for zero length >>> files */ >>> - if ((vap->va_size == 0) && >>> + if (((mask & ~XFS_AT_SIZE) == 0) && (vap->va_size == >>> 0) && >>> (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == >>> 0)) { >>> >>> >>> -- >>> Roger >>> >> >> Yeah, I see your problem. >> It is interesting to know how much of multiple actions (different >> bits of mask) are supported. >> XFS_AT_UPDTIMES doesn't support anything else and will return quickly. >> As far as code which goes via error_return, it looks like the >> only non-error case is the short-circuit one mentioned above - >> truncating to zero an already zeroed file. >> >> I see your fix will get what we want although, it will mean that we >> will go thru the truncating path when we don't need to. >> It would be nice if we could act like the XFS_AT_SIZE was never set >> on the call in the case that other bits are set. >> Though when we first test the AT_SIZE, we don't have the inode locked. >> And I presume in that case we don't necessarily need to send a >> DMAPI truncate event? >> So I wonder if before the 1st AT_SIZE test that we have now, >> in the AT_SIZE case and with other bits set, >> we could lock the inode and test >> for the zero truncate of zero-len file and if so then remove the >> AT_SIZE bit >> and then go on to the other testing as if AT_SIZE was never set. >> Hmmm, may be that just complicates things too much. >> > Yes I looked at simply unsetting the XFS_AT_SIZE bit (you'd also need to > set > timeflags appropriately) but the problem is the bit's used to check when > to create > a transaction - either up front as XFS_TRANS_SETATTR_NOT_SIZE, or > later on, after the inode's been locked and unlocked again, as > XFS_TRANS_SETATTR_SIZE. So if you unset the bit (and there's still more > to do) you need to build a not_size transaction, at which point you > might as well > rewrite the whole routine... > > -- > Roger So this was done by Steve L. for AIM performance... ---------------------------- revision 1.446 date: 2000/06/09 02:59:45; author: lord; state: Exp; lines: +11 -0 modid: 2.4.0-test1-xfs:slinx:55891a Merge of 2.3.99pre2-xfs:slinx:55891a by ananth. Short circuit the case where we truncate a zero length file down to zero length so that we do not do a transaction. This close to doubles create/close AIM run performance. ---------------------------- > p_rdiff -r1.445,1.446 xfs_vnodeops.c 746a747,757 > /* Short circuit the truncate case for zero length files */ > if ((vap->va_size == 0) && > (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == 0)) { > xfs_iunlock(ip, XFS_ILOCK_EXCL); > lock_flags &= ~XFS_ILOCK_EXCL; > if (mask & AT_CTIME) > xfs_ichgtime(ip, XFS_ICHGTIME_CHG); > code = 0; > goto error_return; > } > ---------------------------- revision 1.506 date: 2001/06/26 22:07:29; author: lord; state: Exp; lines: +1 -1 modid: 2.4.x-xfs:slinx:97694a Set the mtime on a zero length file when a create is being done on top of it. ---------------------------- > p_rdiff -r1.505,1.506 xfs_vnodeops.c 526c526 < xfs_ichgtime(ip, XFS_ICHGTIME_CHG); --- > xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); I presume it was done where it was done so that the inode was locked and we were under the XFS_AT_SIZE predicate. I was just thinking of something like... but I'm probably missing something. Index: 2.6.x-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-10-12 16:06:15.000000000 +1000 +++ 2.6.x-xfs/fs/xfs/xfs_vnodeops.c 2007-10-30 14:59:46.418837757 +1100 @@ -304,6 +304,24 @@ } /* + * Short circuit the truncate case for zero length files. + * If more mask bits are set, then just remove the SIZE one + * and keep going. + */ + if (mask & XFS_AT_SIZE) { + xfs_ilock(ip, XFS_ILOCK_SHARED); + if ((vap->va_size == 0) && (ip->i_size == 0) && (ip->i_d.di_nextents == 0)) { + if (mask & ~XFS_AT_SIZE) { + mask &= ~XFS_AT_SIZE; + } else { + xfs_iunlock(ip, XFS_ILOCK_SHARED); + return 0; + } + } + xfs_iunlock(ip, XFS_ILOCK_SHARED); + } + + /* * For the other attributes, we acquire the inode lock and * first do an error checking pass. */ @@ -451,17 +469,6 @@ * Truncate file. Must have write permission and not be a directory. */ if (mask & XFS_AT_SIZE) { - /* Short circuit the truncate case for zero length files */ - if ((vap->va_size == 0) && - (ip->i_size == 0) && (ip->i_d.di_nextents == 0)) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - lock_flags &= ~XFS_ILOCK_EXCL; - if (mask & XFS_AT_CTIME) - xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - code = 0; - goto error_return; - } - if (VN_ISDIR(vp)) { code = XFS_ERROR(EISDIR); goto error_return; From owner-xfs@oss.sgi.com Tue Oct 30 00:20:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 00:20:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9U7KfnO007069 for ; Tue, 30 Oct 2007 00:20:43 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA26431; Tue, 30 Oct 2007 18:20:38 +1100 Message-ID: <4726DB57.2040609@sgi.com> Date: Tue, 30 Oct 2007 18:20:55 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Clean up sparse warnings References: <20071029233442.GP995458@sgi.com> In-Reply-To: <20071029233442.GP995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4627/Mon Oct 29 22:09:53 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13484 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Looks good Dave. David Chinner wrote: > Clean up most outstanding sparse warnings. > > These are mostly locking annotations, marking things static, > casts where needed and declaring stuff in header files. > > Signed-Off-By: Dave Chinner > --- > fs/xfs/linux-2.6/xfs_globals.c | 3 ++- > fs/xfs/linux-2.6/xfs_ioctl.c | 2 +- > fs/xfs/linux-2.6/xfs_ioctl32.c | 1 + > fs/xfs/xfs_attr.c | 2 +- > fs/xfs/xfs_bmap.c | 6 +++--- > fs/xfs/xfs_bmap.h | 2 ++ > fs/xfs/xfs_btree.h | 2 ++ > fs/xfs/xfs_buf_item.h | 2 ++ > fs/xfs/xfs_da_btree.h | 1 + > fs/xfs/xfs_dir2.c | 1 + > fs/xfs/xfs_filestream.c | 2 +- > fs/xfs/xfs_log.c | 24 ++++++++++++------------ > fs/xfs/xfs_log_recover.c | 18 +++++------------- > fs/xfs/xfs_mount.c | 2 +- > fs/xfs/xfs_mru_cache.c | 18 ++++++++++++++---- > fs/xfs/xfs_rename.c | 1 + > fs/xfs/xfs_trans.h | 2 ++ > fs/xfs/xfs_trans_item.c | 1 + > fs/xfs/xfs_vfsops.c | 11 ----------- > 19 files changed, 53 insertions(+), 48 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_globals.c 2007-10-02 16:01:46.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_globals.c 2007-10-26 10:08:57.901694193 +1000 > @@ -47,5 +47,6 @@ xfs_param_t xfs_params = { > /* > * Global system credential structure. > */ > -cred_t sys_cred_val, *sys_cred = &sys_cred_val; > +static cred_t sys_cred_val; > +cred_t *sys_cred = &sys_cred_val; > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2007-10-02 16:01:47.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl.c 2007-10-26 10:08:57.901694193 +1000 > @@ -512,7 +512,7 @@ xfs_attrmulti_attr_get( > if (!kbuf) > return ENOMEM; > > - error = xfs_attr_get(XFS_I(inode), name, kbuf, len, flags, NULL); > + error = xfs_attr_get(XFS_I(inode), name, kbuf, (int *)len, flags, NULL); > if (error) > goto out_kfree; > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl32.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_ioctl32.c 2007-10-15 09:58:18.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_ioctl32.c 2007-10-26 10:08:57.905693678 +1000 > @@ -44,6 +44,7 @@ > #include "xfs_error.h" > #include "xfs_dfrag.h" > #include "xfs_vnodeops.h" > +#include "xfs_ioctl32.h" > > #define _NATIVE_IOC(cmd, type) \ > _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(type)) > Index: 2.6.x-xfs-new/fs/xfs/xfs_attr.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_attr.c 2007-08-24 22:25:22.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_attr.c 2007-10-26 10:08:57.905693678 +1000 > @@ -929,7 +929,7 @@ xfs_attr_shortform_addname(xfs_da_args_t > * This leaf block cannot have a "remote" value, we only call this routine > * if bmap_one_block() says there is only one block (ie: no remote blks). > */ > -int > +STATIC int > xfs_attr_leaf_addname(xfs_da_args_t *args) > { > xfs_inode_t *dp; > Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.c 2007-10-02 16:01:47.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.c 2007-10-26 10:08:57.909693163 +1000 > @@ -6393,7 +6393,7 @@ xfs_bmap_count_blocks( > * Recursively walks each level of a btree > * to count total fsblocks is use. > */ > -int /* error */ > +STATIC int /* error */ > xfs_bmap_count_tree( > xfs_mount_t *mp, /* file system mount point */ > xfs_trans_t *tp, /* transaction pointer */ > @@ -6469,7 +6469,7 @@ xfs_bmap_count_tree( > /* > * Count leaf blocks given a range of extent records. > */ > -int > +STATIC int > xfs_bmap_count_leaves( > xfs_ifork_t *ifp, > xfs_extnum_t idx, > @@ -6489,7 +6489,7 @@ xfs_bmap_count_leaves( > * Count leaf blocks given a range of extent records originally > * in btree format. > */ > -int > +STATIC int > xfs_bmap_disk_count_leaves( > xfs_extnum_t idx, > xfs_bmbt_block_t *block, > Index: 2.6.x-xfs-new/fs/xfs/xfs_bmap.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bmap.h 2007-08-24 22:25:22.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_bmap.h 2007-10-26 10:08:57.909693163 +1000 > @@ -25,6 +25,8 @@ struct xfs_inode; > struct xfs_mount; > struct xfs_trans; > > +extern kmem_zone_t *xfs_bmap_free_item_zone; > + > /* > * DELTA: describe a change to the in-core extent list. > * > Index: 2.6.x-xfs-new/fs/xfs/xfs_btree.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_btree.h 2007-06-20 15:54:59.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_btree.h 2007-10-26 10:08:57.913692649 +1000 > @@ -24,6 +24,8 @@ struct xfs_inode; > struct xfs_mount; > struct xfs_trans; > > +extern kmem_zone_t *xfs_btree_cur_zone; > + > /* > * This nonsense is to make -wlint happy. > */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_buf_item.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_buf_item.h 2007-10-02 16:01:47.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_buf_item.h 2007-10-26 10:08:57.913692649 +1000 > @@ -18,6 +18,8 @@ > #ifndef __XFS_BUF_ITEM_H__ > #define __XFS_BUF_ITEM_H__ > > +extern kmem_zone_t *xfs_buf_item_zone; > + > /* > * This is the structure used to lay out a buf log item in the > * log. The data map describes which 128 byte chunks of the buffer > Index: 2.6.x-xfs-new/fs/xfs/xfs_da_btree.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_da_btree.h 2007-02-07 13:24:33.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/xfs_da_btree.h 2007-10-26 10:08:57.913692649 +1000 > @@ -260,6 +260,7 @@ void xfs_da_binval(struct xfs_trans *tp, > xfs_daddr_t xfs_da_blkno(xfs_dabuf_t *dabuf); > > extern struct kmem_zone *xfs_da_state_zone; > +extern struct kmem_zone *xfs_dabuf_zone; > #endif /* __KERNEL__ */ > > #endif /* __XFS_DA_BTREE_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2.c 2007-09-12 15:41:22.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2.c 2007-10-26 10:08:57.913692649 +1000 > @@ -42,6 +42,7 @@ > #include "xfs_dir2_node.h" > #include "xfs_dir2_trace.h" > #include "xfs_error.h" > +#include "xfs_vnodeops.h" > > > void > Index: 2.6.x-xfs-new/fs/xfs/xfs_filestream.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_filestream.c 2007-10-02 16:01:22.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_filestream.c 2007-10-26 10:08:57.917692134 +1000 > @@ -348,7 +348,7 @@ _xfs_filestream_update_ag( > } > > /* xfs_fstrm_free_func(): callback for freeing cached stream items. */ > -void > +STATIC void > xfs_fstrm_free_func( > unsigned long ino, > void *data) > Index: 2.6.x-xfs-new/fs/xfs/xfs_log.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_log.c 2007-10-02 16:01:48.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_log.c 2007-10-26 10:08:57.917692134 +1000 > @@ -907,7 +907,7 @@ xlog_assign_tail_lsn(xfs_mount_t *mp) > * the tail. The details of this case are described below, but the end > * result is that we return the size of the log as the amount of space left. > */ > -int > +STATIC int > xlog_space_left(xlog_t *log, int cycle, int bytes) > { > int free_bytes; > @@ -1289,7 +1289,7 @@ xlog_commit_record(xfs_mount_t *mp, > * pushes on an lsn which is further along in the log once we reach the high > * water mark. In this manner, we would be creating a low water mark. > */ > -void > +STATIC void > xlog_grant_push_ail(xfs_mount_t *mp, > int need_bytes) > { > @@ -1372,7 +1372,7 @@ xlog_grant_push_ail(xfs_mount_t *mp, > * is added immediately before calling bwrite(). > */ > > -int > +STATIC int > xlog_sync(xlog_t *log, > xlog_in_core_t *iclog) > { > @@ -1516,7 +1516,7 @@ xlog_sync(xlog_t *log, > /* > * Deallocate a log structure > */ > -void > +STATIC void > xlog_dealloc_log(xlog_t *log) > { > xlog_in_core_t *iclog, *next_iclog; > @@ -1738,7 +1738,7 @@ xlog_print_tic_res(xfs_mount_t *mp, xlog > * we don't update ic_offset until the end when we know exactly how many > * bytes have been written out. > */ > -int > +STATIC int > xlog_write(xfs_mount_t * mp, > xfs_log_iovec_t reg[], > int nentries, > @@ -2280,7 +2280,7 @@ xlog_state_do_callback( > * global state machine log lock. Assume that the calls to cvsema won't > * take a long time. At least we know it won't sleep. > */ > -void > +STATIC void > xlog_state_done_syncing( > xlog_in_core_t *iclog, > int aborted) > @@ -2340,7 +2340,7 @@ xlog_state_done_syncing( > * needs to be incremented, depending on the amount of data which > * is copied. > */ > -int > +STATIC int > xlog_state_get_iclog_space(xlog_t *log, > int len, > xlog_in_core_t **iclogp, > @@ -2776,7 +2776,7 @@ xlog_ungrant_log_space(xlog_t *log, > /* > * Atomically put back used ticket. > */ > -void > +STATIC void > xlog_state_put_ticket(xlog_t *log, > xlog_ticket_t *tic) > { > @@ -2794,7 +2794,7 @@ xlog_state_put_ticket(xlog_t *log, > * > * > */ > -int > +STATIC int > xlog_state_release_iclog(xlog_t *log, > xlog_in_core_t *iclog) > { > @@ -3024,7 +3024,7 @@ no_sleep: > * If filesystem activity goes to zero, the iclog will get flushed only by > * bdflush(). > */ > -int > +STATIC int > xlog_state_sync(xlog_t *log, > xfs_lsn_t lsn, > uint flags, > @@ -3129,7 +3129,7 @@ try_again: > * Called when we want to mark the current iclog as being ready to sync to > * disk. > */ > -void > +STATIC void > xlog_state_want_sync(xlog_t *log, xlog_in_core_t *iclog) > { > spin_lock(&log->l_icloglock); > @@ -3241,7 +3241,7 @@ xlog_ticket_put(xlog_t *log, > /* > * Grab ticket off freelist or allocation some more > */ > -xlog_ticket_t * > +STATIC xlog_ticket_t * > xlog_ticket_get(xlog_t *log, > int unit_bytes, > int cnt, > Index: 2.6.x-xfs-new/fs/xfs/xfs_log_recover.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_log_recover.c 2007-10-15 09:58:18.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_log_recover.c 2007-10-26 10:08:57.921691620 +1000 > @@ -293,7 +293,7 @@ xlog_recover_iodone( > * Note that the algorithm can not be perfect because the disk will not > * necessarily be perfect. > */ > -int > +STATIC int > xlog_find_cycle_start( > xlog_t *log, > xfs_buf_t *bp, > @@ -986,7 +986,7 @@ exit: > * -1 => use *blk_no as the first block of the log > * >0 => error has occurred > */ > -int > +STATIC int > xlog_find_zeroed( > xlog_t *log, > xfs_daddr_t *blk_no) > @@ -2733,21 +2733,13 @@ xlog_recover_do_efd_trans( > * AIL lock. > */ > xfs_trans_delete_ail(mp, lip); > - break; > + xfs_efi_item_free(efip); > + return; > } > } > lip = xfs_trans_next_ail(mp, lip, &gen, NULL); > } > - > - /* > - * If we found it, then free it up. If it wasn't there, it > - * must have been overwritten in the log. Oh well. > - */ > - if (lip != NULL) { > - xfs_efi_item_free(efip); > - } else { > - spin_unlock(&mp->m_ail_lock); > - } > + spin_unlock(&mp->m_ail_lock); > } > > /* > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2007-10-16 08:52:58.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2007-10-26 10:08:57.925691105 +1000 > @@ -2343,7 +2343,7 @@ out: > spin_unlock(&mp->m_sb_lock); > } > > -int > +STATIC int > xfs_icsb_modify_counters( > xfs_mount_t *mp, > xfs_sb_field_t field, > Index: 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mru_cache.c 2007-10-02 16:01:48.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mru_cache.c 2007-10-26 10:08:57.925691105 +1000 > @@ -225,10 +225,14 @@ _xfs_mru_cache_list_insert( > * list need to be deleted. For each element this involves removing it from the > * data store, removing it from the reap list, calling the client's free > * function and deleting the element from the element zone. > + * > + * We get called holding the mru->lock, which we drop and then reacquire. > + * Sparse need special help with this to tell it we know what we are doing. > */ > STATIC void > _xfs_mru_cache_clear_reap_list( > - xfs_mru_cache_t *mru) > + xfs_mru_cache_t *mru) __releases(mru->lock) __acquires(mru->lock) > + > { > xfs_mru_cache_elem_t *elem, *next; > struct list_head tmp; > @@ -528,6 +532,10 @@ xfs_mru_cache_delete( > * > * If the element isn't found, this function returns NULL and the spinlock is > * released. xfs_mru_cache_done() should NOT be called when this occurs. > + * > + * Because sparse isn't smart enough to know about conditional lock return > + * status, we need to help it get it right by annotating the path that does > + * not release the lock. > */ > void * > xfs_mru_cache_lookup( > @@ -545,8 +553,8 @@ xfs_mru_cache_lookup( > if (elem) { > list_del(&elem->list_node); > _xfs_mru_cache_list_insert(mru, elem); > - } > - else > + __release(mru_lock); /* help sparse not be stupid */ > + } else > spin_unlock(&mru->lock); > > return elem ? elem->value : NULL; > @@ -575,6 +583,8 @@ xfs_mru_cache_peek( > elem = radix_tree_lookup(&mru->store, key); > if (!elem) > spin_unlock(&mru->lock); > + else > + __release(mru_lock); /* help sparse not be stupid */ > > return elem ? elem->value : NULL; > } > @@ -586,7 +596,7 @@ xfs_mru_cache_peek( > */ > void > xfs_mru_cache_done( > - xfs_mru_cache_t *mru) > + xfs_mru_cache_t *mru) __releases(mru->lock) > { > spin_unlock(&mru->lock); > } > Index: 2.6.x-xfs-new/fs/xfs/xfs_rename.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_rename.c 2007-09-12 15:41:22.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_rename.c 2007-10-26 10:08:57.925691105 +1000 > @@ -39,6 +39,7 @@ > #include "xfs_refcache.h" > #include "xfs_utils.h" > #include "xfs_trans_space.h" > +#include "xfs_vnodeops.h" > > > /* > Index: 2.6.x-xfs-new/fs/xfs/xfs_trans.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_trans.h 2007-10-02 16:01:23.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_trans.h 2007-10-26 10:08:57.929690591 +1000 > @@ -1001,6 +1001,8 @@ xfs_log_busy_slot_t *xfs_trans_add_busy( > xfs_agnumber_t ag, > xfs_extlen_t idx); > > +extern kmem_zone_t *xfs_trans_zone; > + > #endif /* __KERNEL__ */ > > #endif /* __XFS_TRANS_H__ */ > Index: 2.6.x-xfs-new/fs/xfs/xfs_trans_item.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_trans_item.c 2007-01-16 10:54:19.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/xfs_trans_item.c 2007-10-26 10:08:57.929690591 +1000 > @@ -21,6 +21,7 @@ > #include "xfs_log.h" > #include "xfs_inum.h" > #include "xfs_trans.h" > +#include "xfs_trans_priv.h" > > STATIC int xfs_trans_unlock_chunk(xfs_log_item_chunk_t *, > int, int, xfs_lsn_t); > Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-10-25 10:34:08.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-10-26 10:08:57.929690591 +1000 > @@ -61,11 +61,6 @@ > int > xfs_init(void) > { > - extern kmem_zone_t *xfs_bmap_free_item_zone; > - extern kmem_zone_t *xfs_btree_cur_zone; > - extern kmem_zone_t *xfs_trans_zone; > - extern kmem_zone_t *xfs_buf_item_zone; > - extern kmem_zone_t *xfs_dabuf_zone; > #ifdef XFS_DABUF_DEBUG > extern spinlock_t xfs_dabuf_global_lock; > spin_lock_init(&xfs_dabuf_global_lock); > @@ -155,15 +150,9 @@ xfs_init(void) > void > xfs_cleanup(void) > { > - extern kmem_zone_t *xfs_bmap_free_item_zone; > - extern kmem_zone_t *xfs_btree_cur_zone; > extern kmem_zone_t *xfs_inode_zone; > - extern kmem_zone_t *xfs_trans_zone; > - extern kmem_zone_t *xfs_da_state_zone; > - extern kmem_zone_t *xfs_dabuf_zone; > extern kmem_zone_t *xfs_efd_zone; > extern kmem_zone_t *xfs_efi_zone; > - extern kmem_zone_t *xfs_buf_item_zone; > extern kmem_zone_t *xfs_icluster_zone; > > xfs_cleanup_procfs(); > From owner-xfs@oss.sgi.com Tue Oct 30 04:01:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 04:01:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9UB1510018226 for ; Tue, 30 Oct 2007 04:01:10 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1ImnzF-0006CO-QO; Tue, 30 Oct 2007 10:06:17 +0000 Date: Tue, 30 Oct 2007 10:06:17 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] show all mount args in /proc/mounts Message-ID: <20071030100617.GB23489@infradead.org> References: <20071029233543.GQ995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029233543.GQ995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4629/Tue Oct 30 01:34:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13487 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 On Tue, Oct 30, 2007 at 10:35:43AM +1100, David Chinner wrote: > There are several mount options that don't show up in /proc/mounts. > Add them in and clean up the showargs code at the same time. Looks good. Care to submit a patch ontop of this to move all the mount option handling to xfs_super.c as it's entirely linux-specific in this form? From owner-xfs@oss.sgi.com Tue Oct 30 04:01:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 04:01:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9UB150x018226 for ; Tue, 30 Oct 2007 04:01:09 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Imo01-0006Cn-Ox; Tue, 30 Oct 2007 10:07:05 +0000 Date: Tue, 30 Oct 2007 10:07:05 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Clean up bitops Message-ID: <20071030100705.GC23489@infradead.org> References: <20071029233635.GR995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029233635.GR995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4629/Tue Oct 30 01:34:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13488 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 Looks good to me, and you also got rid of these horrible casts in Andi's patch which is good. From owner-xfs@oss.sgi.com Tue Oct 30 04:01:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 04:01:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9UB150w018226 for ; Tue, 30 Oct 2007 04:01:09 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Imo1y-0006DV-4y; Tue, 30 Oct 2007 10:09:06 +0000 Date: Tue, 30 Oct 2007 10:09:06 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Implement fallocate Message-ID: <20071030100906.GD23489@infradead.org> References: <20071029233841.GT995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029233841.GT995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4629/Tue Oct 30 01:34:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13486 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 On Tue, Oct 30, 2007 at 10:38:41AM +1100, David Chinner wrote: > +/* > + * generic space allocation vector. > + */ This comment is rather non-sensical. But I think you can just kill it as inode operations don't really need comments. > +STATIC long > +xfs_vn_fallocate( > + struct inode *inode, > + int mode, > + loff_t offset, > + loff_t len) > +{ > + long error; > + loff_t new_size = 0; > + xfs_flock64_t bf; > + > + /* preallocation on directories not yet supported */ > + error = -ENODEV; > + if (S_ISDIR(inode->i_mode)) > + goto out_error; > + > + bf.l_whence = 0; > + bf.l_start = offset; > + bf.l_len = len; > + > + xfs_ilock(XFS_I(inode), XFS_IOLOCK_EXCL); > + error = xfs_change_file_space(XFS_I(inode), XFS_IOC_RESVSP, &bf, > + 0, NULL, ATTR_NOLOCK); please add a struct xfs_inode *ip = XFS_I(inode); to the beginning of the function and use it subsequently. That'll make the fun ction a little more readable. Otherwise this looks fine to me. From owner-xfs@oss.sgi.com Tue Oct 30 04:01:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 04:01:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9UB150v018226 for ; Tue, 30 Oct 2007 04:01:08 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1ImnyN-0006C2-6h; Tue, 30 Oct 2007 10:05:23 +0000 Date: Tue, 30 Oct 2007 10:05:23 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Clean up sparse warnings Message-ID: <20071030100523.GA23489@infradead.org> References: <20071029233442.GP995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029233442.GP995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4629/Tue Oct 30 01:34:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13485 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 On Tue, Oct 30, 2007 at 10:34:42AM +1100, David Chinner wrote: > > Clean up most outstanding sparse warnings. > > These are mostly locking annotations, marking things static, > casts where needed and declaring stuff in header files. Nice. Note that once we start on making things static there's also a lot of things not really used non-static but exported which we should cleanup aswell. I'll look at that when I get some time. Note that we'll also always get tons of sparse warnings for debug builds because STATIC is defined away.. > @@ -2733,21 +2733,13 @@ xlog_recover_do_efd_trans( > * AIL lock. > */ > xfs_trans_delete_ail(mp, lip); > - break; > + xfs_efi_item_free(efip); > + return; > } > } > lip = xfs_trans_next_ail(mp, lip, &gen, NULL); > } > - > - /* > - * If we found it, then free it up. If it wasn't there, it > - * must have been overwritten in the log. Oh well. > - */ > - if (lip != NULL) { > - xfs_efi_item_free(efip); > - } else { > - spin_unlock(&mp->m_ail_lock); > - } > + spin_unlock(&mp->m_ail_lock); Imho non-trivial changes like this hunk always deserve beeing a patch of it's own where they're described in details. Note that I also get warnings from the lock annotations prover in sparse about some conditional locking in xfs_mount.c. I have patches I still need to run through testing for those which clean the code up quite nicely aswell. From owner-xfs@oss.sgi.com Tue Oct 30 05:41:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 05:41:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9UCfprJ005849 for ; Tue, 30 Oct 2007 05:41:54 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1ImqPr-00088P-Ba; Tue, 30 Oct 2007 12:41:55 +0000 Date: Tue, 30 Oct 2007 12:41:55 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] fix inode allocation latency Message-ID: <20071030124155.GA31166@infradead.org> References: <20071029233742.GS995458@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071029233742.GS995458@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4629/Tue Oct 30 01:34:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13489 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 On Tue, Oct 30, 2007 at 10:37:42AM +1100, David Chinner wrote: > The log force added in xfs_iget_core() has been a performance > issue since it was introduced for tight loops that allocate > then unlink a single file. under heavy writeback, this can > introduce unnecessary latency due tothe log I/o getting > stuck behind bulk data writes. > > Fix this latency problem by avoinding the need for the log > force by moving the place we mark linux inode dirty to the > transaction commit rather than on transaction completion. > > This also closes a potential hole in the sync code where a > linux inode is not dirty betwen the time it is modified and > the time the log buffer has been written to disk. The concept sounds fine to me, and the implementation looks good aswell. > /* > + * If the linux inode exists, mark it dirty. > + * Used when commiting a dirty inode into a transaction so that > + * the inode will get written back by the linux code > + */ > +void > +xfs_mark_inode_dirty_sync( > + xfs_inode_t *ip) > +{ > + bhv_vnode_t *vp; > + > + vp = XFS_ITOV_NULL(ip); > + if (vp) > + mark_inode_dirty_sync(vn_to_inode(vp)); > +} I think this should be: void xfs_mark_inode_dirty_sync( xfs_inode_t *ip) { if (ip->i_vnode) mark_inode_dirty_sync(ip->i_vnode); } From owner-xfs@oss.sgi.com Tue Oct 30 10:28:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 10:28:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from b.mx.filmlight.ltd.uk (bongo.filmlight.ltd.uk [217.40.27.26]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9UHRvsw025200 for ; Tue, 30 Oct 2007 10:28:00 -0700 Received: (dqd 3887 invoked from network); 30 Oct 2007 17:28:01 -0000 Received: from unknown (HELO ?10.44.0.101?) (roger@10.44.0.101) by b.mx.filmlight.ltd.uk with SMTP; 30 Oct 2007 17:28:01 -0000 Message-ID: <472769A1.5090605@filmlight.ltd.uk> Date: Tue, 30 Oct 2007 17:28:01 +0000 From: Roger Willcocks User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com Subject: Re: bug: truncate to zero + setuid References: <47249E7A.7060709@filmlight.ltd.uk> <47252F62.6030503@sgi.com> <47262CD0.5010708@filmlight.ltd.uk> <4726ADAE.9070206@sgi.com> In-Reply-To: <4726ADAE.9070206@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4639/Tue Oct 30 09:08:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13490 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: roger@filmlight.ltd.uk Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Roger Willcocks wrote: >> Tim Shimmin wrote: >>> Hi Roger, >>> >>> Roger Willcocks wrote: >>>> The nfsv3 setattr call permits a simultaneous truncate + setuid/gid >>>> operation. Normally XFS handles this fine, but if the file's being >>>> truncated to zero, and the file's already empty, XFS simply ignores >>>> the setuid/gid part, returning 'success'. >>>> >>>> The error's in xfs_vnodeops.c/xfs_setattr below the comment 'Short >>>> circuit the truncate case for zero length files', which bypasses >>>> all other changes. >>>> >>>> The simplest fix is to test whether this is the only change that's >>>> happening, otherwise you get tangled in transactions. >>>> >>>> if (mask & XFS_AT_SIZE) { >>>> /* Short circuit the truncate case for zero length >>>> files */ >>>> - if ((vap->va_size == 0) && >>>> + if (((mask & ~XFS_AT_SIZE) == 0) && (vap->va_size >>>> == 0) && >>>> (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == >>>> 0)) { >>>> >>>> >>>> -- >>>> Roger >>>> >>> >>> Yeah, I see your problem. >>> It is interesting to know how much of multiple actions (different >>> bits of mask) are supported. >>> XFS_AT_UPDTIMES doesn't support anything else and will return quickly. >>> As far as code which goes via error_return, it looks like the >>> only non-error case is the short-circuit one mentioned above - >>> truncating to zero an already zeroed file. >>> >>> I see your fix will get what we want although, it will mean that we >>> will go thru the truncating path when we don't need to. >>> It would be nice if we could act like the XFS_AT_SIZE was never set >>> on the call in the case that other bits are set. >>> Though when we first test the AT_SIZE, we don't have the inode locked. >>> And I presume in that case we don't necessarily need to send a >>> DMAPI truncate event? >>> So I wonder if before the 1st AT_SIZE test that we have now, >>> in the AT_SIZE case and with other bits set, >>> we could lock the inode and test >>> for the zero truncate of zero-len file and if so then remove the >>> AT_SIZE bit >>> and then go on to the other testing as if AT_SIZE was never set. >>> Hmmm, may be that just complicates things too much. >>> >> Yes I looked at simply unsetting the XFS_AT_SIZE bit (you'd also need >> to set >> timeflags appropriately) but the problem is the bit's used to check >> when to create >> a transaction - either up front as XFS_TRANS_SETATTR_NOT_SIZE, or >> later on, after the inode's been locked and unlocked again, as >> XFS_TRANS_SETATTR_SIZE. So if you unset the bit (and there's still more >> to do) you need to build a not_size transaction, at which point you >> might as well >> rewrite the whole routine... >> >> -- >> Roger > > So this was done by Steve L. for AIM performance... > > ---------------------------- > revision 1.446 > date: 2000/06/09 02:59:45; author: lord; state: Exp; lines: +11 -0 > modid: 2.4.0-test1-xfs:slinx:55891a > Merge of 2.3.99pre2-xfs:slinx:55891a by ananth. > > Short circuit the case where we truncate a zero length > file down to zero length so that we do not do a transaction. > This close to doubles create/close AIM run performance. > ---------------------------- > > > p_rdiff -r1.445,1.446 xfs_vnodeops.c > 746a747,757 > > /* Short circuit the truncate case for zero length > files */ > > if ((vap->va_size == 0) && > > (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == > 0)) { > > xfs_iunlock(ip, XFS_ILOCK_EXCL); > > lock_flags &= ~XFS_ILOCK_EXCL; > > if (mask & AT_CTIME) > > xfs_ichgtime(ip, XFS_ICHGTIME_CHG); > > code = 0; > > goto error_return; > > } > > > > > ---------------------------- > revision 1.506 > date: 2001/06/26 22:07:29; author: lord; state: Exp; lines: +1 -1 > modid: 2.4.x-xfs:slinx:97694a > Set the mtime on a zero length file when a create is being done on > top of it. > ---------------------------- > > > p_rdiff -r1.505,1.506 xfs_vnodeops.c > 526c526 > < xfs_ichgtime(ip, XFS_ICHGTIME_CHG); > --- > > xfs_ichgtime(ip, XFS_ICHGTIME_MOD | > XFS_ICHGTIME_CHG); > > > > > I presume it was done where it was done so that the inode was locked > and we > were under the XFS_AT_SIZE predicate. > > I was just thinking of something like... > but I'm probably missing something. > > Index: 2.6.x-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- 2.6.x-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-10-12 > 16:06:15.000000000 +1000 > +++ 2.6.x-xfs/fs/xfs/xfs_vnodeops.c 2007-10-30 14:59:46.418837757 > +1100 > @@ -304,6 +304,24 @@ > } > > /* > + * Short circuit the truncate case for zero length files. > + * If more mask bits are set, then just remove the SIZE one > + * and keep going. > + */ > + if (mask & XFS_AT_SIZE) { > + xfs_ilock(ip, XFS_ILOCK_SHARED); > + if ((vap->va_size == 0) && (ip->i_size == 0) && > (ip->i_d.di_nextents == 0)) { > + if (mask & ~XFS_AT_SIZE) { > + mask &= ~XFS_AT_SIZE; > + } else { > + xfs_iunlock(ip, XFS_ILOCK_SHARED); > + return 0; > + } > + } > + xfs_iunlock(ip, XFS_ILOCK_SHARED); > + } > + > + /* > * For the other attributes, we acquire the inode lock and > * first do an error checking pass. > */ > @@ -451,17 +469,6 @@ > * Truncate file. Must have write permission and not be a > directory. > */ > if (mask & XFS_AT_SIZE) { > - /* Short circuit the truncate case for zero length > files */ > - if ((vap->va_size == 0) && > - (ip->i_size == 0) && (ip->i_d.di_nextents == 0)) { > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > - lock_flags &= ~XFS_ILOCK_EXCL; > - if (mask & XFS_AT_CTIME) > - xfs_ichgtime(ip, XFS_ICHGTIME_MOD | > XFS_ICHGTIME_CHG); > - code = 0; > - goto error_return; > - } > - > if (VN_ISDIR(vp)) { > code = XFS_ERROR(EISDIR); > goto error_return; This misses setting the access and changed times which still need to be touched even if the file's already zero bytes. How about this: (noting that open.c/do_truncate uses XFS_AT_SIZE | XFS_AT_CTIME) --- xfs_vnodeops.c 2007-09-04 15:57:40.000000000 +0100 +++ /tmp/xfs_vnodeops.c 2007-10-30 17:11:32.000000000 +0000 @@ -378,6 +378,24 @@ return (code); } + + if ((mask & XFS_AT_SIZE) && (vap->va_size == 0)) { + + /* Short circuit the truncate case for zero length files */ + + xfs_ilock(ip, XFS_ILOCK_EXCL); + if ((ip->i_d.di_size == 0) && (ip->i_d.di_nextents == 0)) { + xfs_iunlock(ip, XFS_ILOCK_EXCL); + if (mask & XFS_AT_CTIME) + xfs_ichgtime(ip, XFS_ICHGTIME_MOD|XFS_ICHGTIME_CHG); + mask &= ~(XFS_AT_SIZE|XFS_AT_CTIME); + if (mask == 0) { + code = 0; + goto error_return; + } + } + } + /* * For the other attributes, we acquire the inode lock and * first do an error checking pass. @@ -528,17 +546,6 @@ * Truncate file. Must have write permission and not be a directory. */ if (mask & XFS_AT_SIZE) { - /* Short circuit the truncate case for zero length files */ - if ((vap->va_size == 0) && - (ip->i_d.di_size == 0) && (ip->i_d.di_nextents == 0)) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - lock_flags &= ~XFS_ILOCK_EXCL; - if (mask & XFS_AT_CTIME) - xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - code = 0; - goto error_return; - } - if (vp->v_type == VDIR) { code = XFS_ERROR(EISDIR); goto error_return; From owner-xfs@oss.sgi.com Tue Oct 30 16:03:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 16:03:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9UN3Ou4032416 for ; Tue, 30 Oct 2007 16:03:25 -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 KAA22051; Wed, 31 Oct 2007 10:03:22 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9UN3LdD87605234; Wed, 31 Oct 2007 10:03:21 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9UN3KRO87746475; Wed, 31 Oct 2007 10:03:20 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 31 Oct 2007 10:03:20 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Clean up sparse warnings Message-ID: <20071030230320.GS66820511@sgi.com> References: <20071029233442.GP995458@sgi.com> <20071030100523.GA23489@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030100523.GA23489@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13491 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 On Tue, Oct 30, 2007 at 10:05:23AM +0000, Christoph Hellwig wrote: > On Tue, Oct 30, 2007 at 10:34:42AM +1100, David Chinner wrote: > > > > Clean up most outstanding sparse warnings. > > > > These are mostly locking annotations, marking things static, > > casts where needed and declaring stuff in header files. > > Nice. Note that once we start on making things static there's also a lot > of things not really used non-static but exported which we should cleanup > aswell. I'll look at that when I get some time. > > Note that we'll also always get tons of sparse warnings for debug builds > because STATIC is defined away.. Yeah, I noticed that - but given that we've done that on purpose to aid debugging, I don't think it will change ;) > > @@ -2733,21 +2733,13 @@ xlog_recover_do_efd_trans( > > * AIL lock. > > */ > > xfs_trans_delete_ail(mp, lip); > > - break; > > + xfs_efi_item_free(efip); > > + return; > > } > > } > > lip = xfs_trans_next_ail(mp, lip, &gen, NULL); > > } > > - > > - /* > > - * If we found it, then free it up. If it wasn't there, it > > - * must have been overwritten in the log. Oh well. > > - */ > > - if (lip != NULL) { > > - xfs_efi_item_free(efip); > > - } else { > > - spin_unlock(&mp->m_ail_lock); > > - } > > + spin_unlock(&mp->m_ail_lock); > > Imho non-trivial changes like this hunk always deserve beeing a patch of > it's own where they're described in details. Ok, I'll split that one out. > Note that I also get warnings from the lock annotations prover in sparse > about some conditional locking in xfs_mount.c. I have patches I still need > to run through testing for those which clean the code up quite nicely aswell. Oh, yeah, I left a couple in the icsb code alone as they'd require more than trivial annotation to fix. I just wanted to remove the majority of the noise so I could see new problems easily. Patches to fix them would be great ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Oct 30 19:35:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 19:35:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_40,SPF_HELO_PASS, WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V2ZJWF027701 for ; Tue, 30 Oct 2007 19:35:22 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1In3QR-0006xb-AJ for xfs@oss.sgi.com; Tue, 30 Oct 2007 19:35:23 -0700 Message-ID: <13501909.post@talk.nabble.com> Date: Tue, 30 Oct 2007 19:35:23 -0700 (PDT) From: "paul.lkw" To: xfs@oss.sgi.com Subject: 2.6TB Storage Size Problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: paul.lkw@mfun.org X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13492 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul.lkw@mfun.org Precedence: bulk X-list: xfs Dear all: I have a DELL server with a hardware raid controller card and 6 x 750GB Harddisk, and I configured it as a Raid-5 (5 x 750GB) and 1 of HotSpare. I partitioned 50GB of the main base CentOS system and the remain unpartitioned size should be 2.5xxxTB, but however I just have 2.0T as EXT-3 limitation (I think), How can I use the full size of this with LVM? THX for all. ^_^ -- View this message in context: http://www.nabble.com/2.6TB-Storage-Size-Problem-tf4722532.html#a13501909 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Oct 30 19:48:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 19:48:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V2mPXt029226 for ; Tue, 30 Oct 2007 19:48:26 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 28A3892C318; Wed, 31 Oct 2007 13:48:28 +1100 (EST) Subject: Re: 2.6TB Storage Size Problem From: Nathan Scott Reply-To: nscott@aconex.com To: "paul.lkw" Cc: xfs@oss.sgi.com In-Reply-To: <13501909.post@talk.nabble.com> References: <13501909.post@talk.nabble.com> Content-Type: text/plain Organization: Aconex Date: Wed, 31 Oct 2007 13:48:23 +1100 Message-Id: <1193798904.3862.106.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13493 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2007-10-30 at 19:35 -0700, paul.lkw wrote: > > size should be 2.5xxxTB, but however I just have 2.0T as EXT-3 > limitation (I DOS partition size limitation more likely - use a different partitioning scheme, or just don't partition the device. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Oct 30 20:30:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 20:30:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from hogwarts.egr.duke.edu (hogwarts.egr.duke.edu [152.3.195.84]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V3U6Z3010020 for ; Tue, 30 Oct 2007 20:30:08 -0700 Received: from hogwarts.egr.duke.edu (localhost.localdomain [127.0.0.1]) by hogwarts.egr.duke.edu (8.13.1/8.13.1) with ESMTP id l9V3U5UJ029374; Tue, 30 Oct 2007 23:30:05 -0400 Received: from localhost (jlb@localhost) by hogwarts.egr.duke.edu (8.13.1/8.13.1/Submit) with ESMTP id l9V3U46Y029349; Tue, 30 Oct 2007 23:30:05 -0400 X-Authentication-Warning: hogwarts.egr.duke.edu: jlb owned process doing -bs Date: Tue, 30 Oct 2007 23:30:04 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@hogwarts.egr.duke.edu To: "paul.lkw" cc: xfs@oss.sgi.com Subject: Re: 2.6TB Storage Size Problem In-Reply-To: <13501909.post@talk.nabble.com> Message-ID: References: <13501909.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13494 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 On Tue, 30 Oct 2007 at 7:35pm, paul.lkw wrote > I have a DELL server with a hardware raid controller card and 6 x 750GB > Harddisk, and I configured it as a Raid-5 (5 x 750GB) and 1 of HotSpare. I > partitioned 50GB of the main base CentOS system and the remain unpartitioned > size should be 2.5xxxTB, but however I just have 2.0T as EXT-3 limitation (I > think), How can I use the full size of this with LVM? This has been answered many times on the CentOS list: 1) On a device larger than 2.0TB, you must use a gpt disklabel rather than the default msdos. 2) You must use parted when partitioning such a device. 3) You can't boot from such a device (as neither grub nor lilo support gpt disklabels). -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF From owner-xfs@oss.sgi.com Tue Oct 30 21:07:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 21:08:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V47pPY014657 for ; Tue, 30 Oct 2007 21:07:54 -0700 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1In4rz-0000WK-HW for xfs@oss.sgi.com; Tue, 30 Oct 2007 21:07:55 -0700 Message-ID: <13502504.post@talk.nabble.com> Date: Tue, 30 Oct 2007 21:07:55 -0700 (PDT) From: "paul.lkw" To: xfs@oss.sgi.com Subject: Re: 2.6TB Storage Size Problem In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: paul.lkw@mfun.org References: <13501909.post@talk.nabble.com> X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13496 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul.lkw@mfun.org Precedence: bulk X-list: xfs Does it means I have to use one harddisk for just boot process ? Joshua Baker-LePain wrote: > > On Tue, 30 Oct 2007 at 7:35pm, paul.lkw wrote > >> I have a DELL server with a hardware raid controller card and 6 x 750GB >> Harddisk, and I configured it as a Raid-5 (5 x 750GB) and 1 of HotSpare. >> I >> partitioned 50GB of the main base CentOS system and the remain >> unpartitioned >> size should be 2.5xxxTB, but however I just have 2.0T as EXT-3 limitation >> (I >> think), How can I use the full size of this with LVM? > > This has been answered many times on the CentOS list: > > 1) On a device larger than 2.0TB, you must use a gpt disklabel rather than > the default msdos. > > 2) You must use parted when partitioning such a device. > > 3) You can't boot from such a device (as neither grub nor lilo support gpt > disklabels). > > -- > Joshua Baker-LePain > QB3 Shared Cluster Sysadmin > UCSF > > > > -- View this message in context: http://www.nabble.com/2.6TB-Storage-Size-Problem-tf4722532.html#a13502504 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Oct 30 21:07:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 21:07:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.0-r574664 Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V471Bc014457 for ; Tue, 30 Oct 2007 21:07:03 -0700 X-IronPort-AV: E=Sophos;i="4.21,349,1188743400"; d="asc'?scan'208";a="222552824" Received: from ppp198-168.static.internode.on.net (HELO saturn.flamingspork.com) ([59.167.198.168]) by ipmail01.adl2.internode.on.net with ESMTP; 31 Oct 2007 14:03:35 +1030 Received: from localhost.localdomain (saturn.flamingspork.com [127.0.0.1]) by saturn.flamingspork.com (Postfix) with ESMTP id 45C7FC00091; Wed, 31 Oct 2007 14:27:53 +1100 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id CD1EAA002DC; Tue, 30 Oct 2007 19:40:05 +1100 (EST) Subject: Re: Default mount options (that suck less). From: Stewart Smith To: Eric Sandeen Cc: Hannes Dorbath , Niv Sardi , xfs@oss.sgi.com In-Reply-To: <4725F732.2060509@sandeen.net> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> <4725F6C0.3020303@theendofthetunnel.de> <4725F732.2060509@sandeen.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hUGNsWMUTwMtaamSOwT8" Date: Tue, 30 Oct 2007 19:40:05 +1100 Message-Id: <1193733605.9551.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13495 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 --=-hUGNsWMUTwMtaamSOwT8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-10-29 at 10:07 -0500, Eric Sandeen wrote: > Hannes Dorbath wrote: > > On 29.10.2007 15:03, Eric Sandeen wrote: > >> Niv Sardi wrote: > >>> XFS's default mount options are in most cases sub-optimal, we should = try > >>> to have more sensible defaults, so far I'm following some quick dave-= powered > >>> recomendations: > >=20 > > Is there any reason to not set the default inode size to 512 bytes? ..a= s=20 > > suggested in: > >=20 > > http://www.suse.de/~agruen/acl/linux-acls/online/ >=20 > attr2 should help with the problem now... unless there is some common > case where attr2+256 still spills out a lot? Probably SELinux+Beagle attributes? Attribute "Beagle.Fingerprint" has a 25 byte value Attribute "Beagle.Uid" has a 22 byte value Attribute "Beagle.MTime" has a 14 byte value Attribute "Beagle.Filter" has a 36 byte value Attribute "Beagle.AttrTime" has a 14 byte value That's 111bytes just for values... --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-hUGNsWMUTwMtaamSOwT8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUARybt5b3yNwHyU3DLAQJZ3BAAlPp6ANf04XWkdSJMVk2qwPfZwnh/QawC 7RnsoRaeaOBR1mqZIlcF2f6dIuZ+G24G+mPsWhuKVCLtzhJRnjNlT7e9UpQAwpf8 4Q7miKTygp8WOKZ9iiihPe0PrkJOa+hV3qnYYDWQPn7MGWWttistUqp+qim7QKxj WdujFKl3fondKKhgsi59YNCtxOGhSPUYlQlGmrlcwEAwRyuySmDCsunQcTgHpO48 FN/0nacZkLS+sRK6ry9kV/SJGY7eIjvLqRTleT5ZAcQBBD9led1BJzns3hVF4KeL jVNOt2lruZrQrH2SiT0QRm6k9jrGKHK3sgrorf1sNWZGtjSqAuGTqxFCV++JY1zM 91J9RteswoQRO1gTax2OdZcAzGJZbg4kXassAZc5+kjQLKXRDJnbCYH5RkR+t8/p eRDR2HyA76813SGq9bh7n7eGLhYshiyqjUfqMDDpG2pDSJcyK34nlrZuop0QzRLa +MA7opymuqsESGLHvzyf8TCeKqAXKKGa1XiEtjhpz6ygc1h6DhHLxV71gaPNOBTE OcBDluUmUNZAhLB2fdalA0+r9DmhYEhMUV52xZHFqr3/p5woaut7VSeyQOkIhZyu SMoTR0JHY7Rm5XmCbdCJ+wGCHwnXgGYnchteMCaxnbwi0XKwVf33Pg3u0he42vtu bXZ/wCgfyWc= =2wFf -----END PGP SIGNATURE----- --=-hUGNsWMUTwMtaamSOwT8-- From owner-xfs@oss.sgi.com Tue Oct 30 21:11:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 21:12:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V4Bjb8015647 for ; Tue, 30 Oct 2007 21:11:48 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 8495C92C34C; Wed, 31 Oct 2007 15:11:49 +1100 (EST) Subject: Re: Default mount options (that suck less). From: Nathan Scott Reply-To: nscott@aconex.com To: Stewart Smith Cc: Eric Sandeen , Hannes Dorbath , Niv Sardi , xfs@oss.sgi.com In-Reply-To: <1193733605.9551.18.camel@localhost.localdomain> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> <4725F6C0.3020303@theendofthetunnel.de> <4725F732.2060509@sandeen.net> <1193733605.9551.18.camel@localhost.localdomain> Content-Type: text/plain Organization: Aconex Date: Wed, 31 Oct 2007 15:11:45 +1100 Message-Id: <1193803905.3862.108.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13497 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2007-10-30 at 19:40 +1100, Stewart Smith wrote: > > Probably SELinux+Beagle attributes? > > Attribute "Beagle.Fingerprint" has a 25 byte value > Attribute "Beagle.Uid" has a 22 byte value > Attribute "Beagle.MTime" has a 14 byte value > Attribute "Beagle.Filter" has a 36 byte value > Attribute "Beagle.AttrTime" has a 14 byte value > > That's 111bytes just for values... and another ~70 bytes for the names. -- Nathan From owner-xfs@oss.sgi.com Tue Oct 30 21:12:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 21:13:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from hogwarts.egr.duke.edu (hogwarts.egr.duke.edu [152.3.195.84]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V4CmSr015875 for ; Tue, 30 Oct 2007 21:12:51 -0700 Received: from hogwarts.egr.duke.edu (localhost.localdomain [127.0.0.1]) by hogwarts.egr.duke.edu (8.13.1/8.13.1) with ESMTP id l9V4Cn5i031623; Wed, 31 Oct 2007 00:12:49 -0400 Received: from localhost (jlb@localhost) by hogwarts.egr.duke.edu (8.13.1/8.13.1/Submit) with ESMTP id l9V4CnCn031620; Wed, 31 Oct 2007 00:12:49 -0400 X-Authentication-Warning: hogwarts.egr.duke.edu: jlb owned process doing -bs Date: Wed, 31 Oct 2007 00:12:49 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@hogwarts.egr.duke.edu To: "paul.lkw" cc: xfs@oss.sgi.com Subject: Re: 2.6TB Storage Size Problem In-Reply-To: <13502504.post@talk.nabble.com> Message-ID: References: <13501909.post@talk.nabble.com> <13502504.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13498 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 On Tue, 30 Oct 2007 at 9:07pm, paul.lkw wrote > Does it means I have to use one harddisk for just boot process ? Yes, or use auto-carving if your RAID adapter supports it. -- Joshua Baker-LePain QB3 Shared Cluster Sysadmin UCSF From owner-xfs@oss.sgi.com Tue Oct 30 21:13:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 30 Oct 2007 21:13:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9V4CvJK015907 for ; Tue, 30 Oct 2007 21:13:00 -0700 Received: from liberator.sandeen.net (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 A053F18004FC1; Tue, 30 Oct 2007 23:13:00 -0500 (CDT) Message-ID: <472800CC.8000904@sandeen.net> Date: Tue, 30 Oct 2007 23:13:00 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: nscott@aconex.com CC: Stewart Smith , Hannes Dorbath , Niv Sardi , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725E84D.3030609@sandeen.net> <4725F6C0.3020303@theendofthetunnel.de> <4725F732.2060509@sandeen.net> <1193733605.9551.18.camel@localhost.localdomain> <1193803905.3862.108.camel@edge.yarra.acx> In-Reply-To: <1193803905.3862.108.camel@edge.yarra.acx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4641/Tue Oct 30 12:59:09 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13499 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 Nathan Scott wrote: > On Tue, 2007-10-30 at 19:40 +1100, Stewart Smith wrote: >> Probably SELinux+Beagle attributes? >> >> Attribute "Beagle.Fingerprint" has a 25 byte value >> Attribute "Beagle.Uid" has a 22 byte value >> Attribute "Beagle.MTime" has a 14 byte value >> Attribute "Beagle.Filter" has a 36 byte value >> Attribute "Beagle.AttrTime" has a 14 byte value >> >> That's 111bytes just for values... > > and another ~70 bytes for the names. bleah! Ok, so we can have a "beagle" filesystem type in mkfs.xfs.conf ;-) -Eric From owner-xfs@oss.sgi.com Wed Oct 31 04:21:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 04:21:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from waldorf.loreland.org (uk.loreland.org [89.16.172.112]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9VBLADg030587 for ; Wed, 31 Oct 2007 04:21:15 -0700 Received: from [192.168.0.5] (5ac0ef75.bb.sky.com [90.192.239.117]) by waldorf.loreland.org (Postfix) with ESMTP id 2F5BA2011E; Wed, 31 Oct 2007 11:05:08 +0000 (GMT) In-Reply-To: <47267EC7.8000906@sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: James Braid Subject: Re: Default mount options (that suck less). Date: Wed, 31 Oct 2007 11:05:09 +0000 To: Timothy Shimmin X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4645/Wed Oct 31 00:55:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13500 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jamesb@loreland.org Precedence: bulk X-list: xfs On 30 Oct 2007, at 00:45, Timothy Shimmin wrote: > It might be interesting if people let us know what non-default > mkfs and mount options that they are using for their various > configurations/classes. > Didn't Russell C. have some survey years ago - can't remember if > that was for h/ware or what now. We have a ~100TB filesystem that was made with the default mkfs.xfs options from memory. The only mount option we use is inode64. From owner-xfs@oss.sgi.com Wed Oct 31 04:27:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 04:27:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9VBRO9A031992 for ; Wed, 31 Oct 2007 04:27:25 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D8F441C000262; Wed, 31 Oct 2007 07:27:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D497B4019581; Wed, 31 Oct 2007 07:27:27 -0400 (EDT) Date: Wed, 31 Oct 2007 07:27:27 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: James Braid cc: Timothy Shimmin , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). In-Reply-To: <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> Message-ID: References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/4645/Wed Oct 31 00:55:58 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13501 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 On Wed, 31 Oct 2007, James Braid wrote: > On 30 Oct 2007, at 00:45, Timothy Shimmin wrote: >> It might be interesting if people let us know what non-default >> mkfs and mount options that they are using for their various >> configurations/classes. >> Didn't Russell C. have some survey years ago - can't remember if >> that was for h/ware or what now. > > We have a ~100TB filesystem that was made with the default mkfs.xfs options > from memory. The only mount option we use is inode64. > Impressive, what architecture do you run? ia64 or x86_64? What performance differences did you see? Justin. From owner-xfs@oss.sgi.com Wed Oct 31 08:21:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 08:21:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, SPF_HELO_PASS autolearn=no version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9VFLMJc015247 for ; Wed, 31 Oct 2007 08:21:26 -0700 Received: from liberator.sandeen.net (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 7FD8418004FC3; Wed, 31 Oct 2007 10:21:25 -0500 (CDT) Message-ID: <47289D75.7030300@sandeen.net> Date: Wed, 31 Oct 2007 10:21:25 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: James Braid CC: Timothy Shimmin , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> In-Reply-To: <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4648/Wed Oct 31 07:11:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13502 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 James Braid wrote: > On 30 Oct 2007, at 00:45, Timothy Shimmin wrote: >> It might be interesting if people let us know what non-default >> mkfs and mount options that they are using for their various >> configurations/classes. >> Didn't Russell C. have some survey years ago - can't remember if >> that was for h/ware or what now. > > We have a ~100TB filesystem that was made with the default mkfs.xfs > options from memory. The only mount option we use is inode64. Hm, which has been another pet peeve of mine; shouldn't inode64 flag the SB when the first >32bit inode is created? It always bothered me that inode64 was a mount option which appears to be something you could turn back off, even though there may be >32bit inodes on disk already. -Eric From owner-xfs@oss.sgi.com Wed Oct 31 08:41:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 08:41:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9VFf8G0019157 for ; Wed, 31 Oct 2007 08:41:11 -0700 Received: (qmail 77206 invoked from network); 31 Oct 2007 15:41:12 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 31 Oct 2007 15:41:12 -0000 X-YMail-OSG: Ifkw50wVM1lP45P39_F2aWPICRVk_p.OnQNa_CU0NkxXQZIUPiNrMnJUxdI3Npn6vGP1KijAHQ-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 22156280813E; Wed, 31 Oct 2007 08:41:11 -0700 (PDT) Date: Wed, 31 Oct 2007 08:41:11 -0700 From: Chris Wedgwood To: James Braid Cc: Timothy Shimmin , xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071031154111.GA14956@puku.stupidest.org> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> X-Virus-Scanned: ClamAV 0.91.2/4648/Wed Oct 31 07:11:06 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13503 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 On Wed, Oct 31, 2007 at 11:05:09AM +0000, James Braid wrote: > We have a ~100TB filesystem that was made with the default mkfs.xfs > options from memory. The only mount option we use is inode64. Weta? Mostly very large files? From owner-xfs@oss.sgi.com Wed Oct 31 13:31:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 13:31:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.181]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id l9VKVmrS013165 for ; Wed, 31 Oct 2007 13:31:50 -0700 Received: by el-out-1112.google.com with SMTP id v27so79489ele for ; Wed, 31 Oct 2007 13:31:52 -0700 (PDT) Received: by 10.143.33.19 with SMTP id l19mr2097516wfj.1193844933778; Wed, 31 Oct 2007 08:35:33 -0700 (PDT) Received: by 10.142.109.1 with HTTP; Wed, 31 Oct 2007 08:35:33 -0700 (PDT) Message-ID: Date: Wed, 31 Oct 2007 21:05:33 +0530 From: "umesh deshpande" To: xfs@oss.sgi.com Subject: change in the value of XFS_TRANS_PUSH_AIL_RESTARTS Cc: kiran@scalex86.org MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.91.2/4652/Wed Oct 31 11:27:18 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 562 X-archive-position: 13504 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: followumesh@gmail.com Precedence: bulk X-list: xfs Hi, The value of XFS_TRANS_PUSH_AIL_RESTARTS was 10 in 2.6.20 but later it was changed to 1000. What was the log space issue because of which the value of this variable was changed? Because when I tried to run dbench on Raid0 partition which was formatted with xfs and I got few softlockups in function xfs_trans_push_ail. But I didn't get these softlockups when I reverted back the value of XFS_TRANS_PUSH_AIL_RESTARTS to 10. Regards Umesh Note: I am not a member of this list yet so please cc to my personal id, Thanks [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Oct 31 16:35:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 16:35:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_43,J_CHICKENPOX_46,J_CHICKENPOX_47,J_CHICKENPOX_51, J_CHICKENPOX_71,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9VNZEt3018981 for ; Wed, 31 Oct 2007 16:35:18 -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 KAA28388 for ; Thu, 1 Nov 2007 10:35:18 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9VNZHdD83765271 for ; Thu, 1 Nov 2007 10:35:17 +1100 (AEDT) Received: (from xaiki@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9VNZGq989111981 for xfs@oss.sgi.com; Thu, 1 Nov 2007 10:35:16 +1100 (AEDT) Date: Thu, 1 Nov 2007 10:35:16 +1100 From: Niv Sardi To: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071031233516.GB88034736@melbourne.sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20071029075657.GA84369978@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13505 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks for all your insightfull replys Here's the state of my xfsprogs/TODO: DONE - version 2 logs DONE - attr2 BUG - lazy superblock counters It looks like it's a fixed bug that should be commited soon: >[itchy] dmesg -c >[itchy] dd if=/dev/zero of=blah bs=1 seek=100G count=1 1+0 records in 1+0 records out 1 byte (1 B) copied, 0.00151443 s, 0.7 kB/s # this is my patched mkfs >[itchy] mkfs.xfs -f -l lazy-count=1 blah meta-data=/home/xaiki/blah isize=256 agcount=8, agsize=3276800 blks = sectsz=512 attr=2 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 >[itchy] mount -o loop blah /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so >[itchy] dmesg -c XFS: bad version XFS: SB validate failed DONE - version 2 inodes DONE - dropping the ability to turn unwritten extents off completely DONE/ASK - imaxpct default can be reduced > Given that 25% on a 4GB filesystem will allow about 5million inodes, > I think it's probably reasonable to bring it down to 5% by the time we > pass 1TB and 1% by 50TB..... I implemented this as a simple step function, do we need something smarter ? ASK - larger log > Another one for you - make the log larger. The kernel code supports > a log of up to 2GB, so mkfs could making a larger log without > requiring changes elsewhere. dchiner told me that we have issues with big logs, anyway, how much shall I increase the default ? ASK - less allocation groups for single disk configs Again, being quite new, I'd need magnitude orders of what's reasonable, I now multiply by 2 the AG size, witch gives me 2x less AGs. Eric: mkfs.conf sounds like a great idea to me, but i don't think it should be exclusive to XFS. Please find attached the early patches, comments are welcome. Cheers, -- Niv --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Default-to-log-version-2.patch" From af7d810cc78c541e91b712cebbfc6a0f342ac38f Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Mon, 29 Oct 2007 14:56:45 +1100 Subject: [PATCH] Default to log version 2 --- xfsprogs/mkfs/xfs_mkfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 6e84a4e..5f3299d 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -686,7 +686,7 @@ main( ilflag = imflag = ipflag = isflag = 0; liflag = laflag = lsflag = ldflag = lvflag = 0; loginternal = 1; - logversion = 1; + logversion = 2; logagno = logblocks = rtblocks = rtextblocks = 0; Nflag = nlflag = nsflag = nvflag = 0; dirblocklog = dirblocksize = dirversion = 0; -- 1.5.3.4 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0002-Default-to-version-2-attributes.patch" From 92b5a69925f10b42daadad29d2269b71d4f0f23d Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Mon, 29 Oct 2007 14:57:21 +1100 Subject: [PATCH] Default to version 2 attributes. --- xfsprogs/mkfs/xfs_mkfs.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 5f3299d..b378800 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -677,7 +677,7 @@ main( bindtextdomain(PACKAGE, LOCALEDIR); textdomain(PACKAGE); - attrversion = 0; + attrversion = 2; blflag = bsflag = slflag = ssflag = lslflag = lssflag = 0; blocklog = blocksize = 0; sectorlog = lsectorlog = XFS_MIN_SECTORSIZE_LOG; -- 1.5.3.4 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0003-Drop-the-ability-to-turn-unwritten-extents-off-compl.patch" From 42508704dfd2674847347c3266aebff20fae77ba Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Mon, 29 Oct 2007 15:23:22 +1100 Subject: [PATCH] Drop the ability to turn unwritten extents off completly --- xfsprogs/mkfs/xfs_mkfs.c | 38 +++++++++++++------------------------- xfsprogs/mkfs/xfs_mkfs.h | 6 +++--- 2 files changed, 16 insertions(+), 28 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index b378800..3689eb7 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -56,25 +56,23 @@ char *dopts[] = { "sunit", #define D_SWIDTH 5 "swidth", -#define D_UNWRITTEN 6 - "unwritten", -#define D_AGSIZE 7 +#define D_AGSIZE 6 "agsize", -#define D_SU 8 +#define D_SU 7 "su", -#define D_SW 9 +#define D_SW 8 "sw", -#define D_SECTLOG 10 +#define D_SECTLOG 9 "sectlog", -#define D_SECTSIZE 11 +#define D_SECTSIZE 10 "sectsize", -#define D_NOALIGN 12 +#define D_NOALIGN 11 "noalign", -#define D_RTINHERIT 13 +#define D_RTINHERIT 12 "rtinherit", -#define D_PROJINHERIT 14 +#define D_PROJINHERIT 13 "projinherit", -#define D_EXTSZINHERIT 15 +#define D_EXTSZINHERIT 14 "extszinherit", NULL }; @@ -604,7 +602,6 @@ main( int dsw; int dsunit; int dswidth; - int extent_flagging; int force_overwrite; struct fsxattr fsx; int iaflag; @@ -697,7 +694,6 @@ main( dsize = logsize = rtsize = rtextsize = protofile = NULL; dsu = dsw = dsunit = dswidth = lalign = lsu = lsunit = 0; nodsflag = norsflag = 0; - extent_flagging = 1; force_overwrite = 0; worst_freelist = 0; lazy_sb_counters = 0; @@ -877,14 +873,6 @@ main( D_NOALIGN); nodsflag = 1; break; - case D_UNWRITTEN: - if (!value) - reqval('d', dopts, D_UNWRITTEN); - c = atoi(value); - if (c < 0 || c > 1) - illegal(value, "d unwritten"); - extent_flagging = c; - break; case D_SECTLOG: if (!value) reqval('d', dopts, D_SECTLOG); @@ -1990,7 +1978,7 @@ an AG size that is one stripe unit smaller, for example %llu.\n"), "meta-data=%-22s isize=%-6d agcount=%lld, agsize=%lld blks\n" " =%-22s sectsz=%-5u attr=%u\n" "data =%-22s bsize=%-6u blocks=%llu, imaxpct=%u\n" - " =%-22s sunit=%-6u swidth=%u blks, unwritten=%u\n" + " =%-22s sunit=%-6u swidth=%u blks\n" "naming =version %-14u bsize=%-6u\n" "log =%-22s bsize=%-6d blocks=%lld, version=%d\n" " =%-22s sectsz=%-5u sunit=%d blks, lazy-count=%d\n" @@ -1999,7 +1987,7 @@ an AG size that is one stripe unit smaller, for example %llu.\n"), "", sectorsize, attrversion, "", blocksize, (long long)dblocks, imflag ? imaxpct : XFS_DFL_IMAXIMUM_PCT, - "", dsunit, dswidth, extent_flagging, + "", dsunit, dswidth, dirversion, dirversion == 1 ? blocksize : dirblocksize, logfile, 1 << blocklog, (long long)logblocks, logversion, "", lsectorsize, lsunit, lazy_sb_counters, @@ -2066,7 +2054,7 @@ an AG size that is one stripe unit smaller, for example %llu.\n"), } sbp->sb_features2 = XFS_SB_VERSION2_MKFS(lazy_sb_counters, attrversion == 2, 0); sbp->sb_versionnum = XFS_SB_VERSION_MKFS( - iaflag, dsunit != 0, extent_flagging, + iaflag, dsunit != 0, dirversion == 2, logversion == 2, attrversion == 1, (sectorsize != BBSIZE || lsectorsize != BBSIZE), sbp->sb_features2 != 0); @@ -2537,7 +2525,7 @@ usage( void ) /* blocksize */ [-b log=n|size=num]\n\ /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,\n\ (sunit=value,swidth=value|su=num,sw=num),\n\ - sectlog=n|sectsize=num,unwritten=0|1]\n\ + sectlog=n|sectsize=num\n\ /* inode size */ [-i log=n|perblock=n|size=num,maxpct=n,attr=0|1|2]\n\ /* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx,version=n\n\ sunit=value|su=num,sectlog=n|sectsize=num,\n\ diff --git a/xfsprogs/mkfs/xfs_mkfs.h b/xfsprogs/mkfs/xfs_mkfs.h index 1ab85fd..f19f917 100644 --- a/xfsprogs/mkfs/xfs_mkfs.h +++ b/xfsprogs/mkfs/xfs_mkfs.h @@ -18,12 +18,12 @@ #ifndef __XFS_MKFS_H__ #define __XFS_MKFS_H__ -#define XFS_SB_VERSION_MKFS(ia,dia,extflag,dir2,log2,attr1,sflag,more) (\ - ((ia)||(dia)||(extflag)||(dir2)||(log2)||(attr1)||(sflag)||(more)) ? \ +#define XFS_SB_VERSION_MKFS(ia,dia,dir2,log2,attr1,sflag,more) (\ + ((ia)||(dia)||(dir2)||(log2)||(attr1)||(sflag)||(more)) ? \ ( XFS_SB_VERSION_4 | \ ((ia) ? XFS_SB_VERSION_ALIGNBIT : 0) | \ ((dia) ? XFS_SB_VERSION_DALIGNBIT : 0) | \ - ((extflag) ? XFS_SB_VERSION_EXTFLGBIT : 0) | \ + (XFS_SB_VERSION_EXTFLGBIT) | \ ((dir2) ? XFS_SB_VERSION_DIRV2BIT : 0) | \ ((log2) ? XFS_SB_VERSION_LOGV2BIT : 0) | \ ((attr1) ? XFS_SB_VERSION_ATTRBIT : 0) | \ -- 1.5.3.4 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0004-V2-inodes-per-default-and-move-DFL-bits-to-XFS_DFL_.patch" From a9b95cc4636501870155479787ec32b325afa512 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Tue, 30 Oct 2007 11:15:33 +1100 Subject: [PATCH] V2 inodes per default, and move DFL bits to XFS_DFL_SB_VERSION_BITS, Activate XFS_SB_VERSION_NLINKBIT per default, witch will enable V2 INODES. refactor bits that we want everytime in XFS_DFL_SB_VERSION_BITS. --- xfsprogs/mkfs/xfs_mkfs.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.h b/xfsprogs/mkfs/xfs_mkfs.h index f19f917..9291e33 100644 --- a/xfsprogs/mkfs/xfs_mkfs.h +++ b/xfsprogs/mkfs/xfs_mkfs.h @@ -18,17 +18,19 @@ #ifndef __XFS_MKFS_H__ #define __XFS_MKFS_H__ +#define XFS_DFL_SB_VERSION_BITS XFS_SB_VERSION_NLINKBIT|XFS_SB_VERSION_EXTFLGBIT + #define XFS_SB_VERSION_MKFS(ia,dia,dir2,log2,attr1,sflag,more) (\ ((ia)||(dia)||(dir2)||(log2)||(attr1)||(sflag)||(more)) ? \ ( XFS_SB_VERSION_4 | \ ((ia) ? XFS_SB_VERSION_ALIGNBIT : 0) | \ ((dia) ? XFS_SB_VERSION_DALIGNBIT : 0) | \ - (XFS_SB_VERSION_EXTFLGBIT) | \ ((dir2) ? XFS_SB_VERSION_DIRV2BIT : 0) | \ ((log2) ? XFS_SB_VERSION_LOGV2BIT : 0) | \ ((attr1) ? XFS_SB_VERSION_ATTRBIT : 0) | \ ((sflag) ? XFS_SB_VERSION_SECTORBIT : 0) | \ ((more) ? XFS_SB_VERSION_MOREBITSBIT : 0) | \ + XFS_DFL_SB_VERSION_BITS | \ 0 ) : XFS_SB_VERSION_1 ) #define XFS_SB_VERSION2_MKFS(lazycount, attr2, parent) (\ -- 1.5.3.4 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0005-reduce-imaxpct-for-big-filesystems.patch" From c8e590185adb8b48e6765b9de7fe7afa19c6ea20 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Tue, 30 Oct 2007 12:26:35 +1100 Subject: [PATCH] reduce imaxpct for big filesystems, imaxpct is set to 25% for FS < 1 TB, then 5% for FS < 50 TB, and then 1%. It is implemented as a step function in calc_default_imaxpct() --- xfsprogs/mkfs/xfs_mkfs.c | 19 +++++++++++++++++-- 1 files changed, 17 insertions(+), 2 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 3689eb7..78c2c77 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -374,6 +374,21 @@ validate_log_size(__uint64_t logblocks, int blocklog, int min_logblocks) } } +int +calc_default_imaxpct( + int blocklog, + __uint64_t dblocks) +{ + if (dblocks < TERABYTES(1, blocklog)) { + return XFS_DFL_IMAXIMUM_PCT; + } else if (dblocks < TERABYTES(50, blocklog)) { + return 5; + } + + return 1; +} + + void calc_default_ag_geometry( int blocklog, @@ -1986,7 +2001,7 @@ an AG size that is one stripe unit smaller, for example %llu.\n"), dfile, isize, (long long)agcount, (long long)agsize, "", sectorsize, attrversion, "", blocksize, (long long)dblocks, - imflag ? imaxpct : XFS_DFL_IMAXIMUM_PCT, + calc_default_imaxpct(blocklog, dblocks), "", dsunit, dswidth, dirversion, dirversion == 1 ? blocksize : dirblocksize, logfile, 1 << blocklog, (long long)logblocks, @@ -2023,7 +2038,7 @@ an AG size that is one stripe unit smaller, for example %llu.\n"), (__uint8_t)(rtextents ? libxfs_highbit32((unsigned int)rtextents) : 0); sbp->sb_inprogress = 1; /* mkfs is in progress */ - sbp->sb_imax_pct = imflag ? imaxpct : XFS_DFL_IMAXIMUM_PCT; + sbp->sb_imax_pct = calc_default_imaxpct(blocklog, dblocks); sbp->sb_icount = 0; sbp->sb_ifree = 0; sbp->sb_fdblocks = dblocks - agcount * XFS_PREALLOC_BLOCKS(mp) - -- 1.5.3.4 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0006-less-AGs-for-single-disks-configs.patch" From bab3fed25bc5f44aef5b02af88a8ef968d08ddcb Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Tue, 30 Oct 2007 12:26:35 +1100 Subject: [PATCH] less AGs for single disks configs. This patch modifies get_subvol_stripe_wrapper() to return 0 on multi disk configs, <0 on error, and >0 on single disk configs (Ideally I'd like it to be able to return the count of disks or something more usefull). it then uses the output of the new get_subvol_stripe_wrapper() in calc_default_ag_geometry() to get bigger AGs when in single disk configs (currently only x2 bigger). --- xfsprogs/include/volume.h | 2 +- xfsprogs/libdisk/drivers.c | 15 ++++++++------- xfsprogs/mkfs/xfs_mkfs.c | 18 ++++++++++++------ 3 files changed, 21 insertions(+), 14 deletions(-) diff --git a/xfsprogs/include/volume.h b/xfsprogs/include/volume.h index 0cc931d..e4cd26c 100644 --- a/xfsprogs/include/volume.h +++ b/xfsprogs/include/volume.h @@ -46,7 +46,7 @@ typedef enum sv_type_e { SVTYPE_LAST =255 } sv_type_t; -extern void get_subvol_stripe_wrapper (char *, sv_type_t, int *, int *, int *); +extern int get_subvol_stripe_wrapper (char *, sv_type_t, int *, int *, int *); extern int get_driver_block_major (const char *, int); #endif /* __VOLUME_H__ */ diff --git a/xfsprogs/libdisk/drivers.c b/xfsprogs/libdisk/drivers.c index 26c6ec1..9bdc270 100644 --- a/xfsprogs/libdisk/drivers.c +++ b/xfsprogs/libdisk/drivers.c @@ -18,7 +18,7 @@ #include "drivers.h" -void +int get_subvol_stripe_wrapper( char *dev, sv_type_t type, @@ -29,7 +29,7 @@ get_subvol_stripe_wrapper( struct stat64 sb; if (dev == NULL) - return; + return -ENODEV; if (stat64(dev, &sb)) { fprintf(stderr, _("Cannot stat %s: %s\n"), @@ -38,16 +38,17 @@ get_subvol_stripe_wrapper( } if ( dm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( md_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( lvm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( xvm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if (evms_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; + return 1; /* ... add new device drivers here */ } diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 78c2c77..1eb8cf9 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -393,6 +393,7 @@ void calc_default_ag_geometry( int blocklog, __uint64_t dblocks, + int dswidth, __uint64_t *agsize, __uint64_t *agcount) { @@ -428,12 +429,13 @@ calc_default_ag_geometry( * * This scales us up smoothly between min/max AG sizes. */ + if (dblocks > GIGABYTES(512, blocklog)) - shift = 5; + shift = 5 - (dswidth == 0); else if (dblocks > GIGABYTES(8, blocklog)) - shift = 4; + shift = 4 - (dswidth == 0); else if (dblocks >= MEGABYTES(128, blocklog)) - shift = 3; + shift = 3 - (dswidth == 0); else ASSERT(0); blocks = dblocks >> shift; @@ -1771,10 +1773,14 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), agsize /= blocksize; agcount = dblocks / agsize + (dblocks % agsize != 0); - } else if (daflag) /* User-specified AG size */ + } else if (daflag) /* User-specified AG count */ agsize = dblocks / agcount + (dblocks % agcount != 0); - else - calc_default_ag_geometry(blocklog, dblocks, &agsize, &agcount); + else { + get_subvol_stripe_wrapper(dfile, SVTYPE_DATA, + &xlv_dsunit, &xlv_dswidth, §oralign); + + calc_default_ag_geometry(blocklog, dblocks, xlv_dswidth, &agsize, &agcount); + } /* * If the last AG is too small, reduce the filesystem size -- 1.5.3.4 --azLHFNyN32YCQGCU-- From owner-xfs@oss.sgi.com Wed Oct 31 16:40:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 16:40:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id l9VNeQvh020115 for ; Wed, 31 Oct 2007 16:40:30 -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 KAA28452 for ; Thu, 1 Nov 2007 10:40:29 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l9VNeSdD88785647 for ; Thu, 1 Nov 2007 10:40:28 +1100 (AEDT) Received: (from xaiki@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l9VNeS4788897341 for xfs@oss.sgi.com; Thu, 1 Nov 2007 10:40:28 +1100 (AEDT) Date: Thu, 1 Nov 2007 10:40:28 +1100 From: Niv Sardi To: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071031234027.GC88034736@melbourne.sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <20071031233516.GB88034736@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <20071031233516.GB88034736@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13506 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Oops, the last patch should have been this one, sorry for the noise. -- Niv --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0006-less-AGs-for-single-disks-configs.patch" From 1defd8358a7ee693176875ebc3a670a347c87d11 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Tue, 30 Oct 2007 12:26:35 +1100 Subject: [PATCH] less AGs for single disks configs. This patch modifies get_subvol_stripe_wrapper() to return 0 on multi disk configs, <0 on error, and >0 on single disk configs (Ideally I'd like it to be able to return the count of disks or something more usefull). it then uses the output of the new get_subvol_stripe_wrapper() in calc_default_ag_geometry() to get bigger AGs when in single disk configs (currently only x2 bigger). --- xfsprogs/include/volume.h | 2 +- xfsprogs/libdisk/drivers.c | 15 ++++++++------- xfsprogs/mkfs/xfs_mkfs.c | 18 ++++++++++++------ 3 files changed, 21 insertions(+), 14 deletions(-) diff --git a/xfsprogs/include/volume.h b/xfsprogs/include/volume.h index 0cc931d..e4cd26c 100644 --- a/xfsprogs/include/volume.h +++ b/xfsprogs/include/volume.h @@ -46,7 +46,7 @@ typedef enum sv_type_e { SVTYPE_LAST =255 } sv_type_t; -extern void get_subvol_stripe_wrapper (char *, sv_type_t, int *, int *, int *); +extern int get_subvol_stripe_wrapper (char *, sv_type_t, int *, int *, int *); extern int get_driver_block_major (const char *, int); #endif /* __VOLUME_H__ */ diff --git a/xfsprogs/libdisk/drivers.c b/xfsprogs/libdisk/drivers.c index 26c6ec1..9bdc270 100644 --- a/xfsprogs/libdisk/drivers.c +++ b/xfsprogs/libdisk/drivers.c @@ -18,7 +18,7 @@ #include "drivers.h" -void +int get_subvol_stripe_wrapper( char *dev, sv_type_t type, @@ -29,7 +29,7 @@ get_subvol_stripe_wrapper( struct stat64 sb; if (dev == NULL) - return; + return -ENODEV; if (stat64(dev, &sb)) { fprintf(stderr, _("Cannot stat %s: %s\n"), @@ -38,16 +38,17 @@ get_subvol_stripe_wrapper( } if ( dm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( md_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( lvm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if ( xvm_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; if (evms_get_subvol_stripe(dev, type, sunit, swidth, sectalign, &sb)) - return; + return 0; + return 1; /* ... add new device drivers here */ } diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 78c2c77..ea5cd86 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -393,6 +393,7 @@ void calc_default_ag_geometry( int blocklog, __uint64_t dblocks, + int singled, __uint64_t *agsize, __uint64_t *agcount) { @@ -428,12 +429,13 @@ calc_default_ag_geometry( * * This scales us up smoothly between min/max AG sizes. */ + if (dblocks > GIGABYTES(512, blocklog)) - shift = 5; + shift = 5 - (singled > 0); else if (dblocks > GIGABYTES(8, blocklog)) - shift = 4; + shift = 4 - (singled > 0); else if (dblocks >= MEGABYTES(128, blocklog)) - shift = 3; + shift = 3 - (singled > 0); else ASSERT(0); blocks = dblocks >> shift; @@ -1771,10 +1773,14 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), agsize /= blocksize; agcount = dblocks / agsize + (dblocks % agsize != 0); - } else if (daflag) /* User-specified AG size */ + } else if (daflag) /* User-specified AG count */ agsize = dblocks / agcount + (dblocks % agcount != 0); - else - calc_default_ag_geometry(blocklog, dblocks, &agsize, &agcount); + else { + calc_default_ag_geometry(blocklog, dblocks, + get_subvol_stripe_wrapper(dfile, SVTYPE_DATA, + &xlv_dsunit, &xlv_dswidth, §oralign), + &agsize, &agcount); + } /* * If the last AG is too small, reduce the filesystem size -- 1.5.3.4 --QTprm0S8XgL7H0Dt-- From owner-xfs@oss.sgi.com Wed Oct 31 17:32:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 17:32:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from waldorf.loreland.org (uk.loreland.org [89.16.172.112]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lA10WABo025573 for ; Wed, 31 Oct 2007 17:32:14 -0700 Received: from [192.168.0.5] (5ac0ef75.bb.sky.com [90.192.239.117]) by waldorf.loreland.org (Postfix) with ESMTP id 0A1382011E; Thu, 1 Nov 2007 00:32:13 +0000 (GMT) In-Reply-To: <20071031154111.GA14956@puku.stupidest.org> References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> <20071031154111.GA14956@puku.stupidest.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A42DE01-1E92-4BE2-A1D9-BD91D8A7F732@loreland.org> Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: James Braid Subject: Re: Default mount options (that suck less). Date: Thu, 1 Nov 2007 00:32:20 +0000 To: Chris Wedgwood X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13507 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jamesb@loreland.org Precedence: bulk X-list: xfs On 31 Oct 2007, at 15:41, Chris Wedgwood wrote: > On Wed, Oct 31, 2007 at 11:05:09AM +0000, James Braid wrote: > >> We have a ~100TB filesystem that was made with the default mkfs.xfs >> options from memory. The only mount option we use is inode64. > > Weta? Mostly very large files? Not weta, but another big vfx company This particular filesystem is used for nearline backups from a bunch of NFS servers (which run XFS as well - we love XFS). The average file size is only about a megabyte. From owner-xfs@oss.sgi.com Wed Oct 31 17:47:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 17:47:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from waldorf.loreland.org (uk.loreland.org [89.16.172.112]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lA10lKhO027175 for ; Wed, 31 Oct 2007 17:47:23 -0700 Received: from [192.168.0.5] (5ac0ef75.bb.sky.com [90.192.239.117]) by waldorf.loreland.org (Postfix) with ESMTP id 8A49A202AA; Thu, 1 Nov 2007 00:47:24 +0000 (GMT) In-Reply-To: References: <20071029075657.GA84369978@melbourne.sgi.com> <4725FBB4.1010400@sandeen.net> <47267EC7.8000906@sgi.com> <177CA06B-41D3-4E4A-9EA6-5688C952CD63@loreland.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B48CB6B-59DE-4CBE-AEE9-3863C5D784D3@loreland.org> Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: James Braid Subject: Re: Default mount options (that suck less). Date: Thu, 1 Nov 2007 00:47:31 +0000 To: Justin Piszcz X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13508 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jamesb@loreland.org Precedence: bulk X-list: xfs On 31 Oct 2007, at 11:27, Justin Piszcz wrote: > Impressive, what architecture do you run? ia64 or x86_64? What > performance differences did you see? It's all just commodity hardware - HP DL385 x86_64 server with a pile of cheap Infortrend RAID arrays. Performance wise we're limited by a single HBA to the disks, which is fine for this particular application because we saturate the network first. xfs_repair takes a good 36 hours or so and 16-ish GB of memory to run. (we had to run it recently, thanks to a flakey RAID) From owner-xfs@oss.sgi.com Wed Oct 31 18:15:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 18:15:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lA11FMRE029739 for ; Wed, 31 Oct 2007 18:15:24 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01010; Thu, 1 Nov 2007 12:15:23 +1100 Message-ID: <472928C1.5080707@sgi.com> Date: Thu, 01 Nov 2007 12:15:45 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] Implement fallocate References: <20071029233841.GT995458@sgi.com> In-Reply-To: <20071029233841.GT995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13509 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > XFS fallocate() callout. > > Allocate the range requested as unwritten extents. Atomically > change the file size if requested. > > Signed-off-by: Dave Chinner > --- > fs/xfs/linux-2.6/xfs_iops.c | 45 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-10-30 10:18:59.061735503 +1100 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-10-30 10:19:26.498185998 +1100 > @@ -52,6 +52,7 @@ > #include > #include > #include > +#include > > /* > * Bring the atime in the XFS inode uptodate. > @@ -796,6 +797,49 @@ xfs_vn_removexattr( > return namesp->attr_remove(vp, attr, xflags); > } > > +/* > + * generic space allocation vector. > + */ > +STATIC long > +xfs_vn_fallocate( > + struct inode *inode, > + int mode, > + loff_t offset, > + loff_t len) > +{ > + long error; > + loff_t new_size = 0; > + xfs_flock64_t bf; > + > + /* preallocation on directories not yet supported */ > + error = -ENODEV; > + if (S_ISDIR(inode->i_mode)) > + goto out_error; > + > + bf.l_whence = 0; > + bf.l_start = offset; > + bf.l_len = len; > + > + xfs_ilock(XFS_I(inode), XFS_IOLOCK_EXCL); > + error = xfs_change_file_space(XFS_I(inode), XFS_IOC_RESVSP, &bf, > + 0, NULL, ATTR_NOLOCK); > + if (!error && !(mode & FALLOC_FL_KEEP_SIZE) && > + offset + len > i_size_read(inode)) > + new_size = offset + len; > + > + /* Change file size if needed */ > + if (new_size) { > + bhv_vattr_t va; > + > + va.va_mask = XFS_AT_SIZE; > + va.va_size = new_size; > + error = xfs_setattr(XFS_I(inode), &va, ATTR_NOLOCK, NULL); > + } Is it necessary to call xfs_setattr() here? Could we just do an explicit call to xfs_zero_eof(), set the new size, set i_update_core/size and mark the inode dirty? Hmmm, then again, that approach wouldn't be as clean as above. > + > + xfs_iunlock(XFS_I(inode), XFS_IOLOCK_EXCL); > +out_error: > + return error; > +} > > const struct inode_operations xfs_inode_operations = { > .permission = xfs_vn_permission, > @@ -806,6 +850,7 @@ const struct inode_operations xfs_inode_ > .getxattr = xfs_vn_getxattr, > .listxattr = xfs_vn_listxattr, > .removexattr = xfs_vn_removexattr, > + .fallocate = xfs_vn_fallocate, > }; > > const struct inode_operations xfs_dir_inode_operations = { > From owner-xfs@oss.sgi.com Wed Oct 31 18:17:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 18:17:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lA11HDCk030090 for ; Wed, 31 Oct 2007 18:17:17 -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 MAA01159 for ; Thu, 1 Nov 2007 12:17:16 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id lA11HFdD88962245 for ; Thu, 1 Nov 2007 12:17:16 +1100 (AEDT) Received: (from xaiki@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lA11HFpJ88935053 for xfs@oss.sgi.com; Thu, 1 Nov 2007 12:17:15 +1100 (AEDT) Date: Thu, 1 Nov 2007 12:17:15 +1100 From: Niv Sardi To: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). Message-ID: <20071101011715.GD88034736@melbourne.sgi.com> References: <20071029075657.GA84369978@melbourne.sgi.com> <20071031233516.GB88034736@melbourne.sgi.com> <20071031234027.GC88034736@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline In-Reply-To: <20071031234027.GC88034736@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13510 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline After discussing with dave, I changed my mind about the last patch, here's the updated version: Cheers, -- Niv --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0006-less-AGs-for-single-disks-configs.patch" From ce672e92543fa99199ed23fa934dedf8d678924e Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Tue, 30 Oct 2007 12:26:35 +1100 Subject: [PATCH] less AGs for single disks configs. get the underlying structure with get_subvol_stripe_wrapper(), and pass sunit | swidth as an argument to calc_default_ag_geometry(). if it is set, get the AG sizes bigger. this also cleans up a typo: - } else if (daflag) /* User-specified AG size */ + } else if (daflag) /* User-specified AG count */ --- xfsprogs/mkfs/xfs_mkfs.c | 18 ++++++++++++------ 1 files changed, 12 insertions(+), 6 deletions(-) diff --git a/xfsprogs/mkfs/xfs_mkfs.c b/xfsprogs/mkfs/xfs_mkfs.c index 78c2c77..4cf9975 100644 --- a/xfsprogs/mkfs/xfs_mkfs.c +++ b/xfsprogs/mkfs/xfs_mkfs.c @@ -393,6 +393,7 @@ void calc_default_ag_geometry( int blocklog, __uint64_t dblocks, + int multidisk, __uint64_t *agsize, __uint64_t *agcount) { @@ -428,12 +429,13 @@ calc_default_ag_geometry( * * This scales us up smoothly between min/max AG sizes. */ + if (dblocks > GIGABYTES(512, blocklog)) - shift = 5; + shift = 5 - (multidisk == 0); else if (dblocks > GIGABYTES(8, blocklog)) - shift = 4; + shift = 4 - (multidisk == 0); else if (dblocks >= MEGABYTES(128, blocklog)) - shift = 3; + shift = 3 - (multidisk == 0); else ASSERT(0); blocks = dblocks >> shift; @@ -1771,10 +1773,14 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), agsize /= blocksize; agcount = dblocks / agsize + (dblocks % agsize != 0); - } else if (daflag) /* User-specified AG size */ + } else if (daflag) /* User-specified AG count */ agsize = dblocks / agcount + (dblocks % agcount != 0); - else - calc_default_ag_geometry(blocklog, dblocks, &agsize, &agcount); + else { + get_subvol_stripe_wrapper(dfile, SVTYPE_DATA, + &xlv_dsunit, &xlv_dswidth, §oralign), + calc_default_ag_geometry(blocklog, dblocks, xlv_dsunit | xlv_dswidth, + &agsize, &agcount); + } /* * If the last AG is too small, reduce the filesystem size -- 1.5.3.4 --oTHb8nViIGeoXxdp-- From owner-xfs@oss.sgi.com Wed Oct 31 18:47:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 18:47:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lA11lVP1001312 for ; Wed, 31 Oct 2007 18:47:34 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01778; Thu, 1 Nov 2007 12:47:31 +1100 Message-ID: <4729304A.2010202@sgi.com> Date: Thu, 01 Nov 2007 12:47:54 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [PATCH] fix transaction overrun during writeback References: <20071029234010.GU995458@sgi.com> In-Reply-To: <20071029234010.GU995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13511 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Looks good Dave. Since this is a writeback path is there some way we can tell xfs_bmapi() that it should not convert anything but delayed allocs and have it assert/error out if it tries to - not that it will now with this change but just as defensive measure? David Chinner wrote: > Prevent transaction overrun in xfs_iomap_write_allocate() if we > rce with a truncate that overlaps the delalloc range we were > planning to allocate. > > If we race, we may allocate into a hole and that requires block > allocation. At this point in time we don't have a reservation for > block allocation (apart from metadata blocks) and so allocating > into a hole rather than a delalloc region results in overflowing > the transaction block reservation. > > Fix it by only allowing a single extent to be allocated at a > time. > > Signed-Off-By: Dave Chinner > --- > fs/xfs/xfs_iomap.c | 75 +++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 50 insertions(+), 25 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_iomap.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_iomap.c 2007-10-30 10:18:58.777772241 +1100 > +++ 2.6.x-xfs-new/fs/xfs/xfs_iomap.c 2007-10-30 10:19:30.365685668 +1100 > @@ -702,6 +702,9 @@ retry: > * the originating callers request. > * > * Called without a lock on the inode. > + * > + * We no longer bother to look at the incoming map - all we have to > + * guarantee is that whatever we allocate fills the required range. > */ > int > xfs_iomap_write_allocate( > @@ -717,9 +720,9 @@ xfs_iomap_write_allocate( > xfs_fsblock_t first_block; > xfs_bmap_free_t free_list; > xfs_filblks_t count_fsb; > - xfs_bmbt_irec_t imap[XFS_STRAT_WRITE_IMAPS]; > + xfs_bmbt_irec_t imap; > xfs_trans_t *tp; > - int i, nimaps, committed; > + int nimaps, committed; > int error = 0; > int nres; > > @@ -766,13 +769,38 @@ xfs_iomap_write_allocate( > > XFS_BMAP_INIT(&free_list, &first_block); > > - nimaps = XFS_STRAT_WRITE_IMAPS; > /* > - * Ensure we don't go beyond eof - it is possible > - * the extents changed since we did the read call, > - * we dropped the ilock in the interim. > + * it is possible that the extents have changed since > + * we did the read call as we dropped the ilock for a > + * while. We have to be careful about truncates or hole > + * punchs here - we are not allowed to allocate > + * non-delalloc blocks here. > + * > + * The only protection against truncation is the pages > + * for the range we are being asked to convert are > + * locked and hence a truncate will block on them > + * first. > + * > + * As a result, if we go beyond the range we really > + * need and hit an delalloc extent boundary followed by > + * a hole while we have excess blocks in the map, we > + * will fill the hole incorrectly and overrun the > + * transaction reservation. > + * > + * Using a single map prevents this as we are forced to > + * check each map we look for overlap with the desired > + * range and abort as soon as we find it. Also, given > + * that we only return a single map, having one beyond > + * what we can return is probably a bit silly. > + * > + * We also need to check that we don't go beyond EOF; > + * this is a truncate optimisation as a truncate sets > + * the new file size before block on the pages we > + * currently have locked under writeback. Because they > + * are about to be tossed, we don't need to write them > + * back.... > */ > - > + nimaps = 1; > end_fsb = XFS_B_TO_FSB(mp, ip->i_size); > xfs_bmap_last_offset(NULL, ip, &last_block, > XFS_DATA_FORK); > @@ -788,7 +816,7 @@ xfs_iomap_write_allocate( > /* Go get the actual blocks */ > error = xfs_bmapi(tp, ip, map_start_fsb, count_fsb, > XFS_BMAPI_WRITE, &first_block, 1, > - imap, &nimaps, &free_list, NULL); > + &imap, &nimaps, &free_list, NULL); > if (error) > goto trans_cancel; > > @@ -807,27 +835,24 @@ xfs_iomap_write_allocate( > * See if we were able to allocate an extent that > * covers at least part of the callers request > */ > - for (i = 0; i < nimaps; i++) { > - if (unlikely(!imap[i].br_startblock && > - !(ip->i_d.di_flags & XFS_DIFLAG_REALTIME))) > - return xfs_cmn_err_fsblock_zero(ip, &imap[i]); > - if ((offset_fsb >= imap[i].br_startoff) && > - (offset_fsb < (imap[i].br_startoff + > - imap[i].br_blockcount))) { > - *map = imap[i]; > - *retmap = 1; > - XFS_STATS_INC(xs_xstrat_quick); > - return 0; > - } > - count_fsb -= imap[i].br_blockcount; > + if (unlikely(!imap.br_startblock && > + XFS_IS_REALTIME_INODE(ip))) > + return xfs_cmn_err_fsblock_zero(ip, &imap); > + if ((offset_fsb >= imap.br_startoff) && > + (offset_fsb < (imap.br_startoff + > + imap.br_blockcount))) { > + *map = imap; > + *retmap = 1; > + XFS_STATS_INC(xs_xstrat_quick); > + return 0; > } > > - /* So far we have not mapped the requested part of the > + /* > + * So far we have not mapped the requested part of the > * file, just surrounding data, try again. > */ > - nimaps--; > - map_start_fsb = imap[nimaps].br_startoff + > - imap[nimaps].br_blockcount; > + count_fsb -= imap.br_blockcount; > + map_start_fsb = imap.br_startoff + imap.br_blockcount; > } > > trans_cancel: > From owner-xfs@oss.sgi.com Wed Oct 31 19:23:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 19:23:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lA12N99l005006 for ; Wed, 31 Oct 2007 19:23:10 -0700 Received: from macmini.sandeen.net (macmini.sandeen.net [10.0.0.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7412B18004FC2; Wed, 31 Oct 2007 21:23:12 -0500 (CDT) Message-ID: <472939AD.9080708@sandeen.net> Date: Wed, 31 Oct 2007 21:27:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com Subject: Re: Default mount options (that suck less). References: <20071029075657.GA84369978@melbourne.sgi.com> <20071031233516.GB88034736@melbourne.sgi.com> In-Reply-To: <20071031233516.GB88034736@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13512 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 Niv Sardi wrote: > Eric: mkfs.conf sounds like a great idea to me, but i don't think it should > be exclusive to XFS. It's not, ext[234] already has it :) It'd have to be specific to each mkfs, I think, since each mkfs has its own knobs. -Eric From owner-xfs@oss.sgi.com Wed Oct 31 23:19:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 31 Oct 2007 23:19:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lA16JBgw002495 for ; Wed, 31 Oct 2007 23:19:14 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA06959; Thu, 1 Nov 2007 17:19:12 +1100 Message-ID: <47296FF7.8080607@sgi.com> Date: Thu, 01 Nov 2007 17:19:35 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Turn off XBF_READ_AHEAD in io completion Content-Type: multipart/mixed; boundary="------------070101030407090105070907" X-Virus-Scanned: ClamAV 0.91.2/4654/Wed Oct 31 15:07:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13513 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------070101030407090105070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Read-ahead of an inode cluster will set XBF_READ_AHEAD in the buffer. If we don't remove the flag it will still be set when we flush the buffer back to disk. Not sure if leaving this flag set causes any serious problems but it does trigger an assert. --------------070101030407090105070907 Content-Type: text/x-patch; name="readahead.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="readahead.diff" --- fs/xfs/linux-2.6/xfs_buf.c_1.247 2007-10-29 16:01:29.000000000 +1100 +++ fs/xfs/linux-2.6/xfs_buf.c 2007-10-29 14:00:53.000000000 +1100 @@ -1032,7 +1032,7 @@ xfs_buf_ioend( xfs_buf_t *bp, int schedule) { - bp->b_flags &= ~(XBF_READ | XBF_WRITE); + bp->b_flags &= ~(XBF_READ | XBF_WRITE | XBF_READ_AHEAD); if (bp->b_error == 0) bp->b_flags |= XBF_DONE; --------------070101030407090105070907--