From owner-xfs@oss.sgi.com Sat Feb 2 01:48:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 01:48:57 -0800 (PST) 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,DATE_IN_PAST_03_06 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m129moDj031280 for ; Sat, 2 Feb 2008 01:48:52 -0800 X-ASG-Debug-ID: 1201945751-02c100010000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from outbound-mail-25.bluehost.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id C447D591F79 for ; Sat, 2 Feb 2008 01:49:11 -0800 (PST) Received: from outbound-mail-25.bluehost.com (outbound-mail-25.bluehost.com [69.89.21.20]) by cuda.sgi.com with SMTP id 2yh1dF1sfWzOXx3s for ; Sat, 02 Feb 2008 01:49:11 -0800 (PST) Received: (qmail 22650 invoked by uid 0); 2 Feb 2008 09:49:11 -0000 Received: from unknown (HELO box176.bluehost.com) (69.89.25.176) by mailproxy2.bluehost.com with SMTP; 2 Feb 2008 09:49:11 -0000 Received: from localhost ([127.0.0.1] helo=box176.bluehost.com) by box176.bluehost.com with esmtp (Exim 4.68) (envelope-from ) id 1JLEzn-0007Dw-AS for linux-xfs@oss.sgi.com; Sat, 02 Feb 2008 02:49:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: Welcome to the "Com.vn" mailing list Subject: Welcome to the "Com.vn" mailing list From: com.vn-request@chanhung.com To: linux-xfs@oss.sgi.com X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 21:04:09 -0700 Precedence: bulk X-BeenThere: com.vn@chanhung.com X-Mailman-Version: 2.1.9.cp2 X-Identified-User: {507:box176.bluehost.com:mailman:box176.bluehost.com} {sentby:program running on server} X-Barracuda-Connect: outbound-mail-25.bluehost.com[69.89.21.20] X-Barracuda-Start-Time: 1201945752 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.07 X-Barracuda-Spam-Status: No, SCORE=-1.07 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_SC0_SA085b, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41150 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.40 BSF_SC0_SA085b URI: Custom Rule SA085b X-Virus-Scanned: ClamAV 0.91.2/5649/Fri Feb 1 16:54:58 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14310 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: com.vn-request@chanhung.com Precedence: bulk X-list: xfs Welcome to the Com.vn@chanhung.com mailing list! To post to this list, send your email to: com.vn@chanhung.com General information about the mailing list is at: http://chanhung.com/mailman/listinfo/com.vn_chanhung.com If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://chanhung.com/mailman/options/com.vn_chanhung.com/linux-xfs%40oss.sgi.com You can also make such adjustments via email by sending a message to: Com.vn-request@chanhung.com with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: kiapuxix Normally, Mailman will remind you of your chanhung.com mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From owner-xfs@oss.sgi.com Sat Feb 2 02:12:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 02:12:39 -0800 (PST) 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_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m12ACWCG000537 for ; Sat, 2 Feb 2008 02:12:37 -0800 X-ASG-Debug-ID: 1201947159-02c200250000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hs-out-2122.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 70B7C59201E for ; Sat, 2 Feb 2008 02:12:40 -0800 (PST) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.244]) by cuda.sgi.com with ESMTP id PqEzeTdQhIjVCFRQ for ; Sat, 02 Feb 2008 02:12:40 -0800 (PST) Received: by hs-out-2122.google.com with SMTP id 4so1258964hsl.4 for ; Sat, 02 Feb 2008 02:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=KQ+XDSd85LR04eZyGat7UEEw/AclcpVu1p2W5m8ql8s=; b=uNa2UJAoVtNrPM3B0M+CfqhwGbNYUjNiu1XV28RZC4+GRyQdkFeltt9Qgqbxsaur/T6Zk6CG4HNZHVS7uJfRYJIwmR1tx4t0tjBPloF7gTyV1ODCUw5/CShqbmjW6H3LNcTx7GnnqNrpcUamj2V9PGKJTa1kxH8JwGhaNI9FFX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=K3mw7VBZeG6MiBKuzw+tmYDaXcyrVnt5spkLt9H2n7xAsdAcaTZejcO0hK8jp41eK6mvbtE2o5RYs5PKd3b1tJ6DAXQEwH/qYf4kmAzRezMAaV2hAA1u33vyFN+j1s203gQorvqwlgFnqpxDR9C1ROdcv0FaroS02tB6flvBexI= Received: by 10.150.136.6 with SMTP id j6mr1820493ybd.126.1201947158951; Sat, 02 Feb 2008 02:12:38 -0800 (PST) Received: by 10.150.133.20 with HTTP; Sat, 2 Feb 2008 02:12:38 -0800 (PST) Message-ID: <8f1895b90802020212h278968efy7a644c55c480134e@mail.gmail.com> Date: Sat, 2 Feb 2008 11:12:38 +0100 From: "Per Lundberg" To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS: failed to read RT inodes Subject: XFS: failed to read RT inodes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: hs-out-0708.google.com[64.233.178.244] X-Barracuda-Start-Time: 1201947160 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41150 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5649/Fri Feb 1 16:54:58 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14311 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: perlun@gmail.com Precedence: bulk X-list: xfs Hello, After a hard drive failure (and no backup...) I am trying with all my strength do recover the file systems... With no real success. I have dumped over the two file systems in question to another, healthy disk drive. After dumping back the data to a third hard disk, one of the file system can be successfully mounted but with a huge number of files in the lost+found directory (after recovery using xfs_repair). Strange since the dump indicated only 11 bad sectors on that file system. However, the big (55 gig) file system cannot even be mounted and this is troublesome since it contains the most valuable data. This is what I get after doing xfs_repair on the volume: Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10 Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes The repair was done using Debian-compiled Linux kernel (2.6.17-2-k7) using xfsprogs 2.8.11-1. Afterwards, I've upgraded the kernel to 2.6.22 and xfsprogs 2.9.4-2 but it doesn't really make much of a difference. I've tried to disable the realtime stuff afterwards, by mounting the filesystem using rtdev=/dev/null but I only got the following message out of that: Jan 10 10:36:40 amos kernel: XFS: Invalid device [/dev/null], error=-15 *Any* ideas on how to proceed with this is greatly appreciated... Thanks in advance. -- Best regards, Per Lundberg From owner-xfs@oss.sgi.com Sat Feb 2 07:59:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 07:59:04 -0800 (PST) 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,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m12FwtFE022265 for ; Sat, 2 Feb 2008 07:59:01 -0800 X-ASG-Debug-ID: 1201967657-4d7300d10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 915CE592AFB for ; Sat, 2 Feb 2008 07:54:17 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id U03eo3LQigmy7XQG for ; Sat, 02 Feb 2008 07:54:17 -0800 (PST) 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 6CDCB18DAFE24; Sat, 2 Feb 2008 09:53:43 -0600 (CST) Message-ID: <47A49206.4020700@sandeen.net> Date: Sat, 02 Feb 2008 09:53:42 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Per Lundberg CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: failed to read RT inodes Subject: Re: XFS: failed to read RT inodes References: <8f1895b90802020212h278968efy7a644c55c480134e@mail.gmail.com> In-Reply-To: <8f1895b90802020212h278968efy7a644c55c480134e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1201967657 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41174 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5653/Sat Feb 2 05:54:59 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14312 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 Per Lundberg wrote: > Hello, > > After a hard drive failure (and no backup...) I am trying with all my > strength do recover the file systems... With no real success. I have > dumped over the two file systems in question to another, healthy disk > drive. After dumping back the data to a third hard disk, one of the > file system can be successfully mounted but with a huge number of > files in the lost+found directory (after recovery using xfs_repair). > Strange since the dump indicated only 11 bad sectors on that file > system. > > However, the big (55 gig) file system cannot even be mounted and this > is troublesome since it contains the most valuable data. This is what > I get after doing xfs_repair on the volume: > > Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes, > realtime, large block numbers, no debug enabled > Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem > Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10 > Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes maybe try xfs_db on the device; "sb 0" and "p" commands to see what the rt inodes are. -Eric From owner-xfs@oss.sgi.com Sat Feb 2 10:07:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 10:07:25 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m12I7Jia032249 for ; Sat, 2 Feb 2008 10:07:21 -0800 X-ASG-Debug-ID: 1201975661-49d702140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from py-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB95CD76D10 for ; Sat, 2 Feb 2008 10:07:41 -0800 (PST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by cuda.sgi.com with ESMTP id 0syRb1yJmWa9XwTN for ; Sat, 02 Feb 2008 10:07:41 -0800 (PST) Received: by py-out-1112.google.com with SMTP id j37so1673733pyc.4 for ; Sat, 02 Feb 2008 10:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:cc:subject:date:message-id:x-mailer; bh=Wu0g60u/KYOWC5JBgRvQHpt2mWsgcKEnD9/RT9q3WOw=; b=QzHmQOTLiNUslOJyKFmjJ8D7RGtXV23oj1vO+D60Gfch6RNhs2d/tGei+CgWK6I7s7uB9k0q9qMdqqnZu1JCF0ht7gSqpHbDvY98EoAbH+HsGtbW2T8hb+hxTDZsoQ/0S2tM+LBF/IRst+ervKBhXr/swkyqKjQhVALvIfieLos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer; b=L+JUWONM0WCFqZm/Y4/xHILkGaGxGPcomV6w4mKGzteuAZ/PAf7hqVeI7ZQjXgKlLhLUEARDPMxjES6t26AbVKDlBAyL93F7uSVGaFEFTcgBZf7sqZZXb/NsFmmfPQVZIE2FGX5OhiLckuBU6OZ1XzIjBZQqS0mPkRPLoqEWOBY= Received: by 10.141.185.3 with SMTP id m3mr3394244rvp.236.1201975659781; Sat, 02 Feb 2008 10:07:39 -0800 (PST) Received: from tux ( [219.134.231.43]) by mx.google.com with ESMTPS id g1sm3524827rvb.0.2008.02.02.10.07.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Feb 2008 10:07:39 -0800 (PST) Received: by tux (sSMTP sendmail emulation); Sun, 3 Feb 2008 02:07:23 +0800 From: Denis Cheng To: Tim Shimmin , Tim Shimmin Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: [PATCH] xfs: add __init/__exit mark to specific init/cleanup functions Subject: [PATCH] xfs: add __init/__exit mark to specific init/cleanup functions Date: Sun, 3 Feb 2008 02:07:23 +0800 Message-Id: <1201975643-8662-1-git-send-email-crquan@gmail.com> X-Mailer: git-send-email 1.5.3.8 X-Barracuda-Connect: py-out-1112.google.com[64.233.166.179] X-Barracuda-Start-Time: 1201975661 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41182 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5656/Sat Feb 2 08:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14313 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: crquan@gmail.com Precedence: bulk X-list: xfs Signed-off-by: Denis Cheng --- fs/xfs/linux-2.6/xfs_super.c | 2 +- fs/xfs/linux-2.6/xfs_vnode.c | 2 +- fs/xfs/support/ktrace.c | 4 ++-- fs/xfs/support/uuid.c | 2 +- fs/xfs/xfs_vfsops.c | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c index 8cb63c6..abacbdd 100644 --- a/fs/xfs/linux-2.6/xfs_super.c +++ b/fs/xfs/linux-2.6/xfs_super.c @@ -361,7 +361,7 @@ xfs_fs_inode_init_once( inode_init_once(vn_to_inode((bhv_vnode_t *)vnode)); } -STATIC int +STATIC int __init xfs_init_zones(void) { xfs_vnode_zone = kmem_zone_init_flags(sizeof(bhv_vnode_t), "xfs_vnode", diff --git a/fs/xfs/linux-2.6/xfs_vnode.c b/fs/xfs/linux-2.6/xfs_vnode.c index 814169f..56e23cd 100644 --- a/fs/xfs/linux-2.6/xfs_vnode.c +++ b/fs/xfs/linux-2.6/xfs_vnode.c @@ -40,7 +40,7 @@ #define vptosync(v) (&vsync[((unsigned long)v) % NVSYNC]) static wait_queue_head_t vsync[NVSYNC]; -void +void __init vn_init(void) { int i; diff --git a/fs/xfs/support/ktrace.c b/fs/xfs/support/ktrace.c index 5cf2e86..17f2b7c 100644 --- a/fs/xfs/support/ktrace.c +++ b/fs/xfs/support/ktrace.c @@ -21,7 +21,7 @@ static kmem_zone_t *ktrace_hdr_zone; static kmem_zone_t *ktrace_ent_zone; static int ktrace_zentries; -void +void __init ktrace_init(int zentries) { ktrace_zentries = zentries; @@ -36,7 +36,7 @@ ktrace_init(int zentries) ASSERT(ktrace_ent_zone); } -void +void __exit ktrace_uninit(void) { kmem_zone_destroy(ktrace_hdr_zone); diff --git a/fs/xfs/support/uuid.c b/fs/xfs/support/uuid.c index e157015..493a6ec 100644 --- a/fs/xfs/support/uuid.c +++ b/fs/xfs/support/uuid.c @@ -133,7 +133,7 @@ uuid_table_remove(uuid_t *uuid) mutex_unlock(&uuid_monitor); } -void +void __init uuid_init(void) { mutex_init(&uuid_monitor); diff --git a/fs/xfs/xfs_vfsops.c b/fs/xfs/xfs_vfsops.c index a154459..cde337e 100644 --- a/fs/xfs/xfs_vfsops.c +++ b/fs/xfs/xfs_vfsops.c @@ -58,7 +58,7 @@ #include "xfs_vfsops.h" -int +int __init xfs_init(void) { extern kmem_zone_t *xfs_bmap_free_item_zone; @@ -152,7 +152,7 @@ xfs_init(void) return 0; } -void +void __exit xfs_cleanup(void) { extern kmem_zone_t *xfs_bmap_free_item_zone; -- 1.5.3.8 From owner-xfs@oss.sgi.com Sat Feb 2 11:28:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 11:28:39 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m12JSYEC003943 for ; Sat, 2 Feb 2008 11:28:35 -0800 X-ASG-Debug-ID: 1201980535-149e00850000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wx-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3541F100885F for ; Sat, 2 Feb 2008 11:28:55 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by cuda.sgi.com with ESMTP id UHSg5BUAnHqgQVAW for ; Sat, 02 Feb 2008 11:28:55 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id s9so1547752wxc.32 for ; Sat, 02 Feb 2008 11:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=RXN4zfrK83KxRefUwD6+FtmL9N8ToMTjhIqvy4rW0pE=; b=kFCaPvGoSxPk9jEpKgMtVIEfmBSoCJmYB41NERsfbhfDDQuXubsT1Z1fzSXG699pdnHqi95yLc24yHbAi7tCeEWekVCmQo3kj4ub1HyW87dMwQxIr0+AP89h7sPqRae7kYwLJ9JC/Sk76jo6fVKKOouhKczifgYgGykCvGYnZZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PnhvRS3V5UPgL4jfyAo2exHYIx3NGADQYK1yOikbWQOoh3JXsUhSOKegPiBNCqxmRvUAaip6WjVJiIJaEKHXQBtIoWqWr5KGLg9U4qyByhHGW5IxOJZO4mWxPIb+EKDfZSsQhAspy7znf0n0BVhyxcTrn6hyRmI8YQaa/OT0CNc= Received: by 10.150.189.9 with SMTP id m9mr2023821ybf.73.1201978893046; Sat, 02 Feb 2008 11:01:33 -0800 (PST) Received: by 10.150.133.20 with HTTP; Sat, 2 Feb 2008 11:01:32 -0800 (PST) Message-ID: <8f1895b90802021101k63d29842re986ef75ffcc113@mail.gmail.com> Date: Sat, 2 Feb 2008 20:01:32 +0100 From: "Per Lundberg" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS: failed to read RT inodes Subject: Re: XFS: failed to read RT inodes Cc: xfs@oss.sgi.com In-Reply-To: <47A49206.4020700@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f1895b90802020212h278968efy7a644c55c480134e@mail.gmail.com> <47A49206.4020700@sandeen.net> X-Barracuda-Connect: wx-out-0506.google.com[66.249.82.228] X-Barracuda-Start-Time: 1201980536 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41186 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5656/Sat Feb 2 08:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14314 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: perlun@gmail.com Precedence: bulk X-list: xfs On Feb 2, 2008 4:53 PM, Eric Sandeen wrote: > > Jan 10 10:30:59 amos kernel: SGI XFS with ACLs, security attributes, > > realtime, large block numbers, no debug enabled > > Jan 10 10:30:59 amos kernel: SGI XFS Quota Management subsystem > > Jan 10 10:31:00 amos kernel: XFS mounting filesystem sda10 > > Jan 10 10:31:00 amos kernel: XFS: failed to read RT inodes > maybe try xfs_db on the device; "sb 0" and "p" commands to see what the > rt inodes are. Thanks for the hint! However, what I did was do a full restore of the volume again and then xfs_repair + xfs_repair -L. Now, I can mount it - but *everything* (and I really mean literally everything) has been put into lost+found. Slightly annoying to say the least, but still a whole lot better than having lost it all. I think it *could* be because of a bad imaging program (Image for Windows). The first sector of the partition doesn't seem to come through properly (after restore, it contains 512 0x00 bytes. Quite wrong in other words, so that could be the reason for the breakage. I guess I could put back the broken drive again and just "dd" over the data to the working disk but when I tried to do that yesterday on another partition, I got 500 or so bad sectors... compared to 11 with Image for Windows. So either Image for Windows was lying to me or the disk has been starting to fall apart even more. :-) -- Best regards, Per Lundberg From owner-xfs@oss.sgi.com Sat Feb 2 23:43:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Feb 2008 23:43:16 -0800 (PST) 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_20,J_CHICKENPOX_210 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m137h8mq025169 for ; Sat, 2 Feb 2008 23:43:11 -0800 X-ASG-Debug-ID: 1202024610-7b7f00180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from elasmtp-dupuy.atl.sa.earthlink.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D1181594CB3 for ; Sat, 2 Feb 2008 23:43:30 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by cuda.sgi.com with ESMTP id iueSzk56KfCJLDFl for ; Sat, 02 Feb 2008 23:43:30 -0800 (PST) Received: from [64.131.226.230] (helo=[192.168.0.150]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1JLZV6-0002cQ-3v; Sun, 03 Feb 2008 02:42:52 -0500 Message-ID: <47A57056.5070904@mpigani.org> Date: Sun, 03 Feb 2008 02:42:14 -0500 From: Dragos User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Chinner CC: Michael Tokarev , David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: assemble vs create an array....... Subject: Re: assemble vs create an array....... X-Priority: 1 (Highest) References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> <475825C0.4070605@msgid.tls.msk.ru> <20071206212225.GN115527101@sgi.com> In-Reply-To: <20071206212225.GN115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 382be18c4f3f7bcad780f4a490ca6956abb457f1b4332f52b7337aa60c136f28ffc5a819a1d59646350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.131.226.230 X-Barracuda-Connect: elasmtp-dupuy.atl.sa.earthlink.net[209.86.89.62] X-Barracuda-Start-Time: 1202024610 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.90 X-Barracuda-Spam-Status: No, SCORE=-1.90 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=X_PRIORITY_HIGH X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41233 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 X_PRIORITY_HIGH Sent with 'X-Priority' set to high X-Virus-Scanned: ClamAV 0.91.2/5665/Sat Feb 2 18:35:12 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14315 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dragos@mpigani.org Precedence: bulk X-list: xfs Hello, I am not sure if you have received my email from last week with the results of the different combinations prescribed (it contained html code). Anyway, I did a ro mount to check the partition and was happy to see a lot of files intact. A few seemed destroyed, but I am not sure. I tried a xfs_check on the partition and it told me: ERROR: The filesystem have valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Since I am unable to mount the partition, shoud I use the -L option with xfs_repair, or let it run without it? Again, please let me know if I should resend my previous email with the log file of "xfs_repair -n". Thank you for your time, Dragos David Chinner wrote: > On Thu, Dec 06, 2007 at 07:39:28PM +0300, Michael Tokarev wrote: > >> What to do is to give repairfs a try for each permutation, >> but again without letting it to actually fix anything. >> Just run it in read-only mode and see which combination >> of drives gives less errors, or no fatal errors (there >> may be several similar combinations, with the same order >> of drives but with different drive "missing"). >> > > Ugggh. > > >> It's sad that xfs refuses mount when "structure needs >> cleaning" - the best way here is to actually mount it >> and see how it looks like, instead of trying repair >> tools. >> > > It self protection - if you try to write to a corrupted filesystem, > you'll only make the corruption worse. Mounting involves log > recovery, which writes to the filesystem.... > > >> Is there some option to force-mount it still >> (in readonly mode, knowing it may OOPs kernel etc)? >> > > Sure you can: mount -o ro,norecovery > > But it you hit corruption it will still shut down on you. If > the machine oopses then that is a bug. > > >> thread prompted me to think. If I can't force-mount it >> (or browse it using other ways) as I can almost always >> do with (somewhat?) broken ext[23] just to examine things, >> maybe I'm trying it before it's mature enough? ;) >> > > Hehe ;) > > For maximum uber-XFS-guru points, learn to browse your filesystem > with xfs_db. :P > > Cheers, > > Dave. > From owner-xfs@oss.sgi.com Sun Feb 3 14:05:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 14:05:33 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m13M5N84021713 for ; Sun, 3 Feb 2008 14:05:26 -0800 X-ASG-Debug-ID: 1202076345-4a3900570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F006D7ADE8 for ; Sun, 3 Feb 2008 14:05:46 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id bttLAv3VbP1RUvbZ for ; Sun, 03 Feb 2008 14:05:46 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id E111792D3EE; Mon, 4 Feb 2008 09:05:43 +1100 (EST) X-ASG-Orig-Subj: Re: NFSD on XFS with RT subvolume Subject: Re: NFSD on XFS with RT subvolume From: Nathan Scott Reply-To: nscott@aconex.com To: Rabeeh Khoury Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Aconex Date: Mon, 04 Feb 2008 09:05:43 +1100 Message-Id: <1202076343.9463.465.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1202076346 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41290 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5673/Sun Feb 3 13:06:20 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14316 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 Wed, 2008-01-30 at 16:37 +0200, Rabeeh Khoury wrote: > Hi All, > > Exporting an XFS volume with kernel NFSD when real-time subvolume is > enabled hangs the kernel. > > I'm using vanilla LK 2.6.22.7; first I create the XFS volume with two > partitions of 20GB each with extent size of 1MB; then I create a > subdirectory in the volume and mark it (using xfs_io util) as it belongs > to the rt subvolume with inheritance flag. > > After mounting that volume through NFSv3 / UDP; and trying a 'dd > if=/dev/zero of=/mnt/rt/test bs=1M count=1000' the machine running NFSD > hangs infinitely. Did you manage to get a stack trace, OOC? No reason why it shouldn't work AFAIK. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Feb 3 14:13:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 14:13:34 -0800 (PST) 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,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.11/SuSE Linux 0.7) with SMTP id m13MDPnu022413 for ; Sun, 3 Feb 2008 14:13:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08295; Mon, 4 Feb 2008 09:13:36 +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 m13MDWLF49855544; Mon, 4 Feb 2008 09:13:34 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m13MDQ4449837659; Mon, 4 Feb 2008 09:13:26 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Feb 2008 09:13:26 +1100 From: David Chinner To: Peter Zijlstra Cc: Sven Geggus , linux-kernel@vger.kernel.org, David Chinner , xfs@oss.sgi.com, hch@lst.de Subject: Re: XFS oops in vanilla 2.6.24 Message-ID: <20080203221326.GV155407@sgi.com> References: <1201778591.28547.291.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201778591.28547.291.camel@lappy> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5673/Sun Feb 3 13:06:20 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14317 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, Jan 31, 2008 at 12:23:11PM +0100, Peter Zijlstra wrote: > Lets CC the XFS maintainer.. Adding the xfs list and hch. It might be a couple of days before I get to this - I've got a week of backlog to catch up on after LCA.... > On Wed, 2008-01-30 at 20:23 +0000, Sven Geggus wrote: > > Hi there, > > > > I get the following with 2.6.24: > > > > Ending clean XFS mount for filesystem: dm-0 > > BUG: unable to handle kernel paging request at virtual address f2134000 How long after mount does this happen? Does it happen when listing a specific directory? i.e. do you have a reproducable test case for it? Cheers, Dave. > > printing eip: c021a13a *pde = 010b5067 *pte = 32134000 > > Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC > > Modules linked in: radeon drm rfcomm l2cap sym53c8xx scsi_transport_spi snd_via82xx 8139too snd_mpu401_uart snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc via_agp agpgart > > > > Pid: 3889, comm: bash Not tainted (2.6.24 #3) > > EIP: 0060:[] EFLAGS: 00010282 CPU: 0 > > EIP is at xfs_file_readdir+0xfa/0x18c > > EAX: 00000000 EBX: 000002f5 ECX: 00000020 EDX: 00000000 > > ESI: 00000000 EDI: f2133ff8 EBP: f227ff68 ESP: f227ff10 > > DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 > > Process bash (pid: 3889, ti=f227e000 task=f7205a80 task.ti=f227e000) > > Stack: 000002f5 00000000 2c000137 00000000 00000000 c0165358 f227ff94 f221c810 > > f2d85e48 00000000 00000000 00000000 000002f5 00000000 f2133000 00001000 > > 00000ff8 000002f9 00000000 c0421c80 f221c810 f1cdbe48 f227ff88 c0165543 > > Call Trace: > > [] show_trace_log_lvl+0x1a/0x2f > > [] show_stack_log_lvl+0x9b/0xa3 > > [] show_registers+0xa0/0x1e2 > > [] die+0x10f/0x1dd > > [] do_page_fault+0x43a/0x519 > > [] error_code+0x6a/0x70 > > [] vfs_readdir+0x5d/0x89 > > [] sys_getdents64+0x5e/0xa0 > > [] syscall_call+0x7/0xb > > ======================= > > Code: 89 74 24 04 81 e3 ff ff ff 7f 89 1c 24 ff 55 bc 85 c0 0f 85 82 00 00 00 8b 4f 10 31 d2 83 c1 1f 83 e1 f8 29 4d d0 19 55 d4 01 cf <8b> 57 08 8b 4f 0c 89 55 d8 89 4d dc 83 7d d4 00 7f a1 7c 06 83 > > EIP: [] xfs_file_readdir+0xfa/0x18c SS:ESP 0068:f227ff10 > > ---[ end trace e518e1370efb695e ]--- > > > > Sven > > -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 3 14:25:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 14:25:16 -0800 (PST) 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 larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m13MP9WE023401 for ; Sun, 3 Feb 2008 14:25:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08613; Mon, 4 Feb 2008 09:25: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 m13MPQLF49872564; Mon, 4 Feb 2008 09:25:27 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m13MPPPo49847381; Mon, 4 Feb 2008 09:25:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Feb 2008 09:25:25 +1100 From: David Chinner To: Sven Geggus Cc: xfs@oss.sgi.com Subject: Re: XFS oops in vanilla 2.6.24 Message-ID: <20080203222525.GX155407@sgi.com> References: <1201778591.28547.291.camel@lappy> <20080203221326.GV155407@sgi.com> <20080203222034.GA7460@diesel.geggus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080203222034.GA7460@diesel.geggus.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5673/Sun Feb 3 13:06:20 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14318 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, Feb 03, 2008 at 11:20:34PM +0100, Sven Geggus wrote: > David Chinner schrieb am Sonntag, den 03. Februar um 23:13 Uhr: > > > How long after mount does this happen? Does it happen when listing a specific > > directory? i.e. do you have a reproducable test case for it? > > Well, it happens very soon after mounting the device. Typically when > doing ls or something trivial like this. Unfortunately this is not > really reproducable but it does happen reproducable on one specific > device here sooner or later when booting into 2.6.24. Ok. Can you use xfs_metadump to grab an image of the filesystem that you are using to reproduce this and put it up somewhere on the web so I can try to reproduce it locally? > I run xfs-repair just to make shure that the filesystem is not > corrupted. Works fine when booting 2.6.23.8 which I have been using > before. Good - that saves me from having to ask. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 3 14:52:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 14:52:11 -0800 (PST) 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 larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m13Mq5SE025022 for ; Sun, 3 Feb 2008 14:52:07 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09270; Mon, 4 Feb 2008 09:52: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 m13MqLLF49594618; Mon, 4 Feb 2008 09:52:22 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m13MqI0949831254; Mon, 4 Feb 2008 09:52:18 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Feb 2008 09:52:18 +1100 From: David Chinner To: Michael Nishimoto Cc: XFS Mailing List Subject: Re: Extent merging past MAXEXTLEN Message-ID: <20080203225218.GY155407@sgi.com> References: <479E4A52.6000804@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <479E4A52.6000804@agami.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5673/Sun Feb 3 13:06:20 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14319 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, Jan 28, 2008 at 01:34:10PM -0800, Michael Nishimoto wrote: > Hi everyone, > > Is there a reason to continue limiting extent merges past MAXEXTLEN > on 64-bit systems? I don't think 32/64bit issues enter into this - the max extent length is determined by the filesystem block size (the on disk length is in filesystem blocks) so by default we are already at byte lengths greater than what fits in a 32bit variable (i.e. 2^21*2^12 = 2^33). Basically, MAXEXTLEN defines the number of bits in the length field of the on-disk extent record when it is packed and so without a on-disk format change, we can't sanely increase the size of this field. Perhaps we should look at doing this, but it's going to have to wait until the btree re-factoring code is completed so we can implement the record format change sanely.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 3 20:30:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 20:31:06 -0800 (PST) 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 cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m144UtRR022140 for ; Sun, 3 Feb 2008 20:30:58 -0800 X-ASG-Debug-ID: 1202099477-7afd002c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4E19059798C for ; Sun, 3 Feb 2008 20:31:17 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id ECr9N5X038xk7C1Y for ; Sun, 03 Feb 2008 20:31:17 -0800 (PST) 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 3FB8418DAFEF1 for ; Sun, 3 Feb 2008 22:30:45 -0600 (CST) Message-ID: <47A694F3.9010307@sandeen.net> Date: Sun, 03 Feb 2008 22:30:43 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: unpushed 4-month-old mods? Subject: unpushed 4-month-old mods? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1202099478 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41314 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14320 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 At least these three mods which I did back in September to get Fedora 8 / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to kernel.org, and are missing in 2.6.24... Is there any reason for the holdup? Makes me wonder what else isn't pushed... ------------- 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 Merge of xfs-linux-melb:xfs-kern:29834a by kenmcd. Refactor xfs_mountfs and: optimize XFS_IS_REALTIME_INODE w/o realtime config 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 Merge of xfs-linux-melb:xfs-kern:30014a by kenmcd. Use XFS_IS_REALTIME_INODE() rather than open coding the check. 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 Merge of xfs-linux-melb:xfs-kern:29849a by kenmcd. fix 32-bit compat ioctls for GETXFLAGS, SETXFLAGS, GETVERSION From owner-xfs@oss.sgi.com Sun Feb 3 20:46:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 20:46:07 -0800 (PST) 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.11/SuSE Linux 0.7) with SMTP id m144jv9V023120 for ; Sun, 3 Feb 2008 20:46:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16110; Mon, 4 Feb 2008 15:46:14 +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 m144kCLF50026827; Mon, 4 Feb 2008 15:46:13 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m144kBDW50060722; Mon, 4 Feb 2008 15:46:11 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 4 Feb 2008 15:46:11 +1100 From: David Chinner To: Eric Sandeen Cc: xfs-oss Subject: Re: unpushed 4-month-old mods? Message-ID: <20080204044611.GF155407@sgi.com> References: <47A694F3.9010307@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A694F3.9010307@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14321 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, Feb 03, 2008 at 10:30:43PM -0600, Eric Sandeen wrote: > At least these three mods which I did back in September to get Fedora 8 > / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to > kernel.org, and are missing in 2.6.24... > > Is there any reason for the holdup? Makes me wonder what else isn't > pushed... The holdup is that we drew a line in the sand for the 2.6.24 before 2.6.23 was released. We did this because of the massive amount of invasive change we already had queued up for 2.6.24. All those mods that got held up will be pushed into 2.6.25 release. Given the problems with the readdir changes (which still isn't 100% right given we've had at least one bug report of a crash in the readdir code post 2.6.24 release), we couldn't have handled much more change in that release..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 3 20:50:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 20:50:11 -0800 (PST) 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 cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m144o4qf023528 for ; Sun, 3 Feb 2008 20:50:08 -0800 X-ASG-Debug-ID: 1202100626-0424013d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4EB42596874 for ; Sun, 3 Feb 2008 20:50:27 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id pfkDJEY8p4t4HI2O for ; Sun, 03 Feb 2008 20:50:27 -0800 (PST) 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 C267218DAFE3B; Sun, 3 Feb 2008 22:50:25 -0600 (CST) Message-ID: <47A69990.3030501@sandeen.net> Date: Sun, 03 Feb 2008 22:50:24 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss X-ASG-Orig-Subj: Re: unpushed 4-month-old mods? Subject: Re: unpushed 4-month-old mods? References: <47A694F3.9010307@sandeen.net> <20080204044611.GF155407@sgi.com> In-Reply-To: <20080204044611.GF155407@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1202100627 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41316 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14322 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, Feb 03, 2008 at 10:30:43PM -0600, Eric Sandeen wrote: >> At least these three mods which I did back in September to get Fedora 8 >> / 2.6.23 into shape on 4k stacks, and a bugfix, are still not pushed to >> kernel.org, and are missing in 2.6.24... >> >> Is there any reason for the holdup? Makes me wonder what else isn't >> pushed... > > The holdup is that we drew a line in the sand for the 2.6.24 before > 2.6.23 was released. We did this because of the massive amount of invasive > change we already had queued up for 2.6.24. All those mods that got > held up will be pushed into 2.6.25 release. > > Given the problems with the readdir changes (which still isn't 100% right > given we've had at least one bug report of a crash in the readdir code > post 2.6.24 release), we couldn't have handled much more change in that > release..... Ok, as long as you guys know what's up :) I just spent the evening sorting out why Fedora 9 was blowing up on install, when Fedora 8 was working so well... :( -Eric From owner-xfs@oss.sgi.com Sun Feb 3 22:28:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 22:28:25 -0800 (PST) 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_62, J_CHICKENPOX_63,J_CHICKENPOX_64 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m146SDHl029501 for ; Sun, 3 Feb 2008 22:28:16 -0800 X-ASG-Debug-ID: 1202106508-6eaa00310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mta4.srv.hcvlny.cv.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 799F5D7F368 for ; Sun, 3 Feb 2008 22:28:28 -0800 (PST) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by cuda.sgi.com with ESMTP id f6Qiiru6zLGtB5B4 for ; Sun, 03 Feb 2008 22:28:28 -0800 (PST) Received: from freyr.home (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVP00905BBC7T21@mta4.srv.hcvlny.cv.net> for xfs@oss.sgi.com; Mon, 04 Feb 2008 01:28:27 -0500 (EST) Received: by freyr.home (Postfix, from userid 1000) id 2591A800BA3; Mon, 04 Feb 2008 01:28:09 -0500 (EST) Date: Mon, 04 Feb 2008 01:28:08 -0500 From: "Josef 'Jeff' Sipek" X-ASG-Orig-Subj: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head Subject: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head In-reply-to: <20080125070800.GH155407@sgi.com> To: dgc@sgi.com, xfs@oss.sgi.com, hch@infradead.org Cc: "Josef 'Jeff' Sipek" Message-id: <1202106488-31494-1-git-send-email-jeffpc@josefsipek.net> X-Mailer: git-send-email 1.5.4.rc2.85.g9de45-dirty Content-transfer-encoding: 7BIT References: <20080125070800.GH155407@sgi.com> X-Barracuda-Connect: mta4.srv.hcvlny.cv.net[167.206.4.199] X-Barracuda-Start-Time: 1202106515 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41321 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14323 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs Signed-off-by: Josef 'Jeff' Sipek --- This patch assumes you already have Dave Chinner's patch for xfsidbg_xlogitem and xfsidbg_xaildump is needed. Changes since V1: - Pass around a pointer to the AIL, not the struct list_head - Make sure things compile & run with CONFIG_XFS_DEBUG --- fs/xfs/xfs_mount.h | 2 +- fs/xfs/xfs_trans.h | 7 +-- fs/xfs/xfs_trans_ail.c | 149 +++++++++++++++++++---------------------------- 3 files changed, 62 insertions(+), 96 deletions(-) diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index f7c620e..435d625 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -220,7 +220,7 @@ extern void xfs_icsb_sync_counters_flags(struct xfs_mount *, int); #endif typedef struct xfs_ail { - xfs_ail_entry_t xa_ail; + struct list_head xa_ail; uint xa_gen; struct task_struct *xa_task; xfs_lsn_t xa_target; diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 7f40628..50ce02b 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -113,13 +113,8 @@ struct xfs_mount; struct xfs_trans; struct xfs_dquot_acct; -typedef struct xfs_ail_entry { - struct xfs_log_item *ail_forw; /* AIL forw pointer */ - struct xfs_log_item *ail_back; /* AIL back pointer */ -} xfs_ail_entry_t; - typedef struct xfs_log_item { - xfs_ail_entry_t li_ail; /* AIL pointers */ + struct list_head li_ail; /* AIL pointers */ xfs_lsn_t li_lsn; /* last on-disk lsn */ struct xfs_log_item_desc *li_desc; /* ptr to current desc*/ struct xfs_mount *li_mountp; /* ptr to fs mount */ diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index 4d6330e..8b3fd60 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -28,13 +28,13 @@ #include "xfs_trans_priv.h" #include "xfs_error.h" -STATIC void xfs_ail_insert(xfs_ail_entry_t *, xfs_log_item_t *); -STATIC xfs_log_item_t * xfs_ail_delete(xfs_ail_entry_t *, xfs_log_item_t *); -STATIC xfs_log_item_t * xfs_ail_min(xfs_ail_entry_t *); -STATIC xfs_log_item_t * xfs_ail_next(xfs_ail_entry_t *, xfs_log_item_t *); +STATIC void xfs_ail_insert(xfs_ail_t *, xfs_log_item_t *); +STATIC xfs_log_item_t * xfs_ail_delete(xfs_ail_t *, xfs_log_item_t *); +STATIC xfs_log_item_t * xfs_ail_min(xfs_ail_t *); +STATIC xfs_log_item_t * xfs_ail_next(xfs_ail_t *, xfs_log_item_t *); #ifdef DEBUG -STATIC void xfs_ail_check(xfs_ail_entry_t *, xfs_log_item_t *); +STATIC void xfs_ail_check(xfs_ail_t *, xfs_log_item_t *); #else #define xfs_ail_check(a,l) #endif /* DEBUG */ @@ -57,7 +57,7 @@ xfs_trans_tail_ail( xfs_log_item_t *lip; spin_lock(&mp->m_ail_lock); - lip = xfs_ail_min(&(mp->m_ail.xa_ail)); + lip = xfs_ail_min(&(mp->m_ail)); if (lip == NULL) { lsn = (xfs_lsn_t)0; } else { @@ -91,7 +91,7 @@ xfs_trans_push_ail( { xfs_log_item_t *lip; - lip = xfs_ail_min(&mp->m_ail.xa_ail); + lip = xfs_ail_min(&mp->m_ail); if (lip && !XFS_FORCED_SHUTDOWN(mp)) { if (XFS_LSN_CMP(threshold_lsn, mp->m_ail.xa_target) > 0) xfsaild_wakeup(mp, threshold_lsn); @@ -111,15 +111,17 @@ xfs_trans_first_push_ail( { xfs_log_item_t *lip; - lip = xfs_ail_min(&(mp->m_ail.xa_ail)); + lip = xfs_ail_min(&(mp->m_ail)); *gen = (int)mp->m_ail.xa_gen; if (lsn == 0) return lip; - while (lip && (XFS_LSN_CMP(lip->li_lsn, lsn) < 0)) - lip = lip->li_ail.ail_forw; + list_for_each_entry(lip, &mp->m_ail.xa_ail, li_ail) { + if (XFS_LSN_CMP(lip->li_lsn, lsn) >= 0) + return lip; + } - return lip; + return NULL; } /* @@ -326,7 +328,7 @@ xfs_trans_unlocked_item( * the call to xfs_log_move_tail() doesn't do anything if there's * not enough free space to wake people up so we're safe calling it. */ - min_lip = xfs_ail_min(&mp->m_ail.xa_ail); + min_lip = xfs_ail_min(&mp->m_ail); if (min_lip == lip) xfs_log_move_tail(mp, 1); @@ -354,15 +356,13 @@ xfs_trans_update_ail( xfs_log_item_t *lip, xfs_lsn_t lsn) __releases(mp->m_ail_lock) { - xfs_ail_entry_t *ailp; xfs_log_item_t *dlip=NULL; xfs_log_item_t *mlip; /* ptr to minimum lip */ - ailp = &(mp->m_ail.xa_ail); - mlip = xfs_ail_min(ailp); + mlip = xfs_ail_min(&mp->m_ail); if (lip->li_flags & XFS_LI_IN_AIL) { - dlip = xfs_ail_delete(ailp, lip); + dlip = xfs_ail_delete(&mp->m_ail, lip); ASSERT(dlip == lip); } else { lip->li_flags |= XFS_LI_IN_AIL; @@ -370,11 +370,11 @@ xfs_trans_update_ail( lip->li_lsn = lsn; - xfs_ail_insert(ailp, lip); + xfs_ail_insert(&mp->m_ail, lip); mp->m_ail.xa_gen++; if (mlip == dlip) { - mlip = xfs_ail_min(&(mp->m_ail.xa_ail)); + mlip = xfs_ail_min(&mp->m_ail); spin_unlock(&mp->m_ail_lock); xfs_log_move_tail(mp, mlip->li_lsn); } else { @@ -404,14 +404,12 @@ xfs_trans_delete_ail( xfs_mount_t *mp, xfs_log_item_t *lip) __releases(mp->m_ail_lock) { - xfs_ail_entry_t *ailp; xfs_log_item_t *dlip; xfs_log_item_t *mlip; if (lip->li_flags & XFS_LI_IN_AIL) { - ailp = &(mp->m_ail.xa_ail); - mlip = xfs_ail_min(ailp); - dlip = xfs_ail_delete(ailp, lip); + mlip = xfs_ail_min(&mp->m_ail); + dlip = xfs_ail_delete(&mp->m_ail, lip); ASSERT(dlip == lip); @@ -420,7 +418,7 @@ xfs_trans_delete_ail( mp->m_ail.xa_gen++; if (mlip == dlip) { - mlip = xfs_ail_min(&(mp->m_ail.xa_ail)); + mlip = xfs_ail_min(&(mp->m_ail)); spin_unlock(&mp->m_ail_lock); xfs_log_move_tail(mp, (mlip ? mlip->li_lsn : 0)); } else { @@ -458,7 +456,7 @@ xfs_trans_first_ail( { xfs_log_item_t *lip; - lip = xfs_ail_min(&(mp->m_ail.xa_ail)); + lip = xfs_ail_min(&(mp->m_ail)); *gen = (int)mp->m_ail.xa_gen; return lip; @@ -482,9 +480,9 @@ xfs_trans_next_ail( ASSERT(mp && lip && gen); if (mp->m_ail.xa_gen == *gen) { - nlip = xfs_ail_next(&(mp->m_ail.xa_ail), lip); + nlip = xfs_ail_next(&(mp->m_ail), lip); } else { - nlip = xfs_ail_min(&(mp->m_ail).xa_ail); + nlip = xfs_ail_min(&(mp->m_ail)); *gen = (int)mp->m_ail.xa_gen; if (restarts != NULL) { XFS_STATS_INC(xs_push_ail_restarts); @@ -514,8 +512,7 @@ int xfs_trans_ail_init( xfs_mount_t *mp) { - mp->m_ail.xa_ail.ail_forw = (xfs_log_item_t*)&mp->m_ail.xa_ail; - mp->m_ail.xa_ail.ail_back = (xfs_log_item_t*)&mp->m_ail.xa_ail; + INIT_LIST_HEAD(&mp->m_ail.xa_ail); return xfsaild_start(mp); } @@ -534,7 +531,7 @@ xfs_trans_ail_destroy( */ STATIC void xfs_ail_insert( - xfs_ail_entry_t *base, + xfs_ail_t *ailp, xfs_log_item_t *lip) /* ARGSUSED */ { @@ -543,27 +540,22 @@ xfs_ail_insert( /* * If the list is empty, just insert the item. */ - if (base->ail_back == (xfs_log_item_t*)base) { - base->ail_forw = lip; - base->ail_back = lip; - lip->li_ail.ail_forw = (xfs_log_item_t*)base; - lip->li_ail.ail_back = (xfs_log_item_t*)base; + if (list_empty(&ailp->xa_ail)) { + list_add(&lip->li_ail, &ailp->xa_ail); return; } - next_lip = base->ail_back; - while ((next_lip != (xfs_log_item_t*)base) && - (XFS_LSN_CMP(next_lip->li_lsn, lip->li_lsn) > 0)) { - next_lip = next_lip->li_ail.ail_back; + list_for_each_entry_reverse(next_lip, &ailp->xa_ail, li_ail) { + if (XFS_LSN_CMP(next_lip->li_lsn, lip->li_lsn) <= 0) + break; } - ASSERT((next_lip == (xfs_log_item_t*)base) || + + ASSERT((&next_lip->li_ail == &ailp->xa_ail) || (XFS_LSN_CMP(next_lip->li_lsn, lip->li_lsn) <= 0)); - lip->li_ail.ail_forw = next_lip->li_ail.ail_forw; - lip->li_ail.ail_back = next_lip; - next_lip->li_ail.ail_forw = lip; - lip->li_ail.ail_forw->li_ail.ail_back = lip; - xfs_ail_check(base, lip); + list_add(&lip->li_ail, &next_lip->li_ail); + + xfs_ail_check(ailp, lip); return; } @@ -573,15 +565,13 @@ xfs_ail_insert( /*ARGSUSED*/ STATIC xfs_log_item_t * xfs_ail_delete( - xfs_ail_entry_t *base, + xfs_ail_t *ailp, xfs_log_item_t *lip) /* ARGSUSED */ { - xfs_ail_check(base, lip); - lip->li_ail.ail_forw->li_ail.ail_back = lip->li_ail.ail_back; - lip->li_ail.ail_back->li_ail.ail_forw = lip->li_ail.ail_forw; - lip->li_ail.ail_forw = NULL; - lip->li_ail.ail_back = NULL; + xfs_ail_check(ailp, lip); + + list_del(&lip->li_ail); return lip; } @@ -592,14 +582,13 @@ xfs_ail_delete( */ STATIC xfs_log_item_t * xfs_ail_min( - xfs_ail_entry_t *base) + xfs_ail_t *ailp) /* ARGSUSED */ { - register xfs_log_item_t *forw = base->ail_forw; - if (forw == (xfs_log_item_t*)base) { + if (list_empty(&ailp->xa_ail)) return NULL; - } - return forw; + + return list_first_entry(&ailp->xa_ail, xfs_log_item_t, li_ail); } /* @@ -609,15 +598,14 @@ xfs_ail_min( */ STATIC xfs_log_item_t * xfs_ail_next( - xfs_ail_entry_t *base, + xfs_ail_t *ailp, xfs_log_item_t *lip) /* ARGSUSED */ { - if (lip->li_ail.ail_forw == (xfs_log_item_t*)base) { + if (lip->li_ail.next == &ailp->xa_ail) return NULL; - } - return lip->li_ail.ail_forw; + return list_first_entry(&lip->li_ail, xfs_log_item_t, li_ail); } #ifdef DEBUG @@ -626,57 +614,40 @@ xfs_ail_next( */ STATIC void xfs_ail_check( - xfs_ail_entry_t *base, + xfs_ail_t *ailp, xfs_log_item_t *lip) { xfs_log_item_t *prev_lip; - prev_lip = base->ail_forw; - if (prev_lip == (xfs_log_item_t*)base) { - /* - * Make sure the pointers are correct when the list - * is empty. - */ - ASSERT(base->ail_back == (xfs_log_item_t*)base); + if (list_empty(&ailp->xa_ail)) return; - } /* * Check the next and previous entries are valid. */ ASSERT((lip->li_flags & XFS_LI_IN_AIL) != 0); - prev_lip = lip->li_ail.ail_back; - if (prev_lip != (xfs_log_item_t*)base) { - ASSERT(prev_lip->li_ail.ail_forw == lip); + prev_lip = list_entry(lip->li_ail.prev, xfs_log_item_t, li_ail); + if (&prev_lip->li_ail != &ailp->xa_ail) ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) <= 0); - } - prev_lip = lip->li_ail.ail_forw; - if (prev_lip != (xfs_log_item_t*)base) { - ASSERT(prev_lip->li_ail.ail_back == lip); + + prev_lip = list_entry(lip->li_ail.next, xfs_log_item_t, li_ail); + if (&prev_lip->li_ail != &ailp->xa_ail) ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) >= 0); - } #ifdef XFS_TRANS_DEBUG /* - * Walk the list checking forward and backward pointers, - * lsn ordering, and that every entry has the XFS_LI_IN_AIL - * flag set. This is really expensive, so only do it when - * specifically debugging the transaction subsystem. + * Walk the list checking lsn ordering, and that every entry has the + * XFS_LI_IN_AIL flag set. This is really expensive, so only do it + * when specifically debugging the transaction subsystem. */ - prev_lip = (xfs_log_item_t*)base; - while (lip != (xfs_log_item_t*)base) { - if (prev_lip != (xfs_log_item_t*)base) { - ASSERT(prev_lip->li_ail.ail_forw == lip); + prev_lip = list_entry(&ailp->xa_ail, xfs_log_item_t, li_ail); + list_for_each_entry(lip, &ailp->xa_ail, li_ail) { + if (&prev_lip->li_ail != &ailp->xa_ail) ASSERT(XFS_LSN_CMP(prev_lip->li_lsn, lip->li_lsn) <= 0); - } - ASSERT(lip->li_ail.ail_back == prev_lip); ASSERT((lip->li_flags & XFS_LI_IN_AIL) != 0); prev_lip = lip; - lip = lip->li_ail.ail_forw; } - ASSERT(lip == (xfs_log_item_t*)base); - ASSERT(base->ail_back == prev_lip); #endif /* XFS_TRANS_DEBUG */ } #endif /* DEBUG */ -- 1.5.4.rc2.85.g9de45-dirty From owner-xfs@oss.sgi.com Sun Feb 3 22:33:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Feb 2008 22:33:23 -0800 (PST) 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=BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m146XFoD030023 for ; Sun, 3 Feb 2008 22:33:17 -0800 X-ASG-Debug-ID: 1202106670-6ed8003e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mta5.srv.hcvlny.cv.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71D22D7F381 for ; Sun, 3 Feb 2008 22:31:10 -0800 (PST) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by cuda.sgi.com with ESMTP id FHIFYBDRX231KuEi for ; Sun, 03 Feb 2008 22:31:10 -0800 (PST) Received: from freyr.home (ool-44c218a8.dyn.optonline.net [68.194.24.168]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVP005HQBFVJFW0@mta5.srv.hcvlny.cv.net> for xfs@oss.sgi.com; Mon, 04 Feb 2008 01:31:07 -0500 (EST) Received: by freyr.home (Postfix, from userid 1000) id 3F4E5800BA3; Mon, 04 Feb 2008 01:30:52 -0500 (EST) Date: Mon, 04 Feb 2008 01:30:52 -0500 (EST) From: jeffpc@home.josefsipek.net (Jeff) X-ASG-Orig-Subj: XFS compile error Subject: XFS compile error To: xfs@oss.sgi.com Cc: jeffpc@josefsipek.net Message-id: <20080204063052.3F4E5800BA3@freyr.home> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT X-Barracuda-Connect: mta5.srv.hcvlny.cv.net[167.206.4.200] X-Barracuda-Start-Time: 1202106670 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41321 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14324 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@home.josefsipek.net Precedence: bulk X-list: xfs Enabling CONFIG_XFS_DEBUG as well as XFS_TRANS_DEBUG (by editing the makefile) results in a compile error: $ make CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h CC [M] fs/xfs/xfs_rtalloc.o CC [M] fs/xfs/xfs_acl.o CC [M] fs/xfs/linux-2.6/xfs_stats.o CC [M] fs/xfs/linux-2.6/xfs_sysctl.o CC [M] fs/xfs/xfs_alloc.o CC [M] fs/xfs/xfs_alloc_btree.o CC [M] fs/xfs/xfs_attr.o CC [M] fs/xfs/xfs_attr_leaf.o CC [M] fs/xfs/xfs_bit.o CC [M] fs/xfs/xfs_bmap.o CC [M] fs/xfs/xfs_bmap_btree.o CC [M] fs/xfs/xfs_btree.o CC [M] fs/xfs/xfs_buf_item.o fs/xfs/xfs_buf_item.c: In function ‘xfs_buf_item_log_debug’: fs/xfs/xfs_buf_item.c:64: error: implicit declaration of function ‘bfset’ fs/xfs/xfs_buf_item.c: In function ‘xfs_buf_item_log_check’: fs/xfs/xfs_buf_item.c:127: error: implicit declaration of function ‘btst’ fs/xfs/xfs_buf_item.c:130: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘struct xfs_buf_log_item_t *’ fs/xfs/xfs_buf_item.c:130: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct xfs_buf_t *’ fs/xfs/xfs_buf_item.c:130: warning: format ‘%x’ expects type ‘unsigned int’, but argument 5 has type ‘char *’ make[2]: *** [fs/xfs/xfs_buf_item.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 From owner-xfs@oss.sgi.com Mon Feb 4 06:14:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 06:14:50 -0800 (PST) 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_47 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14EEhq0030047 for ; Mon, 4 Feb 2008 06:14:47 -0800 X-ASG-Debug-ID: 1202134226-782303810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9E6735998AA for ; Mon, 4 Feb 2008 06:10:26 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id yai2tMuDXcE0xJHQ for ; Mon, 04 Feb 2008 06:10:26 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 2D9581C000230; Mon, 4 Feb 2008 09:09:53 -0500 (EST) Date: Mon, 4 Feb 2008 09:09:53 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Michael Tokarev cc: Moshe Yudkowsky , linux-raid@vger.kernel.org, xfs@oss.sgi.com, sandeen@sandeen.net X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) In-Reply-To: <47A7188A.4070005@msgid.tls.msk.ru> Message-ID: References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1202134226 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41350 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14325 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 Mon, 4 Feb 2008, Michael Tokarev wrote: > Moshe Yudkowsky wrote: > [] >> If I'm reading the man pages, Wikis, READMEs and mailing lists correctly >> -- not necessarily the case -- the ext3 file system uses the equivalent >> of data=journal as a default. > > ext3 defaults to data=ordered, not data=journal. ext2 doesn't have > journal at all. > >> The question then becomes what data scheme to use with reiserfs on the > > I'd say don't use reiserfs in the first place ;) > >> Another way to phrase this: unless you're running data-center grade >> hardware and have absolute confidence in your UPS, you should use >> data=journal for reiserfs and perhaps avoid XFS entirely. > > By the way, even if you do have a good UPS, there should be some > control program for it, to properly shut down your system when > UPS loses the AC power. So far, I've seen no such programs... > > /mjt Why avoid XFS entirely? esandeen, any comments here? Justin. From owner-xfs@oss.sgi.com Mon Feb 4 06:25:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 06:26:03 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14EPrWK030777 for ; Mon, 4 Feb 2008 06:25:54 -0800 X-ASG-Debug-ID: 1202135171-4f6b002a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B5DD2D816A6 for ; Mon, 4 Feb 2008 06:26:12 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id to2W1dZ7BVrDaSZk for ; Mon, 04 Feb 2008 06:26:12 -0800 (PST) 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 6DA4718DAFE3B; Mon, 4 Feb 2008 08:25:38 -0600 (CST) Message-ID: <47A72061.3010800@sandeen.net> Date: Mon, 04 Feb 2008 08:25:37 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Justin Piszcz CC: Michael Tokarev , Moshe Yudkowsky , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1202135175 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41351 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14326 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 Justin Piszcz wrote: > Why avoid XFS entirely? > > esandeen, any comments here? Heh; well, it's the meme. see: http://oss.sgi.com/projects/xfs/faq.html#nulls and note that recent fixes have been made in this area (also noted in the faq) Also - the above all assumes that when a drive says it's written/flushed data, that it truly has. Modern write-caching drives can wreak havoc with any journaling filesystem, so that's one good reason for a UPS. If the drive claims to have metadata safe on disk but actually does not, and you lose power, the data claimed safe will evaporate, there's not much the fs can do. IO write barriers address this by forcing the drive to flush order-critical data before continuing; xfs has them on by default, although they are tested at mount time and if you have something in between xfs and the disks which does not support barriers (i.e. lvm...) then they are disabled again, with a notice in the logs. Note also that ext3 has the barrier option as well, but it is not enabled by default due to performance concerns. Barriers also affect xfs performance, but enabling them in the non-battery-backed-write-cache scenario is the right thing to do for filesystem integrity. -Eric > Justin. > From owner-xfs@oss.sgi.com Mon Feb 4 06:42:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 06:42:27 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14EgHrB031569 for ; Mon, 4 Feb 2008 06:42:22 -0800 X-ASG-Debug-ID: 1202136159-50b9016a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1BD75D814DD for ; Mon, 4 Feb 2008 06:42:39 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 0H72o639FJS6AYDh for ; Mon, 04 Feb 2008 06:42:39 -0800 (PST) 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 D302218DAFEF7; Mon, 4 Feb 2008 08:42:38 -0600 (CST) Message-ID: <47A7245E.4070207@sandeen.net> Date: Mon, 04 Feb 2008 08:42:38 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Justin Piszcz CC: Michael Tokarev , Moshe Yudkowsky , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> In-Reply-To: <47A72061.3010800@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1202136160 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41352 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5678/Sun Feb 3 17:15:53 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14327 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: > Justin Piszcz wrote: > >> Why avoid XFS entirely? >> >> esandeen, any comments here? > > Heh; well, it's the meme. > > see: > > http://oss.sgi.com/projects/xfs/faq.html#nulls > > and note that recent fixes have been made in this area (also noted in > the faq) Actually, continue reading past that specific entry to the next several, it covers all this quite well. -Eric From owner-xfs@oss.sgi.com Mon Feb 4 07:31:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 07:31:13 -0800 (PST) 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 cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14FV2GE001140 for ; Mon, 4 Feb 2008 07:31:06 -0800 X-ASG-Debug-ID: 1202139081-205f02cc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp02.lnh.mail.rcn.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 45B8E59A228 for ; Mon, 4 Feb 2008 07:31:22 -0800 (PST) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by cuda.sgi.com with ESMTP id 4AlR8oIx7whUBTqT for ; Mon, 04 Feb 2008 07:31:22 -0800 (PST) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 04 Feb 2008 10:31:16 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id JQE20347; Mon, 4 Feb 2008 10:31:14 -0500 (EST) Received: from 207-229-180-107.arm-bsr1.chi-arm.il.cable.rcn.com (HELO [172.28.54.160]) ([207.229.180.107]) by smtp01.lnh.mail.rcn.net with ESMTP; 04 Feb 2008 10:30:09 -0500 Message-ID: <47A72FBC.9090701@pobox.com> Date: Mon, 04 Feb 2008 09:31:08 -0600 From: Moshe Yudkowsky Organization: The Institute User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Eric Sandeen CC: Justin Piszcz , Michael Tokarev , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> In-Reply-To: <47A72061.3010800@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A010208.47A72FC3.012E,ss=1,fgs=0, ip=207.172.4.11, so=2007-10-30 19:00:17, dmn=5.4.3/2007-11-16 X-Junkmail-IWF: false X-Barracuda-Connect: smtp02.lnh.mail.rcn.net[207.172.157.102] X-Barracuda-Start-Time: 1202139085 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41354 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5679/Mon Feb 4 06:57:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14328 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: moshe@pobox.com Precedence: bulk X-list: xfs Eric, Thanks very much for your note. I'm becoming very leery of resiserfs at the moment... I'm about to run another series of crash tests. Eric Sandeen wrote: > Justin Piszcz wrote: > >> Why avoid XFS entirely? >> >> esandeen, any comments here? > > Heh; well, it's the meme. Well, yeah... > Note also that ext3 has the barrier option as well, but it is not > enabled by default due to performance concerns. Barriers also affect > xfs performance, but enabling them in the non-battery-backed-write-cache > scenario is the right thing to do for filesystem integrity. So if I understand you correctly, you're stating that current the most reliable fs in its default configuration, in terms of protection against power-loss scenarios, is XFS? -- Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe "There is something fundamentally wrong with a country [USSR] where the citizens want to buy your underwear." -- Paul Thereaux From owner-xfs@oss.sgi.com Mon Feb 4 08:29:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 08:30:00 -0800 (PST) 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_23 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14GTo2P007893 for ; Mon, 4 Feb 2008 08:29:55 -0800 X-ASG-Debug-ID: 1202142612-591b025e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.emlix.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6A009D82B7D for ; Mon, 4 Feb 2008 08:30:12 -0800 (PST) Received: from mx1.emlix.com (mx1.emlix.com [193.175.82.87]) by cuda.sgi.com with ESMTP id c5McXkNVSUv1M6zp for ; Mon, 04 Feb 2008 08:30:12 -0800 (PST) Received: from gate.emlix.com ([193.175.27.217]:50835 helo=mailer.emlix.com) by mx1.emlix.com with esmtp (Exim 4.63) (envelope-from ) id 1JM4QM-0007MD-Ny for xfs@oss.sgi.com; Mon, 04 Feb 2008 17:44:02 +0100 Received: by mailer.emlix.com id 1JM4Cv-0007hi-OO; Mon, 04 Feb 2008 17:30:09 +0100 Received: by spinat.emlix.com (Postfix, from userid 2047) id 8CDEA7F452; Mon, 4 Feb 2008 17:30:09 +0100 (CET) Date: Mon, 4 Feb 2008 17:30:09 +0100 From: Tobias Ulmer To: xfs@oss.sgi.com X-ASG-Orig-Subj: Another oops in xfs_file_readdir (vanilla linux 2.6.24+) Subject: Another oops in xfs_file_readdir (vanilla linux 2.6.24+) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Message-Id: Organization: emlix gmbh, Goettingen, Germany X-Barracuda-Connect: mx1.emlix.com[193.175.82.87] X-Barracuda-Start-Time: 1202142613 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41358 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5679/Mon Feb 4 06:57:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14329 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tu@emlix.com Precedence: bulk X-list: xfs Hi, i've got a nice oops from a clean pull of linus tree on saturday (head is 24e1c13c93cbdd05e4b7ea921c0050b036555adc) BUG: unable to handle kernel paging request at f8000000 IP: [] xfs_file_readdir+0x157/0x1e0 *pde = 00000000 Oops: 0000 [#1] PREEMPT Modules linked in: Pid: 30823, comm: rm Not tainted (2.6.24toy #18) EIP: 0060:[] EFLAGS: 00010246 CPU: 0 EIP is at xfs_file_readdir+0x157/0x1e0 EAX: 00000000 EBX: 0000046b ECX: 00000028 EDX: 00000000 ESI: 00000000 EDI: f7fffff8 EBP: de28e480 ESP: e04cdf18 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process rm (pid: 30823, ti=e04cc000 task=ccf96f60 task.ti=e04cc000) Stack: 0000046b 00000000 090485aa 00000000 00000000 c016c0e0 e04cdf94 f6da6280 00000000 00000000 00000000 0000046b 00000000 f7fff000 00001000 00000ff8 0000046e 00000000 c03974c0 f6da6280 de28d3c0 c016c0e0 c016c321 e04cdf94 Call Trace: [] filldir64+0x0/0xe0 [] filldir64+0x0/0xe0 [] vfs_readdir+0x81/0xa0 [] sys_getdents64+0x73/0xd0 [] sysenter_past_esp+0x5f/0x85 ======================= Code: 81 e3 ff ff ff 7f 89 1c 24 ff 54 24 14 85 c0 75 51 8b 4f 10 31 d2 83 c1 1f 83 e1 f8 29 4c 24 24 19 24 28 00 <8b> 47 08 8b 57 0c 89 44 24 2c 89 54 24 30 7f 9d 0f 8c 23 ff ff EIP: [] xfs_file_readdir+0x157/0x1e0 SS:ESP 0068:e04cdf18 ---[ end trace 52962aefa1b8fed3 ]--- Poking around in the sources using objdump shows that it breaks at 0x207 (xfs_file_readdir begins at 0xb0) 200: 01 cf add %ecx,%edi } size = buf.used; de = (struct hack_dirent *)buf.dirent; curr_offset = de->offset /* & 0x7fffffff */; while (size > 0) { 202: 83 7c 24 28 00 cmpl $0x0,0x28(%esp) reclen = ALIGN(sizeof(struct hack_dirent) + de->namlen, sizeof(u64)); size -= reclen; de = (struct hack_dirent *)((char *)de + reclen); curr_offset = de->offset /* & 0x7fffffff */; 207: 8b 47 08 mov 0x8(%edi),%eax 20a: 8b 57 0c mov 0xc(%edi),%edx 20d: 89 44 24 2c mov %eax,0x2c(%esp) 211: 89 54 24 30 mov %edx,0x30(%esp) } size = buf.used; de = (struct hack_dirent *)buf.dirent; curr_offset = de->offset /* & 0x7fffffff */; Reproduction: No idea, the system was used for compiling various software packages. The process in question did delete a file tree of about ~100MB sources and binaries, nothing special. Please keep me in CC, thanks, Tobias From owner-xfs@oss.sgi.com Mon Feb 4 08:38:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 08:38:59 -0800 (PST) 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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14GcqLa008533 for ; Mon, 4 Feb 2008 08:38:54 -0800 X-ASG-Debug-ID: 1202143154-67da02ca0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hobbit.corpit.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0836359AA58 for ; Mon, 4 Feb 2008 08:39:14 -0800 (PST) Received: from hobbit.corpit.ru (hobbit.corpit.ru [81.13.94.6]) by cuda.sgi.com with ESMTP id Gbjdztgjb76NNLL7 for ; Mon, 04 Feb 2008 08:39:14 -0800 (PST) Received: from [192.168.1.1] (paltus.tls.msk.ru [192.168.1.1]) by hobbit.corpit.ru (Postfix) with ESMTP id CAE0A3562B; Mon, 4 Feb 2008 19:38:40 +0300 (MSK) (envelope-from mjt@tls.msk.ru) Message-ID: <47A73F90.3020307@msgid.tls.msk.ru> Date: Mon, 04 Feb 2008 19:38:40 +0300 From: Michael Tokarev User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Eric Sandeen CC: Justin Piszcz , Moshe Yudkowsky , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> In-Reply-To: <47A72061.3010800@sandeen.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hobbit.corpit.ru[81.13.94.6] X-Barracuda-Start-Time: 1202143155 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5679/Mon Feb 4 06:57:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14330 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mjt@tls.msk.ru Precedence: bulk X-list: xfs Eric Sandeen wrote: [] > http://oss.sgi.com/projects/xfs/faq.html#nulls > > and note that recent fixes have been made in this area (also noted in > the faq) > > Also - the above all assumes that when a drive says it's written/flushed > data, that it truly has. Modern write-caching drives can wreak havoc > with any journaling filesystem, so that's one good reason for a UPS. If Unfortunately an UPS does not *really* help here. Because unless it has control program which properly shuts system down on the loss of input power, and the battery really has the capacity to power the system while it's shutting down (anyone tested this? With new UPS? and after an year of use, when the battery is not new?), -- unless the UPS actually has the capacity to shutdown system, it will cut the power at an unexpected time, while the disk(s) still has dirty caches... > the drive claims to have metadata safe on disk but actually does not, > and you lose power, the data claimed safe will evaporate, there's not > much the fs can do. IO write barriers address this by forcing the drive > to flush order-critical data before continuing; xfs has them on by > default, although they are tested at mount time and if you have > something in between xfs and the disks which does not support barriers > (i.e. lvm...) then they are disabled again, with a notice in the logs. Note also that with linux software raid barriers are NOT supported. /mjt From owner-xfs@oss.sgi.com Mon Feb 4 08:45:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 08:45:09 -0800 (PST) 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 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14Gj1tc009037 for ; Mon, 4 Feb 2008 08:45:04 -0800 X-ASG-Debug-ID: 1202143523-591602bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72791D82E15 for ; Mon, 4 Feb 2008 08:45:24 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id iHef4ycfGfTWF5Fp for ; Mon, 04 Feb 2008 08:45:24 -0800 (PST) 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.8) with ESMTP id m14GjL2b007065; Mon, 4 Feb 2008 11:45:22 -0500 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 m14GjK3g018889; Mon, 4 Feb 2008 11:45:20 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id m14GjJLP029105; Mon, 4 Feb 2008 11:45:20 -0500 Message-ID: <47A7411F.2040702@sandeen.net> Date: Mon, 04 Feb 2008 10:45:19 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Moshe Yudkowsky CC: Justin Piszcz , Michael Tokarev , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> <47A72FBC.9090701@pobox.com> In-Reply-To: <47A72FBC.9090701@pobox.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1202143524 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41360 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5679/Mon Feb 4 06:57:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14331 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 Moshe Yudkowsky wrote: > So if I understand you correctly, you're stating that current the most > reliable fs in its default configuration, in terms of protection against > power-loss scenarios, is XFS? I wouldn't go that far without some real-world poweroff testing, because various fs's are probably more or less tolerant of a write-cache evaporation. I suppose it'd depend on the size of the write cache as well. -Eric From owner-xfs@oss.sgi.com Mon Feb 4 09:22:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 09:22:10 -0800 (PST) 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,J_CHICKENPOX_32 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14HLwDo010914 for ; Mon, 4 Feb 2008 09:22:01 -0800 X-ASG-Debug-ID: 1202145739-4c9f02110000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hobbit.corpit.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1D4BFD833C3 for ; Mon, 4 Feb 2008 09:22:20 -0800 (PST) Received: from hobbit.corpit.ru (hobbit.corpit.ru [81.13.94.6]) by cuda.sgi.com with ESMTP id ExRGO1IWlEY0GEO6 for ; Mon, 04 Feb 2008 09:22:20 -0800 (PST) Received: from [192.168.1.1] (paltus.tls.msk.ru [192.168.1.1]) by hobbit.corpit.ru (Postfix) with ESMTP id 285773562A; Mon, 4 Feb 2008 20:22:18 +0300 (MSK) (envelope-from mjt@tls.msk.ru) Message-ID: <47A749C9.6010503@msgid.tls.msk.ru> Date: Mon, 04 Feb 2008 20:22:17 +0300 From: Michael Tokarev User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Eric Sandeen CC: Moshe Yudkowsky , Justin Piszcz , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> <47A72FBC.9090701@pobox.com> <47A7411F.2040702@sandeen.net> In-Reply-To: <47A7411F.2040702@sandeen.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hobbit.corpit.ru[81.13.94.6] X-Barracuda-Start-Time: 1202145741 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41362 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5680/Mon Feb 4 08:24:59 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14332 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mjt@tls.msk.ru Precedence: bulk X-list: xfs Eric Sandeen wrote: > Moshe Yudkowsky wrote: >> So if I understand you correctly, you're stating that current the most >> reliable fs in its default configuration, in terms of protection against >> power-loss scenarios, is XFS? > > I wouldn't go that far without some real-world poweroff testing, because > various fs's are probably more or less tolerant of a write-cache > evaporation. I suppose it'd depend on the size of the write cache as well. I know no filesystem which is, as you say, tolerant to a write-cache evaporation. If a drive says the data is written but in fact it's not, it's a Bad Drive (tm) and it should be thrown away immediately. Fortunately, almost all modern disk drives don't lie this way. The only thing needed for the filesystem is to tell the drive to flush it's cache at the appropriate time, and actually wait for the flush to complete. Barriers (mentioned in this thread) is just another way to do so, in a somewhat more efficient way, but normal cache flush will do as well. IFF the write caching is enabled in the first place - note that with some workloads, write caching in the drive actually makes write speed worse, not better - namely, in case of massive writes. Speaking of XFS (and with ext3fs with write barriers enabled) - I'm confused here as well, and answers to my questions didn't help either. As far as I understand, XFS only use barriers, not regular cache flushes, hence without write barrier support (which is not here for linux software raid, which is explained elsewhere) it's unsafe, -- probably the same applies to ext3 with barrier support enabled. But I'm not sure I got it all correctly. /mjt From owner-xfs@oss.sgi.com Mon Feb 4 12:52:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 12:52:19 -0800 (PST) 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 cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14KqA5n025655 for ; Mon, 4 Feb 2008 12:52:13 -0800 X-ASG-Debug-ID: 1202158353-3d2602830000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 96DA059C334; Mon, 4 Feb 2008 12:52:33 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id tisqe83LI5nEehor; Mon, 04 Feb 2008 12:52:33 -0800 (PST) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JM8Io-00041l-Kv; Mon, 04 Feb 2008 20:52:30 +0000 Date: Mon, 4 Feb 2008 15:52:30 -0500 From: Christoph Hellwig To: "Josef 'Jeff' Sipek" Cc: dgc@sgi.com, xfs@oss.sgi.com, hch@infradead.org X-ASG-Orig-Subj: Re: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head Subject: Re: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head Message-ID: <20080204205230.GA14084@lst.de> References: <20080125070800.GH155407@sgi.com> <1202106488-31494-1-git-send-email-jeffpc@josefsipek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1202106488-31494-1-git-send-email-jeffpc@josefsipek.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1202158353 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41377 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5683/Mon Feb 4 10:17:58 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14333 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Mon, Feb 04, 2008 at 01:28:08AM -0500, Josef 'Jeff' Sipek wrote: > Signed-off-by: Josef 'Jeff' Sipek > --- > This patch assumes you already have Dave Chinner's patch for > xfsidbg_xlogitem and xfsidbg_xaildump is needed. > > Changes since V1: > > - Pass around a pointer to the AIL, not the struct list_head > - Make sure things compile & run with CONFIG_XFS_DEBUG Does it work with XFS_TRANS_DEBUG defined aswell? > - lip = xfs_ail_min(&(mp->m_ail.xa_ail)); > + lip = xfs_ail_min(&(mp->m_ail)); Care to remove these useless braces in all the places you touch while you're at it? From owner-xfs@oss.sgi.com Mon Feb 4 14:27:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 14:27:37 -0800 (PST) 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 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14MRTbi031449 for ; Mon, 4 Feb 2008 14:27:31 -0800 X-ASG-Debug-ID: 1202164071-319002020000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 080DAD8B483 for ; Mon, 4 Feb 2008 14:27:51 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id IOi1N7WWqHB3JmwN for ; Mon, 04 Feb 2008 14:27:51 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 2C9E01C000292; Mon, 4 Feb 2008 17:27:50 -0500 (EST) Date: Mon, 4 Feb 2008 17:27:50 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Michael Tokarev cc: Eric Sandeen , Moshe Yudkowsky , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) Subject: Re: RAID needs more to survive a power hit, different /boot layout for example (was Re: draft howto on making raids for surviving a disk crash) In-Reply-To: <47A73F90.3020307@msgid.tls.msk.ru> Message-ID: References: <47A612BE.5050707@pobox.com> <47A623EE.4050305@msgid.tls.msk.ru> <47A62A17.70101@pobox.com> <47A6DA81.3030008@msgid.tls.msk.ru> <47A6EFCF.9080906@pobox.com> <47A7188A.4070005@msgid.tls.msk.ru> <47A72061.3010800@sandeen.net> <47A73F90.3020307@msgid.tls.msk.ru> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1202164072 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5685/Mon Feb 4 12:29:32 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14334 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 Mon, 4 Feb 2008, Michael Tokarev wrote: > Eric Sandeen wrote: > [] >> http://oss.sgi.com/projects/xfs/faq.html#nulls >> >> and note that recent fixes have been made in this area (also noted in >> the faq) >> >> Also - the above all assumes that when a drive says it's written/flushed >> data, that it truly has. Modern write-caching drives can wreak havoc >> with any journaling filesystem, so that's one good reason for a UPS. If > > Unfortunately an UPS does not *really* help here. Because unless > it has control program which properly shuts system down on the loss > of input power, and the battery really has the capacity to power the > system while it's shutting down (anyone tested this? With new UPS? > and after an year of use, when the battery is not new?), -- unless > the UPS actually has the capacity to shutdown system, it will cut > the power at an unexpected time, while the disk(s) still has dirty > caches... You use nut and a large enough UPS to handle the load of the system, it shuts the machine down just fine. > >> the drive claims to have metadata safe on disk but actually does not, >> and you lose power, the data claimed safe will evaporate, there's not >> much the fs can do. IO write barriers address this by forcing the drive >> to flush order-critical data before continuing; xfs has them on by >> default, although they are tested at mount time and if you have >> something in between xfs and the disks which does not support barriers >> (i.e. lvm...) then they are disabled again, with a notice in the logs. > > Note also that with linux software raid barriers are NOT supported. > > /mjt > > From owner-xfs@oss.sgi.com Mon Feb 4 15:39:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 15:39:36 -0800 (PST) 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 cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m14NdVgI002711 for ; Mon, 4 Feb 2008 15:39:32 -0800 X-ASG-Debug-ID: 1202168393-122d01a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0A08C7C8F61; Mon, 4 Feb 2008 15:39:53 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id bq7rR1twp4VZgJ11; Mon, 04 Feb 2008 15:39:53 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m14NdidM025995; Mon, 4 Feb 2008 18:39:44 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id 245701C00DD2; Mon, 4 Feb 2008 18:39:46 -0500 (EST) Date: Mon, 4 Feb 2008 18:39:46 -0500 From: "Josef 'Jeff' Sipek" To: Christoph Hellwig Cc: dgc@sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head Subject: Re: [PATCH 1/1] XFS: Replace custom AIL linked-list code with struct list_head Message-ID: <20080204233946.GA27110@josefsipek.net> References: <20080125070800.GH155407@sgi.com> <1202106488-31494-1-git-send-email-jeffpc@josefsipek.net> <20080204205230.GA14084@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080204205230.GA14084@lst.de> User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1202168394 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.41386 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5687/Mon Feb 4 14:54:45 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14335 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Mon, Feb 04, 2008 at 03:52:30PM -0500, Christoph Hellwig wrote: > On Mon, Feb 04, 2008 at 01:28:08AM -0500, Josef 'Jeff' Sipek wrote: > > Signed-off-by: Josef 'Jeff' Sipek > > --- > > This patch assumes you already have Dave Chinner's patch for > > xfsidbg_xlogitem and xfsidbg_xaildump is needed. > > > > Changes since V1: > > > > - Pass around a pointer to the AIL, not the struct list_head > > - Make sure things compile & run with CONFIG_XFS_DEBUG > > Does it work with XFS_TRANS_DEBUG defined aswell? With XFS_TRANS_DEBUG on, other places in XFS don't compile, but this does and works (xfsqa ran fine). > > - lip = xfs_ail_min(&(mp->m_ail.xa_ail)); > > + lip = xfs_ail_min(&(mp->m_ail)); > > Care to remove these useless braces in all the places you touch while you're at it? Will do. Josef 'Jeff' Sipek. -- The box said "Windows XP or better required". So I installed Linux. From owner-xfs@oss.sgi.com Mon Feb 4 16:31:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 16:31:07 -0800 (PST) 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,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.11/SuSE Linux 0.7) with SMTP id m150UvZX009861 for ; Mon, 4 Feb 2008 16:31:01 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16545; Tue, 5 Feb 2008 11:31:14 +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 m150VCLF43120074; Tue, 5 Feb 2008 11:31:13 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m150VAjP51208715; Tue, 5 Feb 2008 11:31:10 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 5 Feb 2008 11:31:10 +1100 From: David Chinner To: Andrea Perotti Cc: xfs-oss Subject: Re: Some kind of problems with xfs and 2.6.24 kernel Message-ID: <20080205003109.GI155407@sgi.com> References: <39932.84.221.232.4.1202164725.squirrel@manage.unbit.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39932.84.221.232.4.1202164725.squirrel@manage.unbit.it> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5687/Mon Feb 4 14:54:45 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14336 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 report problems direct to xfs@oss.sgi.com, not me ;)] On Mon, Feb 04, 2008 at 11:38:45PM +0100, Andrea Perotti wrote: > Hi David > I've found you address in a linux kernel mailing list and I guess > you are the guy I was looking for. > > I'm gentoo linux user and I'm running on my laptop the 2.6.24 kernel with > the standard gentoo patchset and I have both / and /home on XFS. > > During normal usage I got a couple of time the kernel error you can find > attached. > > Both of them occurred when I was connected with the imap server (dovecot) > present on that machine, accessing to the same account (imap was reading > into /home/$myuser/.maildir/... ) and I get aware that something was gone > because I cannot access to one of my dir inside my mailbox. > > I hope these information could be usefull to you. If you need any extra > info, like the option I used to create and mount FS or anything else, just > ask me. > > Jan 31 15:12:09 stakanov_II BUG: unable to handle kernel paging request at virtual address f8000000 > Jan 31 15:12:09 stakanov_II printing eip: c022dd78 *pde = 00000000 > Jan 31 15:12:09 stakanov_II Oops: 0000 [#1] PREEMPT > Jan 31 15:12:09 stakanov_II Modules linked in: b43 yenta_socket rsrc_nonstatic ssb > Jan 31 15:12:09 stakanov_II > Jan 31 15:12:09 stakanov_II Pid: 19390, comm: imap Not tainted (2.6.24-gentoo-metallica #4) > Jan 31 15:12:09 stakanov_II EIP: 0060:[] EFLAGS: 00010282 CPU: 0 > Jan 31 15:12:09 stakanov_II EIP is at xfs_file_readdir+0xf2/0x1aa > Jan 31 15:12:09 stakanov_II EAX: 00000000 EBX: 000001a4 ECX: 00000058 EDX: 00000000 > Jan 31 15:12:09 stakanov_II ESI: 00000000 EDI: f7fffff8 EBP: f766d780 ESP: e05bbf1c > Jan 31 15:12:09 stakanov_II DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 > Jan 31 15:12:09 stakanov_II Process imap (pid: 19390, ti=e05ba000 task=f7310f60 task.ti=e05ba000) > Jan 31 15:12:09 stakanov_II Stack: 000001a4 00000000 0f49408a 00000000 00000000 c0159838 e05bbf94 e1de1a80 > Jan 31 15:12:09 stakanov_II 00000000 00000000 00000000 000001a4 00000000 f7fff000 00001000 00000ff8 > Jan 31 15:12:09 stakanov_II 000001ad 00000000 c03ae120 f766d780 fffffffe e1de27e8 c0159a00 e05bbf94 > Jan 31 15:12:09 stakanov_II Call Trace: > Jan 31 15:12:09 stakanov_II [] filldir64+0x0/0xc5 > Jan 31 15:12:09 stakanov_II [] vfs_readdir+0x4a/0x74 > Jan 31 15:12:09 stakanov_II [] filldir64+0x0/0xc5 > Jan 31 15:12:09 stakanov_II [] sys_getdents64+0x63/0xa5 > Jan 31 15:12:09 stakanov_II [] sysenter_past_esp+0x5f/0x85 > Jan 31 15:12:09 stakanov_II ======================= > Jan 31 15:12:09 stakanov_II Code: 04 81 e3 ff ff ff 7f 89 1c 24 ff 54 24 14 85 > c0 0f 85 a9 00 00 00 8b 4f 10 31 d2 83 c1 1f 83 e1 f8 29 4c 24 24 19 54 24 28 > 01 cf <8b> 47 08 8b 57 0c 83 7c 24 28 00 89 44 24 2c 89 54 24 30 7f 99 > Jan 31 15:12:09 stakanov_II EIP: [] xfs_file_readdir+0xf2/0x1aa SS:ESP 0068:e05bbf1c > Jan 31 15:12:09 stakanov_II ---[ end trace 96802517b18c4092 ]--- > Feb 4 10:49:18 stakanov_II BUG: unable to handle kernel paging request at virtual address f8000000 > Feb 4 10:49:18 stakanov_II printing eip: c022dd78 *pde = 00000000 > Feb 4 10:49:18 stakanov_II Oops: 0000 [#1] PREEMPT > Feb 4 10:49:18 stakanov_II Modules linked in: yenta_socket rsrc_nonstatic snd_hda_intel > Feb 4 10:49:18 stakanov_II > Feb 4 10:49:18 stakanov_II Pid: 6057, comm: imap Not tainted (2.6.24-gentoo-metallica #9) > Feb 4 10:49:18 stakanov_II EIP: 0060:[] EFLAGS: 00010282 CPU: 0 > Feb 4 10:49:18 stakanov_II EIP is at xfs_file_readdir+0xf2/0x1aa > Feb 4 10:49:18 stakanov_II EAX: 00000000 EBX: 000001a9 ECX: 00000058 EDX: 00000000 > Feb 4 10:49:18 stakanov_II ESI: 00000000 EDI: f7fffff8 EBP: ef5a2880 ESP: ef40bf1c > Feb 4 10:49:18 stakanov_II DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 > Feb 4 10:49:18 stakanov_II Process imap (pid: 6057, ti=ef40a000 task=ef626520 task.ti=ef40a000) > Feb 4 10:49:18 stakanov_II Stack: 000001a9 00000000 132fea33 00000000 00000000 c0159838 ef40bf94 ef98bc00 > Feb 4 10:49:18 stakanov_II 00000000 00000000 00000000 000001a9 00000000 f7fff000 00001000 00000ff8 > Feb 4 10:49:18 stakanov_II 000001b2 00000000 c03a6120 ef5a2880 fffffffe ef98ae28 c0159a00 ef40bf94 > Feb 4 10:49:18 stakanov_II Call Trace: > Feb 4 10:49:18 stakanov_II [] filldir64+0x0/0xc5 > Feb 4 10:49:18 stakanov_II [] vfs_readdir+0x4a/0x74 > Feb 4 10:49:18 stakanov_II [] filldir64+0x0/0xc5 > Feb 4 10:49:18 stakanov_II [] sys_getdents64+0x63/0xa5 > Feb 4 10:49:18 stakanov_II [] sysenter_past_esp+0x5f/0x85 > Feb 4 10:49:18 stakanov_II [] sta_info_release+0x0/0x5b > Feb 4 10:49:18 stakanov_II ======================= > Feb 4 10:49:18 stakanov_II Code: 04 81 e3 ff ff ff 7f 89 1c 24 ff 54 24 14 85 > c0 0f 85 a9 00 00 00 8b 4f 10 31 d2 83 c1 1f 83 e1 f8 29 4c 24 24 19 54 24 28 > 01 cf <8b> 47 08 8b 57 0c 83 7c 24 28 00 89 44 24 2c 89 54 24 30 7f 99 > Feb 4 10:49:18 stakanov_II EIP: [] xfs_file_readdir+0xf2/0x1aa SS:ESP 0068:ef40bf1c > Feb 4 10:49:18 stakanov_II ---[ end trace d899adf5158e5245 ]--- Yeah, this is the third report of a readdir problem on 2.6.24. The others are here: http://oss.sgi.com/archives/xfs/2008-02/msg00019.html http://oss.sgi.com/archives/xfs/2008-02/msg00007.html I'm pulling down a metadump image of one of the problem filesystems right now and I'm going to try to reproduce it locally. When we find the problem, we'll push the fix into the stable branch. more details in a while. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Feb 4 21:24:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Feb 2008 21:24:37 -0800 (PST) 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.11/SuSE Linux 0.7) with SMTP id m155OB2F027535 for ; Mon, 4 Feb 2008 21:24:14 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23013; Tue, 5 Feb 2008 16:24:24 +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 m155OMLF51259785; Tue, 5 Feb 2008 16:24:23 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m155OJ8Q51324493; Tue, 5 Feb 2008 16:24:19 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 5 Feb 2008 16:24:18 +1100 From: David Chinner To: Sven Geggus Cc: xfs@oss.sgi.com, Tobias Ulmer , Andrea Perotti Subject: [PATCH] Possible fix for 2.6.24 xfs_file_readdir crash Message-ID: <20080205052418.GU155259@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/5691/Mon Feb 4 18:12:57 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14337 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 Sven, Tomas, Andrea: Can you try the patch attached below to see if it fixes the xfs_file_readdir() oops you are seeing and let me know if it fixes the problem? It looks like we're deferencing a pointer beyond the end of a buffer if the buffer is filled exactly. This bug does not crash ia64 (even with memory poisoning enabled), which is why the targeted corner case testing I did a while back did not pick this up when fixing a similar bug a month ago. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- Fix yet another corner case oops in xfs_file_readdir(). Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_file.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2008-01-16 16:24:01.000000000 +11