From SRS0+2062eb3e412fa8c358ca+1988+infradead.org+hch@bombadil.srs.infradead.org Sun Feb  1 02:13:06 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n118D5Pg165019
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 02:13:06 -0600
X-ASG-Debug-ID: 1233475945-164401aa0000-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 F300218A0BC4
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 00:12:25 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Q0AqCm3TGbDQHHHp for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 00:12:25 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LTXRI-00028Z-Vl; Sun, 01 Feb 2009 08:12:24 +0000
Date: Sun, 1 Feb 2009 03:12:24 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com, Nick Piggin <nickpiggin@yahoo.com.au>
X-ASG-Orig-Subj: reproducible xfs/vmap oops
Subject: reproducible xfs/vmap oops
Message-ID: <20090201081224.GA22398@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233475945
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

When running xfsqa on the current xfs development tree (sometimes two
runs are needed to trigger it) I get the following oops.  This seems to
have been introduced by the last mainling merge (with
5ee810072175042775e39bdd3eaaa68884c27805), but I'd need to bisect it to
make sure my gut feeling is right.

[ 3262.460241] XFS mounting filesystem vde
[ 3262.474253] ------------[ cut here ]------------
[ 3262.476024] kernel BUG at mm/vmalloc.c:294!
[ 3262.476024] invalid opcode: 0000 [#1] SMP 
[ 3262.476024] last sysfs file: /sys/class/net/lo/operstate
[ 3262.476024] Modules linked in:
[ 3262.476024] 
[ 3262.476024] Pid: 31907, comm: mount Not tainted (2.6.29-rc2-xfs #30) 
[ 3262.476024] EIP: 0060:[<c01b4b28>] EFLAGS: 00010207 CPU: 0
[ 3262.476024] EIP is at __insert_vmap_area+0x88/0xb0
[ 3262.476024] EAX: 00101000 EBX: ffd01000 ECX: 00000000 EDX: f5f25df4
[ 3262.476024] ESI: d2180340 EDI: d2180340 EBP: f32f5bcc ESP: f32f5bc4
[ 3262.476024]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 3262.476024] Process mount (pid: 31907, ti=f32f4000 task=de55e2b0
task.ti=f32f4000)
[ 3262.476024] Stack:
[ 3262.476024]  ffd01000 f874e000 f32f5c10 c01b5581 00000000 000200d0
00001000 f8b4e000
[ 3262.476024]  00400000 d2180340 00000000 d2180340 00000fff fffff000
c0a69e80 c0a69e80
[ 3262.476024]  f685ca98 00000400 00000400 f32f5c58 c01b5972 fff4e000
ffffffff 000000d0
[ 3262.476024] Call Trace:
[ 3262.476024]  [<c01b5581>] ? alloc_vmap_area+0x1b1/0x220
[ 3262.476024]  [<c01b5972>] ? vm_map_ram+0x382/0x3a0
[ 3262.476024]  [<c0450609>] ? kmem_alloc+0x59/0xf0
[ 3262.476024]  [<c04538a9>] ? _xfs_buf_map_pages+0x89/0xc0
[ 3262.476024]  [<c0453a17>] ? xfs_buf_get_noaddr+0x137/0x170
[ 3262.476024]  [<c043f52a>] ? xlog_get_bp+0x4a/0x80
[ 3262.476024]  [<c044045b>] ? xlog_write_log_records+0x4b/0x260
[ 3262.476024]  [<c079ea52>] ? _spin_unlock_irq+0x22/0x30
[ 3262.476024]  [<c0440712>] ? xlog_clear_stale_blocks+0xa2/0x180
[ 3262.476024]  [<c04419bc>] ? xlog_find_tail+0x46c/0x4f0
[ 3262.476024]  [<c0441a54>] ? xlog_recover+0x14/0xa0
[ 3262.476024]  [<c043a4b0>] ? xfs_log_mount+0xa0/0x180
[ 3262.476024]  [<c0444bd8>] ? xfs_mountfs+0x348/0x6d0
[ 3262.476024]  [<c05a8bb9>] ? __debug_object_init+0x229/0x340
[ 3262.476024]  [<c05a8d17>] ? debug_object_init+0x17/0x20
[ 3262.476024]  [<c0156480>] ? init_timer+0x10/0x30
[ 3262.476024]  [<c0445694>] ? xfs_mru_cache_create+0x114/0x150
[ 3262.476024]  [<c045ba0f>] ? xfs_fs_fill_super+0x1cf/0x310
[ 3262.476024]  [<c01c6d53>] ? get_sb_bdev+0x123/0x150
[ 3262.476024]  [<c01dace7>] ? alloc_vfsmnt+0x77/0x100
[ 3262.476024]  [<c01a7c51>] ? kstrdup+0x31/0x60
[ 3262.476024]  [<c0459b71>] ? xfs_fs_get_sb+0x21/0x30
[ 3262.476024]  [<c045b840>] ? xfs_fs_fill_super+0x0/0x310
[ 3262.476024]  [<c01c5a5a>] ? vfs_kern_mount+0x3a/0xa0
[ 3262.476024]  [<c01c5b19>] ? do_kern_mount+0x39/0xe0
[ 3262.476024]  [<c01dba2b>] ? do_mount+0x3ab/0x780
[ 3262.476024]  [<c05a7cf1>] ? _raw_spin_lock+0x41/0x120
[ 3262.476024]  [<c01da00c>] ? copy_mount_options+0x3c/0x130
[ 3262.476024]  [<c01dbe89>] ? sys_mount+0x89/0xc0
[ 3262.476024]  [<c0120dfe>] ? syscall_call+0x7/0xb
[ 3262.476024]  [<c0120000>] ? restore_sigcontext+0x140/0x150

From bharrosh@panasas.com Sun Feb  1 03:49:08 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n119n7Uo169793
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 03:49:08 -0600
X-ASG-Debug-ID: 1233481705-048d01060000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 36C9D189F057; Sun,  1 Feb 2009 01:48:25 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id 8edLwbflR8VxKslx; Sun, 01 Feb 2009 01:48:25 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 01:48:21 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 04:48:19 -0500
Message-ID: <49856FE6.8020601@panasas.com>
Date: Sun, 01 Feb 2009 11:48:22 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Arnd Bergmann <arnd@arndb.de>
CC: Andrew Morton <akpm@linux-foundation.org>, Ankit Jain <me@ankitjain.org>,
        viro@zeniv.linux.org.uk, hch@infradead.org,
        linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
        joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
        linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de> <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de>
In-Reply-To: <200901310248.42820.arnd@arndb.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2009 09:48:19.0811 (UTC) FILETIME=[36C93330:01C98452]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233481707
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16698
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Arnd Bergmann wrote:
> On Saturday 31 January 2009, Andrew Morton wrote:
>> Is this written in a standard somewhere?  Is it guaranteed?
> 
> Alignment is defined in the architecture psABI documents. 
> Unfortunately, many of them were written before the 'long long'
> type became part of the C standard, so it's not strictly guaranteed.
> AFAICT, the alignment of __u64 on x86 is the same as the alignment
> of 'double' by convention.
> 
> However, the problem is well-understood: x86 is the only one
> that has a problem in 32/64 bit compat mode. m68k has similar
> issues with 16/32 bit integers, but those don't apply here.
> 
>> If some (perhaps non-gcc) compiler were to lay this out differently
>> (perhaps with suitable command-line options) then that's liveable
>> with - as long as the kernel never changes the layout.  Of course
>> it would be better to avoid this if poss.
> 
> If a compiler was using irregular structure alignment, all sorts of
> library interfaces would break. The kernel ABI is only a small part
> of the problem then.
> 
>> The other potential issue with a structure like this is that there's a
>> risk that it will lead us to copy four bytes of uninitialised kernel
>> memory out to userspace.
>>
>> IOW, it seems a generally bad idea to rely upon compiler-added padding
>> for this sort of thing.
> 
> Agreed in general, but the whole point of this particular patch was to
> provide compatibility with an interface that has been part of XFS for
> many years.
> Linux already has a better interface for new users (sys_fallocate), so
> changing the patch would not be helpful and not provide any advantage.
> 
> There is also no leak of uninitialized data here, because this structure
> is only read, never written.
> 
> 	Arnd <><
Arnd Bergmann wrote:
> +struct space_resv {
> +	__s16		l_type;
> +	__s16		l_whence;
> +	__s64		l_start;
> +	__s64		l_len;		/* len == 0 means until end of file */
> +	__s32		l_sysid;
> +	__u32		l_pid;
> +	__s32		l_pad[4];	/* reserve area			    */
> +};

What about telling the compiler exactly what you said above, just
to be sure we all mean the same thing. (And as documentation for new
comers):

+struct space_resv_64 {
+	__s16		l_type;
+	__s16		l_whence;
+	__u32		reserved;
+	__s64		l_start;
+	__s64		l_len;		/* len == 0 means until end of file */
+	__s32		l_sysid;
+	__u32		l_pid;
+	__s32		l_pad[4];	/* reserve area			    */
+} __packed;

And define another one for x86_32

Boaz

From geert@linux-m68k.org Sun Feb  1 04:06:06 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11A65cr171285
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 04:06:06 -0600
X-ASG-Debug-ID: 1233482723-65af038e0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from harold.telenet-ops.be (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 33613D5188; Sun,  1 Feb 2009 02:05:23 -0800 (PST)
Received: from harold.telenet-ops.be (harold.telenet-ops.be [195.130.133.65]) by cuda.sgi.com with ESMTP id nh0MxWU1ph4MdHSn; Sun, 01 Feb 2009 02:05:23 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by harold.telenet-ops.be (Postfix) with SMTP id 14BE030017;
	Sun,  1 Feb 2009 11:05:23 +0100 (CET)
Received: from anakin.of.borg (d54C15368.access.telenet.be [84.193.83.104])
	by harold.telenet-ops.be (Postfix) with ESMTP id 216073006E;
	Sun,  1 Feb 2009 11:05:19 +0100 (CET)
Received: from anakin.of.borg (localhost [127.0.0.1])
	by anakin.of.borg (8.14.3/8.14.3/Debian-5) with ESMTP id n11A5JGv030148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 1 Feb 2009 11:05:19 +0100
Received: from localhost (geert@localhost)
	by anakin.of.borg (8.14.3/8.14.3/Submit) with ESMTP id n11A5HS0030145;
	Sun, 1 Feb 2009 11:05:18 +0100
X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs
Date: Sun, 1 Feb 2009 11:05:17 +0100 (CET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sender: geert@linux-m68k.org
To: Boaz Harrosh <bharrosh@panasas.com>
cc: Arnd Bergmann <arnd@arndb.de>, Andrew Morton <akpm@linux-foundation.org>,
        Ankit Jain <me@ankitjain.org>, viro@zeniv.linux.org.uk,
        hch@infradead.org, linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
        joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
        linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
In-Reply-To: <49856FE6.8020601@panasas.com>
Message-ID: <Pine.LNX.4.64.0902011104320.20875@anakin>
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de>
 <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de>
 <49856FE6.8020601@panasas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Barracuda-Connect: harold.telenet-ops.be[195.130.133.65]
X-Barracuda-Start-Time: 1233482725
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16700
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sun, 1 Feb 2009, Boaz Harrosh wrote:
> Arnd Bergmann wrote:
> > On Saturday 31 January 2009, Andrew Morton wrote:
> >> Is this written in a standard somewhere?  Is it guaranteed?
> > 
> > Alignment is defined in the architecture psABI documents. 
> > Unfortunately, many of them were written before the 'long long'
> > type became part of the C standard, so it's not strictly guaranteed.
> > AFAICT, the alignment of __u64 on x86 is the same as the alignment
> > of 'double' by convention.
> > 
> > However, the problem is well-understood: x86 is the only one
> > that has a problem in 32/64 bit compat mode. m68k has similar
> > issues with 16/32 bit integers, but those don't apply here.
> > 
> >> If some (perhaps non-gcc) compiler were to lay this out differently
> >> (perhaps with suitable command-line options) then that's liveable
> >> with - as long as the kernel never changes the layout.  Of course
> >> it would be better to avoid this if poss.
> > 
> > If a compiler was using irregular structure alignment, all sorts of
> > library interfaces would break. The kernel ABI is only a small part
> > of the problem then.
> > 
> >> The other potential issue with a structure like this is that there's a
> >> risk that it will lead us to copy four bytes of uninitialised kernel
> >> memory out to userspace.
> >>
> >> IOW, it seems a generally bad idea to rely upon compiler-added padding
> >> for this sort of thing.
> > 
> > Agreed in general, but the whole point of this particular patch was to
> > provide compatibility with an interface that has been part of XFS for
> > many years.
> > Linux already has a better interface for new users (sys_fallocate), so
> > changing the patch would not be helpful and not provide any advantage.
> > 
> > There is also no leak of uninitialized data here, because this structure
> > is only read, never written.
> > 
> > 	Arnd <><
> Arnd Bergmann wrote:
> > +struct space_resv {
> > +	__s16		l_type;
> > +	__s16		l_whence;
> > +	__s64		l_start;
> > +	__s64		l_len;		/* len == 0 means until end of file */
> > +	__s32		l_sysid;
> > +	__u32		l_pid;
> > +	__s32		l_pad[4];	/* reserve area			    */
> > +};
> 
> What about telling the compiler exactly what you said above, just
> to be sure we all mean the same thing. (And as documentation for new
> comers):
> 
> +struct space_resv_64 {
> +	__s16		l_type;
> +	__s16		l_whence;
> +	__u32		reserved;
> +	__s64		l_start;
> +	__s64		l_len;		/* len == 0 means until end of file */
> +	__s32		l_sysid;
> +	__u32		l_pid;
> +	__s32		l_pad[4];	/* reserve area			    */
> +} __packed;

Because the compiler will assume all fields are always unaligned and will use very
suboptimal code to access them?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From bharrosh@panasas.com Sun Feb  1 04:40:21 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_25
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11AeLiU172999
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 04:40:21 -0600
X-ASG-Debug-ID: 1233484779-048e03030000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id DFD2D18A0EA1; Sun,  1 Feb 2009 02:39:39 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id seVQlpBaXz4prvjo; Sun, 01 Feb 2009 02:39:39 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 02:39:39 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 05:39:37 -0500
Message-ID: <49857BEB.30404@panasas.com>
Date: Sun, 01 Feb 2009 12:39:39 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Arnd Bergmann <arnd@arndb.de>, Andrew Morton <akpm@linux-foundation.org>,
        Ankit Jain <me@ankitjain.org>, viro@zeniv.linux.org.uk,
        hch@infradead.org, linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
        joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
        linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de> <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com> <Pine.LNX.4.64.0902011104320.20875@anakin>
In-Reply-To: <Pine.LNX.4.64.0902011104320.20875@anakin>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2009 10:39:37.0283 (UTC) FILETIME=[611A2930:01C98459]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233484780
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16702
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Geert Uytterhoeven wrote:
> On Sun, 1 Feb 2009, Boaz Harrosh wrote:
>> Arnd Bergmann wrote:
>>> On Saturday 31 January 2009, Andrew Morton wrote:
>>>> Is this written in a standard somewhere?  Is it guaranteed?
>>> Alignment is defined in the architecture psABI documents. 
>>> Unfortunately, many of them were written before the 'long long'
>>> type became part of the C standard, so it's not strictly guaranteed.
>>> AFAICT, the alignment of __u64 on x86 is the same as the alignment
>>> of 'double' by convention.
>>>
>>> However, the problem is well-understood: x86 is the only one
>>> that has a problem in 32/64 bit compat mode. m68k has similar
>>> issues with 16/32 bit integers, but those don't apply here.
>>>
>>>> If some (perhaps non-gcc) compiler were to lay this out differently
>>>> (perhaps with suitable command-line options) then that's liveable
>>>> with - as long as the kernel never changes the layout.  Of course
>>>> it would be better to avoid this if poss.
>>> If a compiler was using irregular structure alignment, all sorts of
>>> library interfaces would break. The kernel ABI is only a small part
>>> of the problem then.
>>>
>>>> The other potential issue with a structure like this is that there's a
>>>> risk that it will lead us to copy four bytes of uninitialised kernel
>>>> memory out to userspace.
>>>>
>>>> IOW, it seems a generally bad idea to rely upon compiler-added padding
>>>> for this sort of thing.
>>> Agreed in general, but the whole point of this particular patch was to
>>> provide compatibility with an interface that has been part of XFS for
>>> many years.
>>> Linux already has a better interface for new users (sys_fallocate), so
>>> changing the patch would not be helpful and not provide any advantage.
>>>
>>> There is also no leak of uninitialized data here, because this structure
>>> is only read, never written.
>>>
>>> 	Arnd <><
>> Arnd Bergmann wrote:
>>> +struct space_resv {
>>> +	__s16		l_type;
>>> +	__s16		l_whence;
>>> +	__s64		l_start;
>>> +	__s64		l_len;		/* len == 0 means until end of file */
>>> +	__s32		l_sysid;
>>> +	__u32		l_pid;
>>> +	__s32		l_pad[4];	/* reserve area			    */
>>> +};
>> What about telling the compiler exactly what you said above, just
>> to be sure we all mean the same thing. (And as documentation for new
>> comers):
>>
>> +struct space_resv_64 {
>> +	__s16		l_type;
>> +	__s16		l_whence;
>> +	__u32		reserved;
>> +	__s64		l_start;
>> +	__s64		l_len;		/* len == 0 means until end of file */
>> +	__s32		l_sysid;
>> +	__u32		l_pid;
>> +	__s32		l_pad[4];	/* reserve area			    */
>> +} __packed;
> 
> Because the compiler will assume all fields are always unaligned and will use very
> suboptimal code to access them?
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 

This discussion comes up every once in a while. I'm using an old FC7 compiler
(gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)) And tests show that when the layout
of a structure is exactly the same the "__packed" on structure declarations does
nothing. It only starts to affect when there are real differences in alignment.
Also tests with gcc 3.4.x showed the same effect.

On previous discussions no one could come forward and say what compiler version
breaks when __packed is applied on structure definition. I'm afraid your statement
above is a myth.

Boaz

From geert@linux-m68k.org Sun Feb  1 04:59:47 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11Axljv174553
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 04:59:47 -0600
X-ASG-Debug-ID: 1233485946-6ab001160000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from harold.telenet-ops.be (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 3C902D54A9; Sun,  1 Feb 2009 02:59:06 -0800 (PST)
Received: from harold.telenet-ops.be (harold.telenet-ops.be [195.130.133.65]) by cuda.sgi.com with ESMTP id EiIsHFsZSXrJBAFc; Sun, 01 Feb 2009 02:59:06 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by harold.telenet-ops.be (Postfix) with SMTP id ED8C130066;
	Sun,  1 Feb 2009 11:59:05 +0100 (CET)
Received: from anakin.of.borg (d54C15368.access.telenet.be [84.193.83.104])
	by harold.telenet-ops.be (Postfix) with ESMTP id CFE623005E;
	Sun,  1 Feb 2009 11:59:05 +0100 (CET)
Received: from anakin.of.borg (localhost [127.0.0.1])
	by anakin.of.borg (8.14.3/8.14.3/Debian-5) with ESMTP id n11Ax5Xk017685
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 1 Feb 2009 11:59:05 +0100
Received: from localhost (geert@localhost)
	by anakin.of.borg (8.14.3/8.14.3/Submit) with ESMTP id n11Ax5UZ017682;
	Sun, 1 Feb 2009 11:59:05 +0100
X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs
Date: Sun, 1 Feb 2009 11:59:04 +0100 (CET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sender: geert@linux-m68k.org
To: Boaz Harrosh <bharrosh@panasas.com>
cc: Arnd Bergmann <arnd@arndb.de>, Andrew Morton <akpm@linux-foundation.org>,
        Ankit Jain <me@ankitjain.org>, viro@zeniv.linux.org.uk,
        hch@infradead.org, linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
        joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
        linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
In-Reply-To: <49857BEB.30404@panasas.com>
Message-ID: <Pine.LNX.4.64.0902011151180.20875@anakin>
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de>
 <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de>
 <49856FE6.8020601@panasas.com> <Pine.LNX.4.64.0902011104320.20875@anakin>
 <49857BEB.30404@panasas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Barracuda-Connect: harold.telenet-ops.be[195.130.133.65]
X-Barracuda-Start-Time: 1233485947
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16704
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sun, 1 Feb 2009, Boaz Harrosh wrote:
> Geert Uytterhoeven wrote:
> > On Sun, 1 Feb 2009, Boaz Harrosh wrote:
> >> Arnd Bergmann wrote:
> >>> +struct space_resv {
> >>> +	__s16		l_type;
> >>> +	__s16		l_whence;
> >>> +	__s64		l_start;
> >>> +	__s64		l_len;		/* len == 0 means until end of file */
> >>> +	__s32		l_sysid;
> >>> +	__u32		l_pid;
> >>> +	__s32		l_pad[4];	/* reserve area			    */
> >>> +};
> >> What about telling the compiler exactly what you said above, just
> >> to be sure we all mean the same thing. (And as documentation for new
> >> comers):
> >>
> >> +struct space_resv_64 {
> >> +	__s16		l_type;
> >> +	__s16		l_whence;
> >> +	__u32		reserved;
> >> +	__s64		l_start;
> >> +	__s64		l_len;		/* len == 0 means until end of file */
> >> +	__s32		l_sysid;
> >> +	__u32		l_pid;
> >> +	__s32		l_pad[4];	/* reserve area			    */
> >> +} __packed;
> > 
> > Because the compiler will assume all fields are always unaligned and will use very
> > suboptimal code to access them?
> 
> This discussion comes up every once in a while. I'm using an old FC7 compiler
> (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)) And tests show that when the layout
> of a structure is exactly the same the "__packed" on structure declarations does
> nothing. It only starts to affect when there are real differences in alignment.
> Also tests with gcc 3.4.x showed the same effect.
> 
> On previous discussions no one could come forward and say what compiler version
> breaks when __packed is applied on structure definition. I'm afraid your statement
> above is a myth.

FC7, targeting ia32? Sure, ia32 has no alignment restrictions.
Try e.g. MIPS.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From bharrosh@panasas.com Sun Feb  1 06:34:30 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_25
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11CYUn9180665
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 06:34:30 -0600
X-ASG-Debug-ID: 1233491628-70a501700000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id F1E6B18A1073; Sun,  1 Feb 2009 04:33:48 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id BdfiRjSZV3LsC0nr; Sun, 01 Feb 2009 04:33:48 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 04:32:47 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 07:32:45 -0500
Message-ID: <4985966D.8040402@panasas.com>
Date: Sun, 01 Feb 2009 14:32:45 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Arnd Bergmann <arnd@arndb.de>, Andrew Morton <akpm@linux-foundation.org>,
        Ankit Jain <me@ankitjain.org>, viro@zeniv.linux.org.uk,
        hch@infradead.org, linux-fsdevel@vger.kernel.org, mfasheh@suse.com,
        joel.becker@oracle.com, ocfs2-devel@oss.oracle.com,
        linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
Subject: Re: [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility
 with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de> <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com> <Pine.LNX.4.64.0902011104320.20875@anakin> <49857BEB.30404@panasas.com> <Pine.LNX.4.64.0902011151180.20875@anakin>
In-Reply-To: <Pine.LNX.4.64.0902011151180.20875@anakin>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2009 12:32:46.0061 (UTC) FILETIME=[2F8779D0:01C98469]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233491630
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0201
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16709
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Geert Uytterhoeven wrote:
> On Sun, 1 Feb 2009, Boaz Harrosh wrote:
>> Geert Uytterhoeven wrote:
>>> On Sun, 1 Feb 2009, Boaz Harrosh wrote:
>>>> Arnd Bergmann wrote:
>>>>> +struct space_resv {
>>>>> +	__s16		l_type;
>>>>> +	__s16		l_whence;
>>>>> +	__s64		l_start;
>>>>> +	__s64		l_len;		/* len == 0 means until end of file */
>>>>> +	__s32		l_sysid;
>>>>> +	__u32		l_pid;
>>>>> +	__s32		l_pad[4];	/* reserve area			    */
>>>>> +};
>>>> What about telling the compiler exactly what you said above, just
>>>> to be sure we all mean the same thing. (And as documentation for new
>>>> comers):
>>>>
>>>> +struct space_resv_64 {
>>>> +	__s16		l_type;
>>>> +	__s16		l_whence;
>>>> +	__u32		reserved;
>>>> +	__s64		l_start;
>>>> +	__s64		l_len;		/* len == 0 means until end of file */
>>>> +	__s32		l_sysid;
>>>> +	__u32		l_pid;
>>>> +	__s32		l_pad[4];	/* reserve area			    */
>>>> +} __packed;
>>> Because the compiler will assume all fields are always unaligned and will use very
>>> suboptimal code to access them?
>> This discussion comes up every once in a while. I'm using an old FC7 compiler
>> (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)) And tests show that when the layout
>> of a structure is exactly the same the "__packed" on structure declarations does
>> nothing. It only starts to affect when there are real differences in alignment.
>> Also tests with gcc 3.4.x showed the same effect.
>>
>> On previous discussions no one could come forward and say what compiler version
>> breaks when __packed is applied on structure definition. I'm afraid your statement
>> above is a myth.
> 
> FC7, targeting ia32? Sure, ia32 has no alignment restrictions.
> Try e.g. MIPS.
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 

I don't understand

if you have a structure like
struct foo {
	u32 one;
	u32 two;
};
vs
struct foo_packed {
	u32 one;
	u32 two;
} __packed;

Just adding an __attribute__((packed)) to it clearly does not change
the layout of the structure. Are you saying the __attribute__((packed))
is an hint to the compiler that foo_packed might be used unaligned. This
is just brain-dead, because I can use an unaligned pointer to foo just as
I can to foo_packed. Otherwise there is no difference what-so-ever between
the two. I have to see it to believe. It is totally the wrong hint in the
wrong place taking away valuable meaning of saying "please don't use padding
holes in this structure"

Sorry for been so slow, I just don't get it.
Boaz

From sandeen@sandeen.net Sun Feb  1 09:42:08 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11Fg8pG191591
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 09:42:08 -0600
X-ASG-Debug-ID: 1233502886-537600200000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 0AB761BB3C69; Sun,  1 Feb 2009 07:41:26 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id mCKxyZkcaCLLaAEj; Sun, 01 Feb 2009 07:41:26 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n11FbVOb001537;
	Sun, 1 Feb 2009 10:37:31 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n11FbSOa018837;
	Sun, 1 Feb 2009 10:37:28 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n11FbMxW026814;
	Sun, 1 Feb 2009 10:37:24 -0500
Message-ID: <4985C1B0.8060905@sandeen.net>
Date: Sun, 01 Feb 2009 09:37:20 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Boaz Harrosh <bharrosh@panasas.com>
CC: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        hch@infradead.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de>	<20090130171423.f99c88d0.akpm@linux-foundation.org>	<200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com>	<Pine.LNX.4.64.0902011104320.20875@anakin>	<49857BEB.30404@panasas.com>	<Pine.LNX.4.64.0902011151180.20875@anakin> <4985966D.8040402@panasas.com>
In-Reply-To: <4985966D.8040402@panasas.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233502888
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16721
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Boaz Harrosh wrote:

...

> I don't understand
> 
> if you have a structure like
> struct foo {
> 	u32 one;
> 	u32 two;
> };
> vs
> struct foo_packed {
> 	u32 one;
> 	u32 two;
> } __packed;
> 
> Just adding an __attribute__((packed)) to it clearly does not change
> the layout of the structure. Are you saying the __attribute__((packed))
> is an hint to the compiler that foo_packed might be used unaligned. This
> is just brain-dead, because I can use an unaligned pointer to foo just as
> I can to foo_packed. Otherwise there is no difference what-so-ever between
> the two. I have to see it to believe. It is totally the wrong hint in the
> wrong place taking away valuable meaning of saying "please don't use padding
> holes in this structure"
> 
> Sorry for been so slow, I just don't get it.
> Boaz

While I'm no gcc guru, I can confirm that gratuitous use of the packed
attribute is suboptimal; adding "packed" to every ondisk structure made
obdump -d xfs.ko | wc -l explode by about 15,000 lines on ia64.

-Eric

From SRS0+2062eb3e412fa8c358ca+1988+infradead.org+hch@bombadil.srs.infradead.org Sun Feb  1 10:16:13 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11GGAhU194122
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 10:16:11 -0600
X-ASG-Debug-ID: 1233504929-408601870000-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 7258BD5983
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 08:15:29 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id a5t077v41DIRQGrX for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 08:15:29 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LTeyI-0005vG-KJ; Sun, 01 Feb 2009 16:14:58 +0000
Date: Sun, 1 Feb 2009 11:14:58 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com, Nick Piggin <nickpiggin@yahoo.com.au>
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090201161458.GA5930@infradead.org>
References: <20090201081224.GA22398@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090201081224.GA22398@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233504929
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sun, Feb 01, 2009 at 03:12:24AM -0500, Christoph Hellwig wrote:
> When running xfsqa on the current xfs development tree (sometimes two
> runs are needed to trigger it) I get the following oops.  This seems to
> have been introduced by the last mainling merge (with
> 5ee810072175042775e39bdd3eaaa68884c27805), but I'd need to bisect it to
> make sure my gut feeling is right.

Still happens with a commit before that mainline merge.  Looking for
a good candiate for bisection now.

From bharrosh@panasas.com Sun Feb  1 10:26:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11GQD5x194533
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 10:26:14 -0600
X-ASG-Debug-ID: 1233505532-12ee031d0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id C9ED61BB3EC1; Sun,  1 Feb 2009 08:25:33 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id mwkwGwsdp95RS5gK; Sun, 01 Feb 2009 08:25:33 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 08:25:32 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 11:25:30 -0500
Message-ID: <4985CCFA.4070008@panasas.com>
Date: Sun, 01 Feb 2009 18:25:30 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sandeen.net>
CC: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        hch@infradead.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de>	<20090130171423.f99c88d0.akpm@linux-foundation.org>	<200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com>	<Pine.LNX.4.64.0902011104320.20875@anakin>	<49857BEB.30404@panasas.com>	<Pine.LNX.4.64.0902011151180.20875@anakin> <4985966D.8040402@panasas.com> <4985C1B0.8060905@sandeen.net>
In-Reply-To: <4985C1B0.8060905@sandeen.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2009 16:25:30.0854 (UTC) FILETIME=[B331C860:01C98489]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233505533
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16725
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Eric Sandeen wrote:
> Boaz Harrosh wrote:
> 
> ...
> 
>> I don't understand
>>
>> if you have a structure like
>> struct foo {
>> 	u32 one;
>> 	u32 two;
>> };
>> vs
>> struct foo_packed {
>> 	u32 one;
>> 	u32 two;
>> } __packed;
>>
>> Just adding an __attribute__((packed)) to it clearly does not change
>> the layout of the structure. Are you saying the __attribute__((packed))
>> is an hint to the compiler that foo_packed might be used unaligned. This
>> is just brain-dead, because I can use an unaligned pointer to foo just as
>> I can to foo_packed. Otherwise there is no difference what-so-ever between
>> the two. I have to see it to believe. It is totally the wrong hint in the
>> wrong place taking away valuable meaning of saying "please don't use padding
>> holes in this structure"
>>
>> Sorry for been so slow, I just don't get it.
>> Boaz
> 
> While I'm no gcc guru, I can confirm that gratuitous use of the packed
> attribute is suboptimal; adding "packed" to every ondisk structure made
> obdump -d xfs.ko | wc -l explode by about 15,000 lines on ia64.

Yes! but are the structures the same? that is sizeof(foo_packed) == sizeof(foo) ?
If not then clearly above is expected.

In anyway, if __attribute__((packed)) makes some brain-dead gcc do the wrong thing
putting a _Padding member where you expect an alignment hole, and a BUILD_BUG_ON(sizeof() != ())
statement somewhere in code is a must, specifically for the brain-dead.

> 
> -Eric

There are to many places in Kernel where these things are left to chance that give
me an headache, not talking about cross platform mounts.

Boaz

From sandeen@sandeen.net Sun Feb  1 10:37:10 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11Gb9PJ194949
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 10:37:10 -0600
X-ASG-Debug-ID: 1233506188-081a03d20000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 8AD65D5A3D; Sun,  1 Feb 2009 08:36:28 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id hCRyvFCOQ1COpThd; Sun, 01 Feb 2009 08:36:28 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n11GZvkl009766;
	Sun, 1 Feb 2009 11:35:57 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n11GZuu8026909;
	Sun, 1 Feb 2009 11:35:57 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n11GZp6B006317;
	Sun, 1 Feb 2009 11:35:52 -0500
Message-ID: <4985CF66.6090409@sandeen.net>
Date: Sun, 01 Feb 2009 10:35:50 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Boaz Harrosh <bharrosh@panasas.com>
CC: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        hch@infradead.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <4980C71F.1010804@ankitjain.org> <200901310138.34164.arnd@arndb.de>	<20090130171423.f99c88d0.akpm@linux-foundation.org>	<200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com>	<Pine.LNX.4.64.0902011104320.20875@anakin>	<49857BEB.30404@panasas.com>	<Pine.LNX.4.64.0902011151180.20875@anakin> <4985966D.8040402@panasas.com> <4985C1B0.8060905@sandeen.net> <4985CCFA.4070008@panasas.com>
In-Reply-To: <4985CCFA.4070008@panasas.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233506189
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16725
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Boaz Harrosh wrote:
> Eric Sandeen wrote:
>> Boaz Harrosh wrote:
>>
>> ...
>>
>>> I don't understand
>>>
>>> if you have a structure like
>>> struct foo {
>>> 	u32 one;
>>> 	u32 two;
>>> };
>>> vs
>>> struct foo_packed {
>>> 	u32 one;
>>> 	u32 two;
>>> } __packed;
>>>
>>> Just adding an __attribute__((packed)) to it clearly does not change
>>> the layout of the structure. Are you saying the __attribute__((packed))
>>> is an hint to the compiler that foo_packed might be used unaligned. This
>>> is just brain-dead, because I can use an unaligned pointer to foo just as
>>> I can to foo_packed. Otherwise there is no difference what-so-ever between
>>> the two. I have to see it to believe. It is totally the wrong hint in the
>>> wrong place taking away valuable meaning of saying "please don't use padding
>>> holes in this structure"
>>>
>>> Sorry for been so slow, I just don't get it.
>>> Boaz
>> While I'm no gcc guru, I can confirm that gratuitous use of the packed
>> attribute is suboptimal; adding "packed" to every ondisk structure made
>> obdump -d xfs.ko | wc -l explode by about 15,000 lines on ia64.
> 
> Yes! but are the structures the same? that is sizeof(foo_packed) == sizeof(foo) ?
> If not then clearly above is expected.

Yes, they are the same.  They're disk structure definitions after all;
ia64 doesn't *need* the packing, but adding the packed attribute changes
the code that gcc generates.

See also, perhaps,
http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/

For an interface like this maybe it's fine, but sprnkling it around like
pixie dust may not be a good plan.  :)

-Eric

From SRS0+2062eb3e412fa8c358ca+1988+infradead.org+hch@bombadil.srs.infradead.org Sun Feb  1 10:42:30 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11GgTet195173
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 10:42:30 -0600
X-ASG-Debug-ID: 1233506509-7ff700190000-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 E59951BB4B0F; Sun,  1 Feb 2009 08:41:49 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jbzdVTW3OPwROZBF; Sun, 01 Feb 2009 08:41:49 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LTfNy-0003QX-7N; Sun, 01 Feb 2009 16:41:30 +0000
Date: Sun, 1 Feb 2009 11:41:30 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Arnd Bergmann <arnd@arndb.de>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        hch@infradead.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
	for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
	for compatibility with legacy xfs ioctls
Message-ID: <20090201164130.GA32276@infradead.org>
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com> <Pine.LNX.4.64.0902011104320.20875@anakin> <49857BEB.30404@panasas.com> <Pine.LNX.4.64.0902011151180.20875@anakin> <4985966D.8040402@panasas.com> <4985C1B0.8060905@sandeen.net> <4985CCFA.4070008@panasas.com> <4985CF66.6090409@sandeen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4985CF66.6090409@sandeen.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233506509
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

The structures have been defined exactly like that in XFS (and ocfs2)
before, and there are similar cases in other ioctls handlers.

If anyone feels like changing this in some way feel free to wade through
the endless discussions about the pros and cons for it, but I think
doing it in context of this patch is not helpful.

From bharrosh@panasas.com Sun Feb  1 10:59:28 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11GxRE7196142
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 10:59:28 -0600
X-ASG-Debug-ID: 1233507527-7ff6004a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id E5A021BB4967; Sun,  1 Feb 2009 08:58:47 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id hlXDdQqdfEFjZODn; Sun, 01 Feb 2009 08:58:47 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 08:57:45 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Sun, 1 Feb 2009 11:57:44 -0500
Message-ID: <4985D48A.6090007@panasas.com>
Date: Sun, 01 Feb 2009 18:57:46 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Christoph Hellwig <hch@infradead.org>
CC: Eric Sandeen <sandeen@sandeen.net>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Arnd Bergmann <arnd@arndb.de>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <200901310248.42820.arnd@arndb.de> <49856FE6.8020601@panasas.com> <Pine.LNX.4.64.0902011104320.20875@anakin> <49857BEB.30404@panasas.com> <Pine.LNX.4.64.0902011151180.20875@anakin> <4985966D.8040402@panasas.com> <4985C1B0.8060905@sandeen.net> <4985CCFA.4070008@panasas.com> <4985CF66.6090409@sandeen.net> <20090201164130.GA32276@infradead.org>
In-Reply-To: <20090201164130.GA32276@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2009 16:57:44.0507 (UTC) FILETIME=[33BDD0B0:01C9848E]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233507527
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16727
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Christoph Hellwig wrote:
> The structures have been defined exactly like that in XFS (and ocfs2)
> before, and there are similar cases in other ioctls handlers.
> 
> If anyone feels like changing this in some way feel free to wade through
> the endless discussions about the pros and cons for it, but I think
> doing it in context of this patch is not helpful.

OK so ia64 gcc is broken in regard to __attribute__((packed(1))),
and it should not be used.
But clearly the programmer, Like in this patch exactly, should spell
out the hole created by padding and spell that hole out and call it
__Padding. The porgrammer thought about it, identified there is an hole,
please don't drop this information on the floor. Put it in the code so I 
don't have to break my head on it.

> Arnd Bergmann wrote:
>> > +struct space_resv {
>> > +	__s16		l_type;
>> > +	__s16		l_whence;
>> > +	__s64		l_start;
>> > +	__s64		l_len;		/* len == 0 means until end of file */
>> > +	__s32		l_sysid;
>> > +	__u32		l_pid;
>> > +	__s32		l_pad[4];	/* reserve area			    */
>> > +};
> 
> What about telling the compiler exactly what you said above, just
> to be sure we all mean the same thing. (And as documentation for new
> comers):
> 
> +struct space_resv_64 {
> +	__s16		l_type;
> +	__s16		l_whence;
> +	__u32		reserved;
change that to
	__u32		__padding_hole;
> +	__s64		l_start;
> +	__s64		l_len;		/* len == 0 means until end of file */
> +	__s32		l_sysid;
> +	__u32		l_pid;
> +	__s32		l_pad[4];	/* reserve area			    */
> +} __packed;
Drop the evil __packed but show me the padding

Thanks
Boaz

From arekm@carme.pld-linux.org Sun Feb  1 15:28:13 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11LSC7c206546
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 15:28:12 -0600
X-ASG-Debug-ID: 1233523650-6fdf03850000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from carme.pld-linux.org (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 4A2A6D647B
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 13:27:31 -0800 (PST)
Received: from carme.pld-linux.org (carme.pld-linux.org [193.239.45.140]) by cuda.sgi.com with ESMTP id k5lk0DVceeDIAwEs for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 13:27:31 -0800 (PST)
Received: from arekm by carme.pld-linux.org with local (Exim 4.69)
	(envelope-from <arekm@carme.pld-linux.org>)
	id 1LTjqk-000qqc-8f; Sun, 01 Feb 2009 22:27:30 +0100
From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
To: xfs@oss.sgi.com
Cc: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
X-ASG-Orig-Subj: [PATCH] build: Explict libtool tag. Preserve CFLAGS/CPPFLAGS.
Subject: [PATCH] build: Explict libtool tag. Preserve CFLAGS/CPPFLAGS.
Date: Sun,  1 Feb 2009 22:27:30 +0100
Message-Id: <1233523650-203120-1-git-send-email-arekm@maven.pl>
X-Mailer: git-send-email 1.6.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Barracuda-Connect: carme.pld-linux.org[193.239.45.140]
X-Barracuda-Start-Time: 1233523652
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16745
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Use explict libtool CC tag (sometimes libtool can't decide what tag is
correct one if omited).

Preserve CFLAGS/CPPFLAGS to allow:
CPPFLAGS="-I$HOME/here-is-xfsprogs-installed/include" \
LDFLAGS="-L$HOME/here-is-xfsprogs-installed/lib" \
./configure  ...

Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
---
 include/builddefs.in |    4 +++-
 include/buildmacros  |    4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/builddefs.in b/include/builddefs.in
index d855c89..636f632 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -11,6 +11,8 @@ DEBUG = @debug_build@
 OPTIMIZER = @opt_build@
 MALLOCLIB = @malloc_lib@
 LOADERFLAGS = @LDFLAGS@
+CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
 
 LIBXFS = @libxfs@
 LIBACL = @libacl@
@@ -75,7 +77,7 @@ ifeq ($(PKG_PLATFORM),freebsd)
 DEPENDFLAGS = -D__FreeBSD__
 endif
 
-GCFLAGS = $(OPTIMIZER) $(DEBUG) \
+GCFLAGS = $(OPTIMIZER) $(DEBUG) $(CPPFLAGS) \
 	-I$(TOPDIR)/include -DVERSION=\"$(PKG_VERSION)\"
 
 # Global, Platform, Local CFLAGS
diff --git a/include/buildmacros b/include/buildmacros
index 801bcb6..276d2c8 100644
--- a/include/buildmacros
+++ b/include/buildmacros
@@ -41,10 +41,10 @@ LIBNAME = $(basename $(LTLIBRARY))
 LTOBJECTS = $(OBJECTS:.o=.lo)
 LTVERSION = $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
 
-LTLINK = $(LIBTOOL) --mode=link $(CC)
+LTLINK = $(LIBTOOL) --tag=CC --mode=link $(CC)
 LTEXEC = $(LIBTOOL) --mode=execute
 LTINSTALL = $(LIBTOOL) --mode=install $(INSTALL)
-LTCOMPILE = $(LIBTOOL) --mode=compile $(CCF)
+LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CCF)
 
 ifeq ($(ENABLE_SHARED),yes)
 LTLDFLAGS += -rpath $(PKG_LIB_DIR)
-- 
1.6.1.1

From sandeen@sandeen.net Sun Feb  1 16:06:02 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n11M62A3207606
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 16:06:02 -0600
X-ASG-Debug-ID: 1233525922-66b200be0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 84AD3D6547
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 14:05:22 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id x33HvMsYLwdnlgji for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 14:05:22 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n11M5CsC021392;
	Sun, 1 Feb 2009 17:05:14 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n11M5C5m005149;
	Sun, 1 Feb 2009 17:05:12 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n11M57qn003399;
	Sun, 1 Feb 2009 17:05:12 -0500
Message-ID: <49861C91.2080106@sandeen.net>
Date: Sun, 01 Feb 2009 16:05:05 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: =?UTF-8?B?QXJrYWRpdXN6IE1pxZtraWV3aWN6?= <arekm@maven.pl>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] build: Explict libtool tag. Preserve CFLAGS/CPPFLAGS.
Subject: Re: [PATCH] build: Explict libtool tag. Preserve CFLAGS/CPPFLAGS.
References: <1233523650-203120-1-git-send-email-arekm@maven.pl>
In-Reply-To: <1233523650-203120-1-git-send-email-arekm@maven.pl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233525922
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16747
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Arkadiusz Miśkiewicz wrote:
> Use explict libtool CC tag (sometimes libtool can't decide what tag is
> correct one if omited).

Seems good to me.  I'll push this on the kernel.org repo, thanks.

(This is against xfstests, based on irc conversation) :)

-Eric

> Preserve CFLAGS/CPPFLAGS to allow:
> CPPFLAGS="-I$HOME/here-is-xfsprogs-installed/include" \
> LDFLAGS="-L$HOME/here-is-xfsprogs-installed/lib" \
> ./configure  ...
> 
> Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
> ---
>  include/builddefs.in |    4 +++-
>  include/buildmacros  |    4 ++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/include/builddefs.in b/include/builddefs.in
> index d855c89..636f632 100644
> --- a/include/builddefs.in
> +++ b/include/builddefs.in
> @@ -11,6 +11,8 @@ DEBUG = @debug_build@
>  OPTIMIZER = @opt_build@
>  MALLOCLIB = @malloc_lib@
>  LOADERFLAGS = @LDFLAGS@
> +CFLAGS = @CFLAGS@
> +CPPFLAGS = @CPPFLAGS@
>  
>  LIBXFS = @libxfs@
>  LIBACL = @libacl@
> @@ -75,7 +77,7 @@ ifeq ($(PKG_PLATFORM),freebsd)
>  DEPENDFLAGS = -D__FreeBSD__
>  endif
>  
> -GCFLAGS = $(OPTIMIZER) $(DEBUG) \
> +GCFLAGS = $(OPTIMIZER) $(DEBUG) $(CPPFLAGS) \
>  	-I$(TOPDIR)/include -DVERSION=\"$(PKG_VERSION)\"
>  
>  # Global, Platform, Local CFLAGS
> diff --git a/include/buildmacros b/include/buildmacros
> index 801bcb6..276d2c8 100644
> --- a/include/buildmacros
> +++ b/include/buildmacros
> @@ -41,10 +41,10 @@ LIBNAME = $(basename $(LTLIBRARY))
>  LTOBJECTS = $(OBJECTS:.o=.lo)
>  LTVERSION = $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
>  
> -LTLINK = $(LIBTOOL) --mode=link $(CC)
> +LTLINK = $(LIBTOOL) --tag=CC --mode=link $(CC)
>  LTEXEC = $(LIBTOOL) --mode=execute
>  LTINSTALL = $(LIBTOOL) --mode=install $(INSTALL)
> -LTCOMPILE = $(LIBTOOL) --mode=compile $(CCF)
> +LTCOMPILE = $(LIBTOOL) --tag=CC --mode=compile $(CCF)
>  
>  ifeq ($(ENABLE_SHARED),yes)
>  LTLDFLAGS += -rpath $(PKG_LIB_DIR)

From arnd@arndb.de Sun Feb  1 18:32:55 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n120Wsdv213136
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 18:32:55 -0600
X-ASG-Debug-ID: 1233534732-0fa2036e0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from moutng.kundenserver.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 61E7F1BFEAB4; Sun,  1 Feb 2009 16:32:12 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by cuda.sgi.com with ESMTP id FOcbp1EjrVkhlXLd; Sun, 01 Feb 2009 16:32:12 -0800 (PST)
Received: from noname (port-92-202-8-175.dynamic.qsc.de [92.202.8.175])
	by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis)
	id 0ML31I-1LTmiZ2Jy0-0005e9; Mon, 02 Feb 2009 01:31:23 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Boaz Harrosh <bharrosh@panasas.com>
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Date: Mon, 2 Feb 2009 01:31:02 +0100
User-Agent: KMail/1.9.9
Cc: Christoph Hellwig <hch@infradead.org>, Eric Sandeen <sandeen@sandeen.net>,
        Geert Uytterhoeven <geert@linux-m68k.org>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com>
In-Reply-To: <4985D48A.6090007@panasas.com>
X-Face: I@=L^?./?$U,EK.)V[4*>`zSqm0>65YtkOe>TFD'!aw?7OVv#~5xd\s,[~w]-J!)|%=]>=?utf-8?q?+=0A=09=7EohchhkRGW=3F=7C6=5FqTmkd=5Ft=3FLZC=23Q-=60=2E=60Y=2Ea=5E?=
 =?utf-8?q?3zb?=)
 =?utf-8?q?+U-JVN=5DWT=25cw=23=5BYo0=267C=26bL12wWGlZi=0A=09=7EJ=3B=5Cwg?=
 =?utf-8?q?=3B3zRnz?=,J"CT_)=\H'1/{?SR7GDu?WIopm.HaBG=QYj"NZD_[zrM\Gip^U
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902020131.04203.arnd@arndb.de>
X-Provags-ID: V01U2FsdGVkX19LENEbkDPjcCPKkPgRuw92wJp7KyPZJX4FYT0
 g7mf4/RGEz0MTKetY1dOf//XL+bSE6kdc5DA+pddHfZPWHN4IU
 IcovClN3zwIa1x/tUy/6Q==
X-Barracuda-Connect: moutng.kundenserver.de[212.227.17.8]
X-Barracuda-Start-Time: 1233534734
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16757
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sunday 01 February 2009, Boaz Harrosh wrote:
> Christoph Hellwig wrote:
> > The structures have been defined exactly like that in XFS (and ocfs2)
> > before, and there are similar cases in other ioctls handlers.
> > 
> > If anyone feels like changing this in some way feel free to wade through
> > the endless discussions about the pros and cons for it, but I think
> > doing it in context of this patch is not helpful.
> 
> OK so ia64 gcc is broken in regard to __attribute__((packed(1))),
> and it should not be used.

No, the compiler is correct, it has to generate more complex code
if it cannot assume that data is naturally aligned and the architecture
does not support unaligned loads. If you don't understand this, please
at least read the list archives about the last five times this came up
before claiming that the compiler is broken.

> But clearly the programmer, Like in this patch exactly, should spell
> out the hole created by padding and spell that hole out and call it
> __Padding. The porgrammer thought about it, identified there is an hole,
> please don't drop this information on the floor. Put it in the code so I 
> don't have to break my head on it.

Again, you are missing the point. The patch has to leave out the padding
and whatnot because the idea of the patch is to provide a
backwards-compatible API for programs written against the legacy XFS
API. The original definition of the interface was flawed, but unless you
can travel back in time to complain about this in the initial submission
of the XFS file system, you should not blame the entirely correct patch now.

	Arnd <><

From david@fromorbit.com Sun Feb  1 20:01:22 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1221LCW216345
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 20:01:21 -0600
X-ASG-Debug-ID: 1233540038-664200410000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id D6F541BFEB83
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 18:00:39 -0800 (PST)
Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id RmD9FDUBK44MhR01 for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 18:00:39 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAOzehUl5LJ2q/2dsb2JhbADGPYQUBg
X-IronPort-AV: E=Sophos;i="4.37,362,1231075800"; 
   d="scan'208";a="308131491"
Received: from ppp121-44-157-170.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.157.170])
  by ipmail05.adl2.internode.on.net with ESMTP; 02 Feb 2009 12:25:04 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LTo1f-0001jW-0u; Mon, 02 Feb 2009 12:55:03 +1100
Date: Mon, 2 Feb 2009 12:55:02 +1100
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com, Nick Piggin <nickpiggin@yahoo.com.au>
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090202015502.GF24173@disturbed>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	xfs@oss.sgi.com, Nick Piggin <nickpiggin@yahoo.com.au>
References: <20090201081224.GA22398@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090201081224.GA22398@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145]
X-Barracuda-Start-Time: 1233540040
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16763
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sun, Feb 01, 2009 at 03:12:24AM -0500, Christoph Hellwig wrote:
> When running xfsqa on the current xfs development tree (sometimes two
> runs are needed to trigger it) I get the following oops.  This seems to
> have been introduced by the last mainling merge (with
> 5ee810072175042775e39bdd3eaaa68884c27805), but I'd need to bisect it to
> make sure my gut feeling is right.

Can you add the patch from this post:

[PATCH] Re: Corrupted XFS log replay oops.

http://lkml.org/lkml/2009/1/21/403

And see if that fixes the problem?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From k-mio@sx.jp.nec.com Sun Feb  1 23:06:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1256DxA223752
	for <xfs@oss.sgi.com>; Sun, 1 Feb 2009 23:06:14 -0600
X-ASG-Debug-ID: 1233551132-710000940000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 212701BFEFE2
	for <xfs@oss.sgi.com>; Sun,  1 Feb 2009 21:05:32 -0800 (PST)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id lFCmvA6Foc1mL9u4 for <xfs@oss.sgi.com>; Sun, 01 Feb 2009 21:05:32 -0800 (PST)
Received: from mailgate3.nec.co.jp ([10.7.69.192])
	by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n1255VHu008956
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 14:05:31 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC)
	id n1255Ve17114 for xfs@oss.sgi.com; Mon, 2 Feb 2009 14:05:31 +0900 (JST)
Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7])
	by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id n1255VgT012193
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 14:05:31 +0900 (JST)
Received: from shoin.jp.nec.com ([10.26.220.3] [10.26.220.3]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-18831; Mon, 2 Feb 2009 14:05:15 +0900
Received: from [10.64.170.99] ([10.64.170.99] [10.64.170.99]) by mail.jp.nec.com with ESMTP; Mon, 2 Feb 2009 14:05:14 +0900
Message-ID: <49867F0A.30300@sx.jp.nec.com>
Date: Mon, 02 Feb 2009 14:05:14 +0900
From: Kazuya Mio <k-mio@sx.jp.nec.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: [PATCH] fix xfsctl man page typo
Subject: [PATCH] fix xfsctl man page typo
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193]
X-Barracuda-Start-Time: 1233551134
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0193
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16775
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hi,

This patch gets rid of the unnecessary period in xfsctl(3) man page.

Regards,
Kazuya Mio

Signed-off-by: Kazuya Mio <k-mio@sx.jp.nec.com>
---
diff --git a/man/man3/xfsctl.3 b/man/man3/xfsctl.3
index 64e18df..d586ea0 100644
--- a/man/man3/xfsctl.3
+++ b/man/man3/xfsctl.3
@@ -564,7 +564,7 @@ value of zero means that the inode table has been exhausted
 .B XFS_IOC_FSBULKSTAT_SINGLE
 This interface is a variant of the
 .B XFS_IOC_FSBULKSTAT
-interface, used to obtain information about a single inode.
+interface, used to obtain information about a single inode
 for an open file in the filesystem of interest.
 The same structure is used to pass information in and out of
 the kernel, except no output count parameter is used (should

From bharrosh@panasas.com Mon Feb  2 02:30:09 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n128U8v4235110
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 02:30:09 -0600
X-ASG-Debug-ID: 1233563367-692d02d20000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id EBE961BFF304; Mon,  2 Feb 2009 00:29:27 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id 2xrIrFvjhufLStIK; Mon, 02 Feb 2009 00:29:27 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 2 Feb 2009 00:29:27 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 2 Feb 2009 03:29:24 -0500
Message-ID: <4986AEE8.5040609@panasas.com>
Date: Mon, 02 Feb 2009 10:29:28 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Arnd Bergmann <arnd@arndb.de>
CC: Christoph Hellwig <hch@infradead.org>, Eric Sandeen <sandeen@sandeen.net>,
        Geert Uytterhoeven <geert@linux-m68k.org>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com> <200902020131.04203.arnd@arndb.de>
In-Reply-To: <200902020131.04203.arnd@arndb.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Feb 2009 08:29:25.0183 (UTC) FILETIME=[5B240CF0:01C98510]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233563368
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.82
X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16789
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.20 BSF_SC0_MJ615          Custom Rule MJ615
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Arnd Bergmann wrote:
> On Sunday 01 February 2009, Boaz Harrosh wrote:
>> Christoph Hellwig wrote:
>>> The structures have been defined exactly like that in XFS (and ocfs2)
>>> before, and there are similar cases in other ioctls handlers.
>>>
>>> If anyone feels like changing this in some way feel free to wade through
>>> the endless discussions about the pros and cons for it, but I think
>>> doing it in context of this patch is not helpful.
>> OK so ia64 gcc is broken in regard to __attribute__((packed(1))),
>> and it should not be used.
> 
> No, the compiler is correct, it has to generate more complex code
> if it cannot assume that data is naturally aligned and the architecture
> does not support unaligned loads. If you don't understand this, please
> at least read the list archives about the last five times this came up
> before claiming that the compiler is broken.
> 

Wrong!! Sorry, you guys don't listen.
I'm talking of the case where the structures are EXACTLY the same anyway
you look at them. sizeof(foo) == sizeof(foo_packed) and 
offsetof(foo_memmber) == offsetof(foo_packed_member) for every member of
the structure. foo && foo_packed are declared exactly the same but with
__attribute__((packed(1))) applied to the later.

THEN in ia64 case the compiler is brain dead, because it relates
"unalignment" to packed(1) which are two different things.

>> But clearly the programmer, Like in this patch exactly, should spell
>> out the hole created by padding and spell that hole out and call it
>> __Padding. The porgrammer thought about it, identified there is an hole,
>> please don't drop this information on the floor. Put it in the code so I 
>> don't have to break my head on it.
> 
> Again, you are missing the point. The patch has to leave out the padding
> and whatnot because the idea of the patch is to provide a
> backwards-compatible API for programs written against the legacy XFS
> API. The original definition of the interface was flawed, but unless you
> can travel back in time to complain about this in the initial submission
> of the XFS file system, you should not blame the entirely correct patch now.
> 

Lets make a small test is: sizeof(orig_struct) == sizeof(my_struct)?
offsetof(orig_any_memmber) == offsetof(my_any_memmber)?

Yes because the padding is there if you shove it under the rug or expose
it.

What I'm saying is don't repeat the passed mistakes, spell out the exact
structure layout. So it will compile the same for any <= 64bit machine.
If the way a structure was defined in the passed, produced two or more
memory representations, spell these out with different structure
definitions and choose the one you need at compile time.

Otherwise you have fixed nothing. You are just repeating the same
passed mistake. And down the future some programmer will wish he add
a time machine to go back and fix what we've done today. But bingo, he
did and told me about it, and now it is time to fix that.

> 	Arnd <><

Don't let the compiler have the driver's sit. You do the driving, because
he does not know where you want to go.

Boaz

From geert@linux-m68k.org Mon Feb  2 02:46:29 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n128kSO7235895
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 02:46:29 -0600
X-ASG-Debug-ID: 1233564348-3bb103b60000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from nelson.telenet-ops.be (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 0D77BD7526; Mon,  2 Feb 2009 00:45:48 -0800 (PST)
Received: from nelson.telenet-ops.be (nelson.telenet-ops.be [195.130.133.66]) by cuda.sgi.com with ESMTP id vrJQWMUoFSGs2U9N; Mon, 02 Feb 2009 00:45:48 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by nelson.telenet-ops.be (Postfix) with SMTP id AE77D50020;
	Mon,  2 Feb 2009 09:45:47 +0100 (CET)
Received: from anakin.of.borg (d54C15368.access.telenet.be [84.193.83.104])
	by nelson.telenet-ops.be (Postfix) with ESMTP id C5BDC5004D;
	Mon,  2 Feb 2009 09:45:46 +0100 (CET)
Received: from anakin.of.borg (localhost [127.0.0.1])
	by anakin.of.borg (8.14.3/8.14.3/Debian-5) with ESMTP id n128jkKn006560
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 2 Feb 2009 09:45:46 +0100
Received: from localhost (geert@localhost)
	by anakin.of.borg (8.14.3/8.14.3/Submit) with ESMTP id n128jhRV006557;
	Mon, 2 Feb 2009 09:45:43 +0100
X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs
Date: Mon, 2 Feb 2009 09:45:43 +0100 (CET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sender: geert@linux-m68k.org
To: Boaz Harrosh <bharrosh@panasas.com>
cc: Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@infradead.org>,
        Eric Sandeen <sandeen@sandeen.net>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
In-Reply-To: <4986AEE8.5040609@panasas.com>
Message-ID: <Pine.LNX.4.64.0902020942230.11930@anakin>
References: <20090130171423.f99c88d0.akpm@linux-foundation.org>
 <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com>
 <200902020131.04203.arnd@arndb.de> <4986AEE8.5040609@panasas.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Barracuda-Connect: nelson.telenet-ops.be[195.130.133.66]
X-Barracuda-Start-Time: 1233564349
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16789
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Mon, 2 Feb 2009, Boaz Harrosh wrote:
> Arnd Bergmann wrote:
> > On Sunday 01 February 2009, Boaz Harrosh wrote:
> >> Christoph Hellwig wrote:
> >>> The structures have been defined exactly like that in XFS (and ocfs2)
> >>> before, and there are similar cases in other ioctls handlers.
> >>>
> >>> If anyone feels like changing this in some way feel free to wade through
> >>> the endless discussions about the pros and cons for it, but I think
> >>> doing it in context of this patch is not helpful.
> >> OK so ia64 gcc is broken in regard to __attribute__((packed(1))),
> >> and it should not be used.
> > 
> > No, the compiler is correct, it has to generate more complex code
> > if it cannot assume that data is naturally aligned and the architecture
> > does not support unaligned loads. If you don't understand this, please
> > at least read the list archives about the last five times this came up
> > before claiming that the compiler is broken.
> > 
> 
> Wrong!! Sorry, you guys don't listen.
> I'm talking of the case where the structures are EXACTLY the same anyway
> you look at them. sizeof(foo) == sizeof(foo_packed) and 
> offsetof(foo_memmber) == offsetof(foo_packed_member) for every member of
> the structure. foo && foo_packed are declared exactly the same but with
> __attribute__((packed(1))) applied to the later.
> 
> THEN in ia64 case the compiler is brain dead, because it relates
> "unalignment" to packed(1) which are two different things.

The natural alignment of a structure is max(alignment(member)), for all
members. With __attribute__((packed)), the natural alignment of the structure
is 1, so the compiler cannot assume anything.

While the ints in the structure may still be at offsets 0, 4, 8, and so on,
this doesn't say anything about their actual memory addresses, as the struct
base address itself may be unaligned.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

From arekm@maven.pl Mon Feb  2 03:08:46 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1298k7E236751
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 03:08:46 -0600
X-ASG-Debug-ID: 1233565685-7268006f0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from main.carme.maven.pl (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 56AA51BFF3EE
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 01:08:06 -0800 (PST)
Received: from main.carme.maven.pl (main.carme.maven.pl [193.239.45.138]) by cuda.sgi.com with ESMTP id LH0Il3RAiAJAF97L for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 01:08:06 -0800 (PST)
Received: from [83.238.65.58] (port=1071 helo=maven.pl ident=matrix157)
	by main.carme.maven.pl with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <arekm@maven.pl>)
	id 1LTumi-000naG-KB; Mon, 02 Feb 2009 10:08:04 +0100
Received: from arekm by maven.pl with local (Exim 4.69)
	(envelope-from <arekm@maven.pl>)
	id 1LTumi-00007w-77; Mon, 02 Feb 2009 10:08:04 +0100
From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
To: xfs@oss.sgi.com
Cc: root <root@farm.lan>
X-ASG-Orig-Subj: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
Subject: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
Date: Mon,  2 Feb 2009 10:08:04 +0100
Message-Id: <1233565684-462-1-git-send-email-arekm@maven.pl>
X-Mailer: git-send-email 1.6.1.2
X-Barracuda-Connect: main.carme.maven.pl[193.239.45.138]
X-Barracuda-Start-Time: 1233565686
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16791
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

From: root <root@farm.lan>

Pass *FLAGS in some targets.

Drop LIBHANDLE, LIBATTR and LIBACL from deps since there are in form
"-llibrary".

Signed-off-by: root <root@farm.lan>
---
 src/Makefile |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/Makefile b/src/Makefile
index ad4c204..634e1b3 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -58,10 +58,10 @@ genhashnames: genhashnames.o
 nametest: nametest.o $(LIBTEST)
 	$(LINKTEST) $(LIBTEST) $(LDLIBS)
 
-bstat: bstat.o $(LIBHANDLE)
+bstat: bstat.o
 	$(LINKTEST) $(LIBHANDLE) $(LDLIBS)
 
-t_immutable: t_immutable.o $(LIBHANDLE) $(LIBACL)
+t_immutable: t_immutable.o
 	$(LINKTEST) $(LIBACL) $(LIBHANDLE) $(LDLIBS)
 
 loggen:	loggen.o
@@ -82,17 +82,17 @@ multi_open_unlink: multi_open_unlink.o
 #scaleread: scaleread.o $(LDLIBS)
 #	$(LINKTEST)
 
-acl_get: acl_get.o $(LIBACL) $(LIBATTR)
+acl_get: acl_get.o
 	$(LINKTEST) $(LIBACL) $(LIBATTR) $(LDLIBS)
 
-dmiperf: dmiperf.o $(LIBATTR)
+dmiperf: dmiperf.o
 	$(LINKTEST) $(LIBATTR) $(LDLIBS)
 
 preallo_rw_pattern_reader:
-	$(CC) -DREAD iopat.c -o preallo_rw_pattern_reader
+	$(CC) $(GCFLAGS) $(LDFLAGS) -DREAD iopat.c -o preallo_rw_pattern_reader
 
 preallo_rw_pattern_writer:
-	$(CC) -DWRITE iopat.c -o preallo_rw_pattern_writer
+	$(CC) $(GCFLAGS) $(LDFLAGS) -DWRITE iopat.c -o preallo_rw_pattern_writer
 
 ftrunc: ftrunc.o
 	$(LINKTEST)
-- 
1.6.1.1

From arekm@maven.pl Mon Feb  2 03:10:18 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n129AH10236905
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 03:10:18 -0600
X-ASG-Debug-ID: 1233565777-255701980000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from main.carme.maven.pl (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 57B43D7757
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 01:09:38 -0800 (PST)
Received: from main.carme.maven.pl (main.carme.maven.pl [193.239.45.138]) by cuda.sgi.com with ESMTP id UAAM23qGQ3o9b3ka for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 01:09:38 -0800 (PST)
Received: from [83.238.65.58] (port=1087 helo=maven.pl ident=matrix157)
	by main.carme.maven.pl with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.69)
	(envelope-from <arekm@maven.pl>)
	id 1LTuoD-000nde-G3
	for xfs@oss.sgi.com; Mon, 02 Feb 2009 10:09:37 +0100
Received: from arekm by maven.pl with local (Exim 4.69)
	(envelope-from <arekm@maven.pl>)
	id 1LTuoC-00009a-TS; Mon, 02 Feb 2009 10:09:36 +0100
From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
To: xfs@oss.sgi.com
Cc: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= <arekm@maven.pl>
X-ASG-Orig-Subj: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
Subject: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
Date: Mon,  2 Feb 2009 10:09:36 +0100
Message-Id: <1233565776-563-1-git-send-email-arekm@maven.pl>
X-Mailer: git-send-email 1.6.1.2
X-Barracuda-Connect: main.carme.maven.pl[193.239.45.138]
X-Barracuda-Start-Time: 1233565778
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16791
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Pass *FLAGS in some targets.

Drop LIBHANDLE, LIBATTR and LIBACL from deps since there are in form
"-llibrary".

Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
---
 src/Makefile |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/Makefile b/src/Makefile
index ad4c204..634e1b3 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -58,10 +58,10 @@ genhashnames: genhashnames.o
 nametest: nametest.o $(LIBTEST)
 	$(LINKTEST) $(LIBTEST) $(LDLIBS)
 
-bstat: bstat.o $(LIBHANDLE)
+bstat: bstat.o
 	$(LINKTEST) $(LIBHANDLE) $(LDLIBS)
 
-t_immutable: t_immutable.o $(LIBHANDLE) $(LIBACL)
+t_immutable: t_immutable.o
 	$(LINKTEST) $(LIBACL) $(LIBHANDLE) $(LDLIBS)
 
 loggen:	loggen.o
@@ -82,17 +82,17 @@ multi_open_unlink: multi_open_unlink.o
 #scaleread: scaleread.o $(LDLIBS)
 #	$(LINKTEST)
 
-acl_get: acl_get.o $(LIBACL) $(LIBATTR)
+acl_get: acl_get.o
 	$(LINKTEST) $(LIBACL) $(LIBATTR) $(LDLIBS)
 
-dmiperf: dmiperf.o $(LIBATTR)
+dmiperf: dmiperf.o
 	$(LINKTEST) $(LIBATTR) $(LDLIBS)
 
 preallo_rw_pattern_reader:
-	$(CC) -DREAD iopat.c -o preallo_rw_pattern_reader
+	$(CC) $(GCFLAGS) $(LDFLAGS) -DREAD iopat.c -o preallo_rw_pattern_reader
 
 preallo_rw_pattern_writer:
-	$(CC) -DWRITE iopat.c -o preallo_rw_pattern_writer
+	$(CC) $(GCFLAGS) $(LDFLAGS) -DWRITE iopat.c -o preallo_rw_pattern_writer
 
 ftrunc: ftrunc.o
 	$(LINKTEST)
-- 
1.6.1.1

From bharrosh@panasas.com Mon Feb  2 03:35:39 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_25
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n129ZcQa238487
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 03:35:39 -0600
X-ASG-Debug-ID: 1233567298-1c5f00130000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 1DBCB1BFF599; Mon,  2 Feb 2009 01:34:58 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id 8S46MkNUEHSzNwkP; Mon, 02 Feb 2009 01:34:58 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 2 Feb 2009 01:33:57 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.136]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 2 Feb 2009 04:33:56 -0500
Message-ID: <4986BE07.6090000@panasas.com>
Date: Mon, 02 Feb 2009 11:33:59 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@infradead.org>,
        Eric Sandeen <sandeen@sandeen.net>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com> <200902020131.04203.arnd@arndb.de> <4986AEE8.5040609@panasas.com> <Pine.LNX.4.64.0902020942230.11930@anakin>
In-Reply-To: <Pine.LNX.4.64.0902020942230.11930@anakin>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Feb 2009 09:33:56.0239 (UTC) FILETIME=[5E7851F0:01C98519]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233567299
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16793
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Geert Uytterhoeven wrote:
> On Mon, 2 Feb 2009, Boaz Harrosh wrote:
>> Arnd Bergmann wrote:
>>> No, the compiler is correct, it has to generate more complex code
>>> if it cannot assume that data is naturally aligned and the architecture
>>> does not support unaligned loads. If you don't understand this, please
>>> at least read the list archives about the last five times this came up
>>> before claiming that the compiler is broken.
>>>
>> Wrong!! Sorry, you guys don't listen.
>> I'm talking of the case where the structures are EXACTLY the same anyway
>> you look at them. sizeof(foo) == sizeof(foo_packed) and 
>> offsetof(foo_memmber) == offsetof(foo_packed_member) for every member of
>> the structure. foo && foo_packed are declared exactly the same but with
>> __attribute__((packed(1))) applied to the later.
>>
>> THEN in ia64 case the compiler is brain dead, because it relates
>> "unalignment" to packed(1) which are two different things.
> 
> The natural alignment of a structure is max(alignment(member)), for all
> members. With __attribute__((packed)), the natural alignment of the structure
> is 1, so the compiler cannot assume anything.
> 

No the natural alignment is what it is, after the application of
__attribute__((packed(1))). In a well defined structure that is a no-opt.
But yes in ai64 the gcc programmers got lazy and did not make that analysis
after laying out the structure.

> While the ints in the structure may still be at offsets 0, 4, 8, and so on,
> this doesn't say anything about their actual memory addresses, as the struct
> base address itself may be unaligned.
> 

The base address can be unaligned even if the structure is aligned. In that
case you need the __atrubute__((aligned)) thingy. It is true that if the sizeof(foo_packed)
is though unaligned, the compiler will have to assume unalignment in array operations.
but if the sizeof(foo_packed) is naturally aligned at the output then the compiler
has all the needed information to know that even if I declared __packed, it calculated
and knows that it is well aligned at the end.

> Gr{oetje,eeting}s,
> 
> 						Geert
> 

Please note that I gave up on the compiler and understand that the use of __packed
is dangerous in some cases, sigh. My standing point is to make sure there are no guesses
left, and a BUILD_BUG_ON to make sure of that.

Boaz

From mpatocka@redhat.com Mon Feb  2 12:08:43 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n12I8hJX001232
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 12:08:43 -0600
X-ASG-Debug-ID: 1233598083-7caa01bc0000-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 CD2A2DA33D
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 10:08:03 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id mDBn1oAwICUQUxUb for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 10:08:03 -0800 (PST)
X-ASG-Whitelist: Barracuda Reputation
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 n12HcGw0005859;
	Mon, 2 Feb 2009 12:38:42 -0500
Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34])
	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n12Hag1t013911;
	Mon, 2 Feb 2009 12:36:52 -0500
Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1])
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n12HaeoM019820;
	Mon, 2 Feb 2009 12:36:40 -0500
Received: from localhost (mpatocka@localhost)
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n12HaeT3019814;
	Mon, 2 Feb 2009 12:36:40 -0500
X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs
Date: Mon, 2 Feb 2009 12:36:40 -0500 (EST)
From: Mikulas Patocka <mpatocka@redhat.com>
X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com
To: Dave Chinner <david@fromorbit.com>
cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
In-Reply-To: <20090131235725.GA24173@disturbed>
Message-ID: <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com>
References: <20090113214949.GN8071@disturbed>
 <Pine.LNX.4.64.0901132324070.16396@hs20-bc2-1.build.redhat.com>
 <20090118173144.GA1999@infradead.org> <Pine.LNX.4.64.0901201430250.4603@hs20-bc2-1.build.redhat.com>
 <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org>
 <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com>
 <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com>
 <20090131235725.GA24173@disturbed>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 1233598083
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean



On Sun, 1 Feb 2009, Dave Chinner wrote:

> On Thu, Jan 29, 2009 at 11:39:00AM -0500, Mikulas Patocka wrote:
> > On Sat, 24 Jan 2009, Dave Chinner wrote:
> > > On Fri, Jan 23, 2009 at 03:14:30PM -0500, Mikulas Patocka wrote:
> > > > If I placed
> > > > xfs_sync_inodes(ip->i_mount, SYNC_DELWRI);
> > > > xfs_sync_inodes(ip->i_mount, SYNC_DELWRI | SYNC_IOWAIT);
> > > > directly to xfs_flush_device, I got lock dependency warning (though not a 
> > > > real deadlock).
> > > 
> > > Same reason memory reclaim gives lockdep warnings on XFS - we're
> > > recursing into operations that take inode locks while we currently
> > > hold an inode lock.  However, it shouldn't deadlock because
> > > we should ever try to take the iolock on the inode that we current
> > > hold it on.
> > > 
> > > > So synchronous flushing definitely needs some thinking and lock 
> > > > rearchitecting.
> > > 
> > > No, not at all. At most the grabbing of the iolock in
> > > xfs_sync_inodes_ag() needs to become a trylock....
> > 
> > You are wrong, the comments in the code are right. It really
> > deadlocks if it is modified to use synchronous wait for the end of
> > the flush and if the flush is done with xfs_sync_inodes:
> > 
> > xfssyncd      D 0000000000606808     0  4819      2
> > Call Trace:
> >  [0000000000606788] rwsem_down_failed_common+0x1ac/0x1d8
> >  [0000000000606808] rwsem_down_read_failed+0x24/0x34
> >  [0000000000606848] __down_read+0x30/0x40
> >  [0000000000468a64] down_read_nested+0x48/0x58
> >  [00000000100e6cc8] xfs_ilock+0x48/0x8c [xfs]
> >  [000000001011018c] xfs_sync_inodes_ag+0x17c/0x2dc [xfs]
> >  [000000001011034c] xfs_sync_inodes+0x60/0xc4 [xfs]
> >  [00000000101103c4] xfs_flush_device_work+0x14/0x2c [xfs]
> >  [000000001010ff1c] xfssyncd+0x110/0x174 [xfs]
> >  [000000000046556c] kthread+0x54/0x88
> >  [000000000042b2a0] kernel_thread+0x3c/0x54
> >  [00000000004653b8] kthreadd+0xac/0x160
> 
> So it is stuck:
> 
> 127                 /*
> 128                  * If we have to flush data or wait for I/O completion
> 129                  * we need to hold the iolock.
> 130                  */
> 131                 if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) {
> 132     >>>>>>>>            xfs_ilock(ip, XFS_IOLOCK_SHARED);
> 133                         lock_flags |= XFS_IOLOCK_SHARED;
> 134                         error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE);
> 135                         if (flags & SYNC_IOWAIT)
> 136                                 xfs_ioend_wait(ip);
> 137                 }
> 
> Given that we are stuck on the iolock in xfs_sync_inodes_ag(), I
> suspect you should re-read my comments above about "lock
> re-architecting" ;).

No, if you turn it into a trylock, it will randomly fail if any other 
process is holding the lock for whatever reason. So you will still get 
spurious -ENOSPCs, although with lower probability.

> If you make the xfs_ilock() there xfs_ilock_nowait() and avoid data
> writeback if we don't get the lock the deadlock goes away, right?

But that premature ENOSPC possibility will still exist.

The only right solution that I see is to drop this flushing code at all 
(because it's unfixable), catch -ENOSPCs exactly before you are about to 
return them to Linux VFS, flush at this point (you are not holding any 
locks here) and retry.

There seems to be more bugs with forgetting to flush delayed allocation 
--- you should flush delayed allocation after *every* failed allocate 
attempt, but the code flushes it only after failed delayed allocate 
attempt --- i.e. nondelayed allocators, such as xfs_iomap_write_direct 
(and maybe other places) will still return -ENOSPC without attempting to 
flush other inodes with delayed allocation.

Syncing should be really moved at the topmost place.

Mikulas

> BTW, can you post the patch you are working on?
> 
> Cheers,
> 
> Dave.

This is what I tried: I turned that 500ms wait into a completion:


Use xfs_sync_inodes and not sync_blockdev. sync_blockdev writes dirty 
metadata buffers, it doesn't touch inodes and pages at all.

Also, change that 500ms delay to a wait for completion, so that the
behavior is not dependent on magic timeout values. XFS developers insist
that it can't deadlock (I hope they're right).

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 fs/xfs/linux-2.6/xfs_sync.c |   25 +++++++++++++++++++------
 fs/xfs/linux-2.6/xfs_sync.h |    1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

Index: linux-2.6.29-rc3-devel/fs/xfs/linux-2.6/xfs_sync.c
===================================================================
--- linux-2.6.29-rc3-devel.orig/fs/xfs/linux-2.6/xfs_sync.c	2009-01-29 15:49:25.000000000 +0100
+++ linux-2.6.29-rc3-devel/fs/xfs/linux-2.6/xfs_sync.c	2009-01-29 16:57:53.000000000 +0100
@@ -389,12 +389,15 @@ xfs_quiesce_attr(
  * - It saves on stack space, which is tight in certain situations
  * - It can be used (with care) as a mechanism to avoid deadlocks.
  * Flushing while allocating in a full filesystem requires both.
+ *
+ * Dave Chinner claims that the deadlock can't happen. -- mikulas
  */
 STATIC void
 xfs_syncd_queue_work(
 	struct xfs_mount *mp,
 	void		*data,
-	void		(*syncer)(struct xfs_mount *, void *))
+	void		(*syncer)(struct xfs_mount *, void *),
+	struct completion *completion)
 {
 	struct bhv_vfs_sync_work *work;
 
@@ -403,6 +406,7 @@ xfs_syncd_queue_work(
 	work->w_syncer = syncer;
 	work->w_data = data;
 	work->w_mount = mp;
+	work->w_completion = completion;
 	spin_lock(&mp->m_sync_lock);
 	list_add_tail(&work->w_list, &mp->m_sync_list);
 	spin_unlock(&mp->m_sync_lock);
@@ -415,6 +419,7 @@ xfs_syncd_queue_work(
  * has failed with ENOSPC and we are in the process of scratching our
  * heads, looking about for more room...
  */
+#if 0
 STATIC void
 xfs_flush_inode_work(
 	struct xfs_mount *mp,
@@ -424,16 +429,20 @@ xfs_flush_inode_work(
 	filemap_flush(inode->i_mapping);
 	iput(inode);
 }
+#endif
 
 void
 xfs_flush_inode(
 	xfs_inode_t	*ip)
 {
+#if 0
 	struct inode	*inode = VFS_I(ip);
+	DECLARE_COMPLETION_ONSTACK(completion);
 
 	igrab(inode);
-	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
-	delay(msecs_to_jiffies(500));
+	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work, &completion);
+	wait_for_completion(&completion);
+#endif
 }
 
 /*
@@ -446,7 +455,7 @@ xfs_flush_device_work(
 	void		*arg)
 {
 	struct inode	*inode = arg;
-	sync_blockdev(mp->m_super->s_bdev);
+	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_IOWAIT);
 	iput(inode);
 }
 
@@ -455,10 +464,11 @@ xfs_flush_device(
 	xfs_inode_t	*ip)
 {
 	struct inode	*inode = VFS_I(ip);
+	DECLARE_COMPLETION_ONSTACK(completion);
 
 	igrab(inode);
-	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work);
-	delay(msecs_to_jiffies(500));
+	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work, &completion);
+	wait_for_completion(&completion);
 	xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC);
 }
 
@@ -526,6 +536,8 @@ xfssyncd(
 		list_for_each_entry_safe(work, n, &tmp, w_list) {
 			(*work->w_syncer)(mp, work->w_data);
 			list_del(&work->w_list);
+			if (work->w_completion)
+				complete(work->w_completion);
 			if (work == &mp->m_sync_work)
 				continue;
 			kmem_free(work);
@@ -541,6 +553,7 @@ xfs_syncd_init(
 {
 	mp->m_sync_work.w_syncer = xfs_sync_worker;
 	mp->m_sync_work.w_mount = mp;
+	mp->m_sync_work.w_completion = NULL;
 	mp->m_sync_task = kthread_run(xfssyncd, mp, "xfssyncd");
 	if (IS_ERR(mp->m_sync_task))
 		return -PTR_ERR(mp->m_sync_task);
Index: linux-2.6.29-rc3-devel/fs/xfs/linux-2.6/xfs_sync.h
===================================================================
--- linux-2.6.29-rc3-devel.orig/fs/xfs/linux-2.6/xfs_sync.h	2009-01-29 15:52:28.000000000 +0100
+++ linux-2.6.29-rc3-devel/fs/xfs/linux-2.6/xfs_sync.h	2009-01-29 15:52:56.000000000 +0100
@@ -25,6 +25,7 @@ typedef struct bhv_vfs_sync_work {
 	struct xfs_mount	*w_mount;
 	void			*w_data;	/* syncer routine argument */
 	void			(*w_syncer)(struct xfs_mount *, void *);
+	struct completion	*w_completion;
 } bhv_vfs_sync_work_t;
 
 #define SYNC_ATTR		0x0001	/* sync attributes */

From sandeen@sandeen.net Mon Feb  2 14:17:12 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n12KHCQf008581
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 14:17:12 -0600
X-ASG-Debug-ID: 1233605791-7007031c0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id AE00418A2EDF
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 12:16:31 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id SvrK66rLANDyNYRv for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 12:16:31 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n12KGFR0019475;
	Mon, 2 Feb 2009 15:16:17 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n12KGFOY021524;
	Mon, 2 Feb 2009 15:16:15 -0500
Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n12KGB6F012521;
	Mon, 2 Feb 2009 15:16:14 -0500
Message-ID: <4987548A.1070809@sandeen.net>
Date: Mon, 02 Feb 2009 14:16:10 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: =?UTF-8?B?QXJrYWRpdXN6IE1pxZtraWV3aWN6?= <arekm@maven.pl>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
Subject: Re: [PATCH] xfstests: Fix *FLAGS passing and dependencies.
References: <1233565776-563-1-git-send-email-arekm@maven.pl>
In-Reply-To: <1233565776-563-1-git-send-email-arekm@maven.pl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233605792
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16833
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Arkadiusz Miśkiewicz wrote:
> Pass *FLAGS in some targets.
> 
> Drop LIBHANDLE, LIBATTR and LIBACL from deps since there are in form
> "-llibrary".

ugh, weird.

> 
> Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>

Looks fine to me.  I'll merge it to the kernel.org repo.

-Eric

> ---
>  src/Makefile |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/src/Makefile b/src/Makefile
> index ad4c204..634e1b3 100644
> --- a/src/Makefile
> +++ b/src/Makefile
> @@ -58,10 +58,10 @@ genhashnames: genhashnames.o
>  nametest: nametest.o $(LIBTEST)
>  	$(LINKTEST) $(LIBTEST) $(LDLIBS)
>  
> -bstat: bstat.o $(LIBHANDLE)
> +bstat: bstat.o
>  	$(LINKTEST) $(LIBHANDLE) $(LDLIBS)
>  
> -t_immutable: t_immutable.o $(LIBHANDLE) $(LIBACL)
> +t_immutable: t_immutable.o
>  	$(LINKTEST) $(LIBACL) $(LIBHANDLE) $(LDLIBS)
>  
>  loggen:	loggen.o
> @@ -82,17 +82,17 @@ multi_open_unlink: multi_open_unlink.o
>  #scaleread: scaleread.o $(LDLIBS)
>  #	$(LINKTEST)
>  
> -acl_get: acl_get.o $(LIBACL) $(LIBATTR)
> +acl_get: acl_get.o
>  	$(LINKTEST) $(LIBACL) $(LIBATTR) $(LDLIBS)
>  
> -dmiperf: dmiperf.o $(LIBATTR)
> +dmiperf: dmiperf.o
>  	$(LINKTEST) $(LIBATTR) $(LDLIBS)
>  
>  preallo_rw_pattern_reader:
> -	$(CC) -DREAD iopat.c -o preallo_rw_pattern_reader
> +	$(CC) $(GCFLAGS) $(LDFLAGS) -DREAD iopat.c -o preallo_rw_pattern_reader
>  
>  preallo_rw_pattern_writer:
> -	$(CC) -DWRITE iopat.c -o preallo_rw_pattern_writer
> +	$(CC) $(GCFLAGS) $(LDFLAGS) -DWRITE iopat.c -o preallo_rw_pattern_writer
>  
>  ftrunc: ftrunc.o
>  	$(LINKTEST)
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

From jamie@shareable.org Mon Feb  2 14:53:24 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n12KrNv7010329
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 14:53:24 -0600
X-ASG-Debug-ID: 1233607963-15b4023f0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mail2.shareable.org (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 21D45DB31C; Mon,  2 Feb 2009 12:52:43 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by cuda.sgi.com with ESMTP id ESIuCAAHBKA3tb8g; Mon, 02 Feb 2009 12:52:43 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63)
	(envelope-from <jamie@shareable.org>)
	id 1LU5l0-0000F6-HP; Mon, 02 Feb 2009 20:51:02 +0000
Date: Mon, 2 Feb 2009 20:51:02 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        Christoph Hellwig <hch@infradead.org>,
        Eric Sandeen <sandeen@sandeen.net>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Message-ID: <20090202205102.GG28129@shareable.org>
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com> <200902020131.04203.arnd@arndb.de> <4986AEE8.5040609@panasas.com> <Pine.LNX.4.64.0902020942230.11930@anakin> <4986BE07.6090000@panasas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4986BE07.6090000@panasas.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Barracuda-Connect: mail2.shareable.org[80.68.89.115]
X-Barracuda-Start-Time: 1233607964
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16836
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Boaz Harrosh wrote:
> No the natural alignment is what it is, after the application of
> __attribute__((packed(1))). In a well defined structure that is a no-opt.
> But yes in ai64 the gcc programmers got lazy and did not make that analysis
> after laying out the structure.

No.  That's what you *want* packed to mean, but it doesn't mean that.

__attribute__ packed on a struct definition means to pack the
structure _and_ set its assumed alignment to 1.

This is what the packed attribute historically means, and it cannot be
changed without breaking existing code.

If you want to remove padding from a structure, but still keep its
natural alignment, you do it with two attributes together:
__attribute__((packed, aligned(4))).  You have to choose the alignment
you want in that case.

GCC manual:
     When used on a struct, or struct member, the `aligned' attribute
     can only increase the alignment; in order to decrease it, the
     `packed' attribute must be specified as well.  When used as part
     of a typedef, the `aligned' attribute can both increase and
     decrease alignment, and specifying the `packed' attribute will
     generate a warning.

It's a counterintuitive, because you must use
__attribute__((aligned(1))) when declaring a variable to reduce its
alignment, but you must use __attribute__((packed)) when declaring a
struct type.  Doing it at the end of a struct typedef is a weird mix
of semantics, so don't do that.

By the way, this discussion is why the "-Wpacked" and "-Wpadding"
options are available.

> The base address can be unaligned even if the structure is aligned. In that
> case you need the __atrubute__((aligned)) thingy.

No, because __attribute__((packed)) on a struct doesn't mean what you
want it to mean.  Use __attribute((packed,aligned(4))) if that's what
you want.

> Please note that I gave up on the compiler and understand that the
> use of __packed is dangerous in some cases, sigh. My standing point
> is to make sure there are no guesses left, and a BUILD_BUG_ON to
> make sure of that.

In this code, it's not a bug because it must be backward compatible
with existing binary code.  "Fixing" the padding breaks
compatibility, which is pointless for this patch.

-- Jamie

From michael.monnerie@is.it-management.at Mon Feb  2 19:24:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n131O43w023476
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 19:24:05 -0600
X-ASG-Debug-ID: 1233624202-6bcc03560000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id E0E0718A4E83
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 17:23:23 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id UZWUUEVUBtANqxG6 for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 17:23:23 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 86EDE3BA9
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 02:22:49 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id A887640016F
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 02:22:48 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Tue, 3 Feb 2009 02:22:47 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090131105712.GA30061@infradead.org>
In-Reply-To: <20090131105712.GA30061@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902030222.47644@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233624203
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16854
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Samstag 31 Januar 2009 Christoph Hellwig wrote:
> This looks like you were running with a write back cache enabled on
> the controller / disks but without barriers.

I've read that this is dangerous. How can I tell if I suffer the same? I 
use an Areca 1680 SAS RAID Controller with 2GB Cache, so there could be 
a lot of writes in it.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From david@fromorbit.com Mon Feb  2 21:30:28 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n133URoK030221
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 21:30:27 -0600
X-ASG-Debug-ID: 1233631785-383402010000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id B24FBDD19A
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 19:29:46 -0800 (PST)
Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id nZF9g1jKtF1Lnzmc for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 19:29:46 -0800 (PST)
Received: from ppp121-44-157-170.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.157.170])
  by ipmail05.adl2.internode.on.net with ESMTP; 03 Feb 2009 13:58:28 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUBwq-0007yL-SQ; Tue, 03 Feb 2009 14:27:40 +1100
Date: Tue, 3 Feb 2009 14:27:40 +1100
From: Dave Chinner <david@fromorbit.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
Message-ID: <20090203032740.GG24173@disturbed>
Mail-Followup-To: Mikulas Patocka <mpatocka@redhat.com>,
	Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
	linux-kernel@vger.kernel.org
References: <20090118173144.GA1999@infradead.org> <Pine.LNX.4.64.0901201430250.4603@hs20-bc2-1.build.redhat.com> <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com> <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com> <20090131235725.GA24173@disturbed> <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145]
X-Barracuda-Start-Time: 1233631787
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16862
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Mon, Feb 02, 2009 at 12:36:40PM -0500, Mikulas Patocka wrote:
> On Sun, 1 Feb 2009, Dave Chinner wrote:
> > On Thu, Jan 29, 2009 at 11:39:00AM -0500, Mikulas Patocka wrote:
> > > On Sat, 24 Jan 2009, Dave Chinner wrote:
> > > > On Fri, Jan 23, 2009 at 03:14:30PM -0500, Mikulas Patocka wrote:
> > > > > If I placed
> > > > > xfs_sync_inodes(ip->i_mount, SYNC_DELWRI);
> > > > > xfs_sync_inodes(ip->i_mount, SYNC_DELWRI | SYNC_IOWAIT);
> > > > > directly to xfs_flush_device, I got lock dependency warning (though not a 
> > > > > real deadlock).
> > > > 
> > > > Same reason memory reclaim gives lockdep warnings on XFS - we're
> > > > recursing into operations that take inode locks while we currently
> > > > hold an inode lock.  However, it shouldn't deadlock because
> > > > we should ever try to take the iolock on the inode that we current
> > > > hold it on.
> > > > 
> > > > > So synchronous flushing definitely needs some thinking and lock 
> > > > > rearchitecting.
> > > > 
> > > > No, not at all. At most the grabbing of the iolock in
> > > > xfs_sync_inodes_ag() needs to become a trylock....
> > > 
> > > You are wrong, the comments in the code are right. It really
> > > deadlocks if it is modified to use synchronous wait for the end of
> > > the flush and if the flush is done with xfs_sync_inodes:
....
> > So it is stuck:
> > 
> > 127                 /*
> > 128                  * If we have to flush data or wait for I/O completion
> > 129                  * we need to hold the iolock.
> > 130                  */
> > 131                 if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) {
> > 132     >>>>>>>>            xfs_ilock(ip, XFS_IOLOCK_SHARED);
> > 133                         lock_flags |= XFS_IOLOCK_SHARED;
> > 134                         error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE);
> > 135                         if (flags & SYNC_IOWAIT)
> > 136                                 xfs_ioend_wait(ip);
> > 137                 }
> > 
> > Given that we are stuck on the iolock in xfs_sync_inodes_ag(), I
> > suspect you should re-read my comments above about "lock
> > re-architecting" ;).
> 
> No, if you turn it into a trylock, it will randomly fail if any other 
> process is holding the lock for whatever reason. So you will still get 
> spurious -ENOSPCs, although with lower probability.

The flush is never, ever going to be perfect. While we are blocking
waiting for the flush, other concurrent writes could be doing more
delayed allocation. The flush won't catch these, so we can still get
spurious ENOSPCs even with a *perfect* flush.

Hence there is no point in trying to make the code perfect - we
can look at more complex solutions if and only if the simple
solution is not sufficient.

> > If you make the xfs_ilock() there xfs_ilock_nowait() and avoid data
> > writeback if we don't get the lock the deadlock goes away, right?
> 
> But that premature ENOSPC possibility will still exist.
> The only right solution that I see is to drop this flushing code at all 
> (because it's unfixable), catch -ENOSPCs exactly before you are about to 
> return them to Linux VFS, flush at this point (you are not holding any 
> locks here) and retry.

Still not perfect as soon as you consider concurrency (as per above).

> There seems to be more bugs with forgetting to flush delayed allocation 
> --- you should flush delayed allocation after *every* failed allocate 
> attempt, but the code flushes it only after failed delayed allocate 
> attempt --- i.e. nondelayed allocators, such as xfs_iomap_write_direct 
> (and maybe other places) will still return -ENOSPC without attempting to 
> flush other inodes with delayed allocation.

xfs_iomap_write_direct() is for direct IO, and if that fails due to
ENOSPC, we're going to return the error rather than try to flush
delayed allocation blocks. Users of direct IO care more about
deterministic response than trying to use every last byte of the
filesystem. Such users also don't tend to mix buffered writes
(hence delayed allocation) and direct IO on the same filesystem
precisely because of the non-deterministic nature of buffered IO.
Hence we don't flush here.

xfs_iomap_write_allocate() does the allocation of delayed extents,
which we've already guaranteed that there is space for due to the
flushing in xfs_iomap_write_delay(). Hence we don't flush here,
either.

For metadata allocations (all over the place), we take a reservation
first and so we could trigger a flush in certain circumstances if
the reservation fails (to avoid recursion and transaction subsystem
deadlocks). However, if you are not getting spurious enospc on
creating inodes (as opposed to writing to them) then I see no
immediate need for flushes there, either....

> Syncing should be really moved at the topmost place.

This can only be considered a best effort flush, not a sync.

> This is what I tried: I turned that 500ms wait into a completion:
> 
> 
> Use xfs_sync_inodes and not sync_blockdev. sync_blockdev writes dirty 
> metadata buffers, it doesn't touch inodes and pages at all.
> 
> Also, change that 500ms delay to a wait for completion, so that the
> behavior is not dependent on magic timeout values. XFS developers insist
> that it can't deadlock (I hope they're right).
> 
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
.....
> @@ -415,6 +419,7 @@ xfs_syncd_queue_work(
>   * has failed with ENOSPC and we are in the process of scratching our
>   * heads, looking about for more room...
>   */
> +#if 0
>  STATIC void
>  xfs_flush_inode_work(
>  	struct xfs_mount *mp,
> @@ -424,16 +429,20 @@ xfs_flush_inode_work(
>  	filemap_flush(inode->i_mapping);
>  	iput(inode);
>  }
> +#endif
>  
>  void
>  xfs_flush_inode(
>  	xfs_inode_t	*ip)
>  {
> +#if 0
>  	struct inode	*inode = VFS_I(ip);
> +	DECLARE_COMPLETION_ONSTACK(completion);
>  
>  	igrab(inode);
> -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
> -	delay(msecs_to_jiffies(500));
> +	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work, &completion);
> +	wait_for_completion(&completion);
> +#endif

Why did you turn off the initial inode flush?

>  }
>  
>  /*
> @@ -446,7 +455,7 @@ xfs_flush_device_work(
>  	void		*arg)
>  {
>  	struct inode	*inode = arg;
> -	sync_blockdev(mp->m_super->s_bdev);
> +	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_IOWAIT);
>  	iput(inode);

This should be:

	xfs_sync_inodes(mp, SYNC_DELWRI);
	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_IOWAIT);

As it will flush the inodes asynchronously and then the second
pass will wait for all the IO to complete. That will be much
more efficient than synchronous flushing.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From sandeen@sandeen.net Mon Feb  2 21:49:15 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n133nEcS031167
	for <xfs@oss.sgi.com>; Mon, 2 Feb 2009 21:49:15 -0600
X-ASG-Debug-ID: 1233632914-29ab026b0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 5821C18AB207
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 19:48:34 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id v9sTgqSJFgWjN93i for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 19:48:34 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n133DwCa032138;
	Mon, 2 Feb 2009 22:13:58 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n133DwCV022649;
	Mon, 2 Feb 2009 22:13:58 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n133Dugq011359;
	Mon, 2 Feb 2009 22:13:57 -0500
Message-ID: <4987B673.8030406@sandeen.net>
Date: Mon, 02 Feb 2009 21:13:55 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Michael Monnerie <michael.monnerie@is.it-management.at>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
References: <498376CF.8020806@renderforce.de>	<20090131105712.GA30061@infradead.org> <200902030222.47644@zmi.at>
In-Reply-To: <200902030222.47644@zmi.at>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233632915
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16862
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Michael Monnerie wrote:
> On Samstag 31 Januar 2009 Christoph Hellwig wrote:
>> This looks like you were running with a write back cache enabled on
>> the controller / disks but without barriers.
> 
> I've read that this is dangerous. How can I tell if I suffer the same? I 
> use an Areca 1680 SAS RAID Controller with 2GB Cache, so there could be 
> a lot of writes in it.
> 
> mfg zmi

you'd need to read the docs for your controller, to find out how to tell
if it has a writeback cache enabled, and whether it is batter-backed or not.

-Eric

From nscott@aconex.com Tue Feb  3 00:11:33 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_41
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n136BWSH039564
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 00:11:33 -0600
X-ASG-Debug-ID: 1233641451-4e9500500000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from postoffice2.aconex.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 8C0CADD893
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 22:10:51 -0800 (PST)
Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id skRupEg7KZilEoYI for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 22:10:51 -0800 (PST)
Received: from postoffice.aconex.com (localhost [127.0.0.1])
	by postoffice2.aconex.com (Spam Firewall) with ESMTP id 8F05E84C5E
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:10:50 +1100 (EST)
Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id e3I0pX4e2weibMUP for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:10:50 +1100 (EST)
Received: from [192.168.5.24] (melho0.aconex.com [203.89.192.141])
	by postoffice.aconex.com (Postfix) with ESMTP id 677B392C312
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:10:50 +1100 (EST)
X-ASG-Orig-Subj: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Subject: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
From: Nathan Scott <nscott@aconex.com>
To: xfs@oss.sgi.com
Content-Type: text/plain
Date: Tue, 03 Feb 2009 17:07:36 +1100
Message-Id: <1233641256.5518.83.camel@verge.scott.net.au>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: mail.aconex.com[203.89.202.182]
X-Barracuda-Start-Time: 1233641453
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16872
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Is this issue known (Eric?) in 2.10.2?

thanks!

-------- Forwarded Message --------
From: TANIGUCHI Takaki <takaki@asis.media-as.org>
Reply-To: TANIGUCHI Takaki <takaki@asis.media-as.org>,
513821@bugs.debian.org
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#513821: xfsprogs: xfs_growfs does not work
Date: Sun, 01 Feb 2009 23:43:27 +0900

Package: xfsprogs
Version: 2.10.2-1
Severity: important

xfs_growfs does not work. But when I use i686 kernel, xfs_growfs work fine.

/# LANG=C xfs_growfs /home
meta-data=/dev/mapper/vgraid-home isize=256    agcount=16, agsize=163840 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=65536  blocks=0, rtextents=0
xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Invalid argument
data blocks changed from 2621440 to 0
inode max percent changed from 25 to 0
log blocks changed from 2560 to 0
log changed from internal to external
realtime extent size changed from 16 to 0
/# 


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xfsprogs depends on:
ii  libc6                         2.7-18     GNU C Library: Shared libraries
ii  libreadline5                  5.2-3.1    GNU readline and history libraries
ii  libuuid1                      1.41.3-1   universally unique id library

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
pn  attr                          <none>     (no description available)
pn  dvhtool                       <none>     (no description available)
pn  quota                         <none>     (no description available)
ii  xfsdump                       2.2.48-1   Administrative utilities for the X

-- no debconf information



From nscott@aconex.com Tue Feb  3 00:12:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n136Cq20039727
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 00:12:53 -0600
X-ASG-Debug-ID: 1233641532-776e02990000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from postoffice2.aconex.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 93D66DD89B
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 22:12:13 -0800 (PST)
Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id pTioQTMfDzj4J2dd for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 22:12:13 -0800 (PST)
Received: from postoffice.aconex.com (localhost [127.0.0.1])
	by postoffice2.aconex.com (Spam Firewall) with ESMTP id B224784CC1
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:12:10 +1100 (EST)
Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id b6rFyVLk2hGkvFqc for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:12:10 +1100 (EST)
Received: from [192.168.5.24] (melho0.aconex.com [203.89.192.141])
	by postoffice.aconex.com (Postfix) with ESMTP id 81BF292C312
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:12:10 +1100 (EST)
X-ASG-Orig-Subj: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Subject: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
From: Nathan Scott <nscott@aconex.com>
To: xfs@oss.sgi.com
In-Reply-To: <1233641256.5518.83.camel@verge.scott.net.au>
References: <1233641256.5518.83.camel@verge.scott.net.au>
Content-Type: text/plain
Date: Tue, 03 Feb 2009 17:08:56 +1100
Message-Id: <1233641336.5518.85.camel@verge.scott.net.au>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: mail.aconex.com[203.89.202.182]
X-Barracuda-Start-Time: 1233641533
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16872
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, 2009-02-03 at 17:07 +1100, Nathan Scott wrote:
> Is this issue known (Eric?) in 2.10.2?

and "Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)" to save ya looking.

thanks!

--
Nathan

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 00:21:18 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n136LHY0040831
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 00:21:18 -0600
X-ASG-Debug-ID: 1233642038-4ea300590000-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 69073DD7B7
	for <xfs@oss.sgi.com>; Mon,  2 Feb 2009 22:20:38 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 3fiTYPAyz6fj332B for <xfs@oss.sgi.com>; Mon, 02 Feb 2009 22:20:38 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUEeC-00080k-Jc; Tue, 03 Feb 2009 06:20:36 +0000
Date: Tue, 3 Feb 2009 01:20:36 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nathan Scott <nscott@aconex.com>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Subject: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Message-ID: <20090203062036.GA23098@infradead.org>
References: <1233641256.5518.83.camel@verge.scott.net.au> <1233641336.5518.85.camel@verge.scott.net.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1233641336.5518.85.camel@verge.scott.net.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233642038
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 05:08:56PM +1100, Nathan Scott wrote:
> On Tue, 2009-02-03 at 17:07 +1100, Nathan Scott wrote:
> > Is this issue known (Eric?) in 2.10.2?
> 
> and "Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)" to save ya looking.

2.6.16 didn't have the compat ioctl handler for growfs yet, and this is
i386 xfsprogs on a 64bit kernel.  He needs to upgrade to a more recent
kernel.

From bharrosh@panasas.com Tue Feb  3 01:31:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n137VqNM044337
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 01:31:52 -0600
X-ASG-Debug-ID: 1233646270-4e9e01340000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from laguna.int.panasas.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 4639CDD2C0; Mon,  2 Feb 2009 23:31:11 -0800 (PST)
Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by cuda.sgi.com with ESMTP id xjKVef9aadtjliob; Mon, 02 Feb 2009 23:31:11 -0800 (PST)
Received: from daytona.int.panasas.com ([172.17.28.41]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 2 Feb 2009 23:31:10 -0800
Received: from bh-buildlin2.bhalevy.com ([172.17.28.140]) by daytona.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 3 Feb 2009 02:31:08 -0500
Message-ID: <4987F2B8.9070700@panasas.com>
Date: Tue, 03 Feb 2009 09:31:04 +0200
From: Boaz Harrosh <bharrosh@panasas.com>
User-Agent: Thunderbird/3.0a2 (X11; 2008072418)
MIME-Version: 1.0
To: Jamie Lokier <jamie@shareable.org>
CC: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        Christoph Hellwig <hch@infradead.org>,
        Eric Sandeen <sandeen@sandeen.net>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs
 for compatibility with legacy xfs ioctls
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com> <200902020131.04203.arnd@arndb.de> <4986AEE8.5040609@panasas.com> <Pine.LNX.4.64.0902020942230.11930@anakin> <4986BE07.6090000@panasas.com> <20090202205102.GG28129@shareable.org>
In-Reply-To: <20090202205102.GG28129@shareable.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Feb 2009 07:31:08.0286 (UTC) FILETIME=[613DA9E0:01C985D1]
X-Barracuda-Connect: gw-ca.panasas.com[66.104.249.162]
X-Barracuda-Start-Time: 1233646273
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16878
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Jamie Lokier wrote:
> Boaz Harrosh wrote:
>> No the natural alignment is what it is, after the application of
>> __attribute__((packed(1))). In a well defined structure that is a no-opt.
>> But yes in ai64 the gcc programmers got lazy and did not make that analysis
>> after laying out the structure.
> 
> No.  That's what you *want* packed to mean, but it doesn't mean that.
> 
> __attribute__ packed on a struct definition means to pack the
> structure _and_ set its assumed alignment to 1.
> 
> This is what the packed attribute historically means, and it cannot be
> changed without breaking existing code.
> 
> If you want to remove padding from a structure, but still keep its
> natural alignment, you do it with two attributes together:
> __attribute__((packed, aligned(4))).  You have to choose the alignment
> you want in that case.
> 
> GCC manual:
>      When used on a struct, or struct member, the `aligned' attribute
>      can only increase the alignment; in order to decrease it, the
>      `packed' attribute must be specified as well.  When used as part
>      of a typedef, the `aligned' attribute can both increase and
>      decrease alignment, and specifying the `packed' attribute will
>      generate a warning.
> 
> It's a counterintuitive, because you must use
> __attribute__((aligned(1))) when declaring a variable to reduce its
> alignment, but you must use __attribute__((packed)) when declaring a
> struct type.  Doing it at the end of a struct typedef is a weird mix
> of semantics, so don't do that.
> 
> By the way, this discussion is why the "-Wpacked" and "-Wpadding"
> options are available.
> 
>> The base address can be unaligned even if the structure is aligned. In that
>> case you need the __atrubute__((aligned)) thingy.
> 
> No, because __attribute__((packed)) on a struct doesn't mean what you
> want it to mean.  Use __attribute((packed,aligned(4))) if that's what
> you want.
> 

OK Thanks I'll use that then. 
(And BUILD_BUG_ON to make sure)

>> Please note that I gave up on the compiler and understand that the
>> use of __packed is dangerous in some cases, sigh. My standing point
>> is to make sure there are no guesses left, and a BUILD_BUG_ON to
>> make sure of that.
> 
> In this code, it's not a bug because it must be backward compatible
> with existing binary code.  "Fixing" the padding breaks
> compatibility, which is pointless for this patch.
> 

That's what I don't like. In compatibility problems situation, we actually
have two kind of structures. I rather that they are spelled out explicitly
and chosen from at the appropriate places. But I'll give up it is probably
just me. (Though proof that it was not me who raised the subject)

I would at least expect a big fat comment explaining what happened to the
structure on what known ARCHs, and how it is expected to look in memory.
And a BUILD_BUG_ON to make sure of that.

> -- Jamie

Thanks, the __attribute((packed,aligned(__WORD_SIZE))) is new for me

Boaz

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 02:09:56 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1389tgl046104
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 02:09:56 -0600
X-ASG-Debug-ID: 1233648556-0b1601da0000-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 EDC9F18ACEE3
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 00:09:16 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 5vhM59peqPcMNb1t for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 00:09:16 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUGLM-0003I0-0m; Tue, 03 Feb 2009 08:09:16 +0000
Date: Tue, 3 Feb 2009 03:09:16 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: XFS status update for January 2009
Subject: XFS status update for January 2009
Message-ID: <20090203080915.GA8921@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233648556
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

January has been an extremely busy month on the userspace front.  Many
smaller and medium updates went into xfsprogs, xfstests and to a lesser
extent xfsdump.  xfsprogs and xfsdump are ramping up for getting a 3.0.0
release out in early February which will include the first major re-sync
with the kernel code in libxfs, a cleanup of the exported library interfaces
and the move of two tools (xfs_fsr and xfs_estimate) from the xfsdump
package to xfsprogs.  After this the xfsprogs package will contain all
tools that use internal libxfs interfaces which fortunately equates to those
needed for normal administration.  The xfsdump package now only contains
the xfsdump/xfsrestore tools needed for backing up and restoring XFS
filesystems.  In addition it grew a fix to support dump/restore on systems
with a 64k page size.  A large number of acl/attr package patches was
posted to the list, but pending a possible split of these packages from the
XFS project these weren't processed yet.

On the kernel side the big excitement in January was an in-memory corruption
introduced in the btree refactoring which hit people running 32bit platforms
without support for large block devices.  This issue was fixed and pushed
to the 2.6.29 development tree after a long collaborative debugging effort
at linux.conf.au.  Besides that about a dozen minor fixes were pushed to
2.6.29 and the first batch of misc patches for the 2.6.30 release cycle
was sent out.

At the end of December the SGI group in Melbourne which the previous
XFS maintainer and some other developers worked for has been closed down
and they will be missed greatly.  As a result maintainership has been passed
on in a way that has been slightly controversial in the community, and the
first patchset of work in progress in Melbourne have been posted to the list
to be picked up by others.

The xfs.org wiki has gotten a little facelift on it's front page making it
a lot easier to read.

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 03:05:21 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1395LBs048513
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 03:05:21 -0600
X-ASG-Debug-ID: 1233651881-4e9302c80000-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 13E52DDC28
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 01:04:41 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id cLfDEYoWwng4hbFY for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 01:04:41 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUHCz-0000zJ-6E
	for xfs@oss.sgi.com; Tue, 03 Feb 2009 09:04:41 +0000
Date: Tue, 3 Feb 2009 04:04:41 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: a crude release script
Subject: a crude release script
Message-ID: <20090203090441.GA24337@infradead.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233651882
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

This is a little script to cut xfsprogs/xfsdump/dmapi releases.  It's
first argument is the respoitory and the second one a temporary
directory.  It should be used on a pristine git repository, and the
version commit and tag need to be pushed out manually.

And yes, this is a hint that we should cut the 3.0.0 releases of
xfsprogs/xfsdump now :)



--cWoXeonUoKmBZSoM
Content-Type: application/x-sh
Content-Disposition: attachment; filename="release.sh"
Content-Transfer-Encoding: quoted-printable

#!/bin/sh=0A#=0A# Script to automate releasing xfsprogs/xfsdump/dmapi=0A#=
=0A# First argument is the git checked out repository of the module to be=
=0A# released. Second argument is a temporary directory.=0A#=0A=0Agitdir=3D=
$1=0Atmpdir=3D$2=0A=0Aif [ "$gitdir" =3D "xfsprogs" -o "$gitdir" =3D "xfspr=
ogs-dev" ]; then=0A    pkg=3D"xfsprogs"=0Aelif [ "$gitdir" =3D "xfsdump" -o=
 "$gitdir" =3D "xfsdump-dev" ]; then=0A    pkg=3D"xfsdump"=0Aelif [ "$gitdi=
r" =3D "dmapi" -o "$gitdir" =3D "dmapi-dev" ]; then=0A    pkg=3D"dmapi"=0Ae=
lse=0A    echo "Invalid package \"$gitdir\"" >&2=0A    exit 1=0Afi=0A=0Aif =
[ -z "$tmpdir" ]; then=0A    echo "usage: $0 module tmpdir" 2>&1=0A    exit=
 1=0Afi=0A=0A. ${gitdir}/VERSION=0A=0Aversion=3D${PKG_MAJOR}.${PKG_MINOR}.$=
{PKG_REVISION}=0Adistdir=3D${pkg}-${version}=0Atarfile=3D${pkg}-${version}.=
tar.gz=0A=0Adate=3D`date +"%-d %B %Y"`=0A=0Aif [ -e ${tmpdir}/${distdir} ];=
 then=0A    echo "${tmpdir}/${distdir} already exists" 2>&1=0A    exit 1=0A=
fi=0A=0Aif [ -e ${tmpdir}/${tarfile} ]; then=0A    echo "${tmpdir}/${tarfil=
e} already exists" 2>&1=0A    exit 1=0Afi=0A=0Aecho "Updating CHANGES"=0Acp=
 $gitdir/doc/CHANGES $tmpdir/CHANGES=0Acat $tmpdir/CHANGES | sed "s/${distd=
ir}.*/${distdir} (${date})/" > $gitdir/doc/CHANGES=0A=0Aecho "Creating ${tm=
pdir}/${distdir}"=0A=0Acp -a $gitdir $tmpdir/$distdir=0Arm -rf $tmpdir/$dis=
tdir/.git=0A=0Aecho "Creating ${tmpdir}/${tarfile}"=0A(cd ${tmpdir} && tar =
chozf ${tarfile} ${distdir})=0A=0Aecho "Removing ${tmpdir}/${distdir}"=0Arm=
 -rf $tmpdir/$distdir/=0A=0Aecho "Commit CHANGES update to git"=0A(cd $gitd=
ir && git-commit -a -m "${version} release")=0A=0Aecho "Tagging git reposit=
ory"=0A(cd $gitdir && git-tag v{$version})=0A
--cWoXeonUoKmBZSoM--

From michael.monnerie@is.it-management.at Tue Feb  3 03:23:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n139Nq09050424
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 03:23:53 -0600
X-ASG-Debug-ID: 1233652989-1bb300b20000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id CF37418AD04A
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 01:23:10 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id ZiAHKSefcFIlDZNW for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 01:23:10 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 4761D3CB8
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 10:22:39 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id EA2F540016F
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 10:22:38 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Tue, 3 Feb 2009 10:22:38 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <200902030222.47644@zmi.at> <4987B673.8030406@sandeen.net>
In-Reply-To: <4987B673.8030406@sandeen.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902031022.38583@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233652990
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16885
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Dienstag 03 Februar 2009 Eric Sandeen wrote:
> you'd need to read the docs for your controller, to find out how to
> tell if it has a writeback cache enabled, and whether it is
> batter-backed or not.

Sorry I didn't write that. Yes it's writeback (can be switched off) and 
it's battery backed. Is there no danger then? Because in the mail from 
Chris, he wrote he got problems because there was "with a write back 
cache enabled on the controller / disks but without barriers". And I 
thought the (not supported/used) barriers could be a problem.

I've re-read the FAQ now. It says it's recommended to turn off barrier 
writes if you have battery-backed writeback, and I guess I'll do that. 
So I misunderstood Chris.
But what about the hard disk cache - should that be disabled? I think in 
case of a power failure, they just loose their cache contents, right? So 
the battery-backed controller cache only helps himself, the disks will 
just throw away up to the 32MB cache they have?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From michael.monnerie@is.it-management.at Tue Feb  3 03:25:34 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n139PYDm050530
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 03:25:34 -0600
X-ASG-Debug-ID: 1233653094-4ea3033a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 09ED7DE071
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 01:24:54 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id F6WOTSJ8lb8eW4Nc for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 01:24:54 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 0A4D73CB8
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 10:24:54 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id CD58040016F
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 10:24:53 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Subject: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Date: Tue, 3 Feb 2009 10:24:53 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <1233641256.5518.83.camel@verge.scott.net.au> <1233641336.5518.85.camel@verge.scott.net.au> <20090203062036.GA23098@infradead.org>
In-Reply-To: <20090203062036.GA23098@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200902031024.53548@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233653095
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16885
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > and "Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)" to save ya
> > looking.
>
> 2.6.16 didn't have the compat ioctl handler for growfs yet, and this
> is i386 xfsprogs on a 64bit kernel. =A0He needs to upgrade to a more
> recent kernel.

He wrote 2.6.26....

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 03:29:59 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n139TxWd050852
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 03:29:59 -0600
X-ASG-Debug-ID: 1233653359-4e9e034a0000-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 1A26ADE0E2
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 01:29:19 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id gcbmE1wWqjJ5zCev for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 01:29:19 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUHap-0001Ot-Eh; Tue, 03 Feb 2009 09:29:19 +0000
Date: Tue, 3 Feb 2009 04:29:19 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Subject: Re: [Fwd: Bug#513821: xfsprogs: xfs_growfs does not work]
Message-ID: <20090203092919.GA31741@infradead.org>
References: <1233641256.5518.83.camel@verge.scott.net.au> <1233641336.5518.85.camel@verge.scott.net.au> <20090203062036.GA23098@infradead.org> <200902031024.53548@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902031024.53548@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233653360
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 10:24:53AM +0100, Michael Monnerie wrote:
> On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > > and "Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)" to save ya
> > > looking.
> >
> > 2.6.16 didn't have the compat ioctl handler for growfs yet, and this
> > is i386 xfsprogs on a 64bit kernel. ?He needs to upgrade to a more
> > recent kernel.
> 
> He wrote 2.6.26....

And I did mean 2.6.26, sorry.

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 03:33:49 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n139XnXY051086
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 03:33:49 -0600
X-ASG-Debug-ID: 1233653589-212d00ae0000-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 27E2818ACFA9
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 01:33:10 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id X3fNlJ5LhQvHI6RI for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 01:33:10 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUHe3-0006TV-AN; Tue, 03 Feb 2009 09:32:39 +0000
Date: Tue, 3 Feb 2009 04:32:39 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090203093239.GA14963@infradead.org>
References: <498376CF.8020806@renderforce.de> <200902030222.47644@zmi.at> <4987B673.8030406@sandeen.net> <200902031022.38583@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902031022.38583@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233653590
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 10:22:38AM +0100, Michael Monnerie wrote:
> But what about the hard disk cache - should that be disabled? I think in 
> case of a power failure, they just loose their cache contents, right? So 
> the battery-backed controller cache only helps himself, the disks will 
> just throw away up to the 32MB cache they have?

Yes.  I would hope raid controllers disable the write cache on disks,
but for lower end controllers I'm not sure they really do it.

From michael.monnerie@is.it-management.at Tue Feb  3 04:40:51 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13AeoPg054307
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 04:40:51 -0600
X-ASG-Debug-ID: 1233657609-1d3701920000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id CC369D94C5
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 02:40:10 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id dUHnQoghPm2Fdv8g for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 02:40:10 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 10D073CC1
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 11:40:09 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id DD10540016F
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 11:40:08 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Tue, 3 Feb 2009 11:40:08 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <200902031022.38583@zmi.at> <20090203093239.GA14963@infradead.org>
In-Reply-To: <20090203093239.GA14963@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200902031140.08576@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233657610
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16889
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> Yes. =A0I would hope raid controllers disable the write cache on disks,
> but for lower end controllers I'm not sure they really do it.

On Areca Controllers, I can select if I want it on or off. Could an=20
information about the disk cache be written to the FAQ? Would for sure=20
save some people's data... :-)

So battery backed controller cache on, disk cache off, barriers off.
Quite simple once you know it :-))

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From jamie@shareable.org Tue Feb  3 05:23:17 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00
	autolearn=unavailable version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13BNHga057412
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 05:23:17 -0600
X-ASG-Debug-ID: 1233660156-1d3602e80000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mail2.shareable.org (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id 2F96CD98E4; Tue,  3 Feb 2009 03:22:37 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by cuda.sgi.com with ESMTP id A6itY6WD9GoXLjc7; Tue, 03 Feb 2009 03:22:37 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63)
	(envelope-from <jamie@shareable.org>)
	id 1LUJKz-0003Mu-81; Tue, 03 Feb 2009 11:21:05 +0000
Date: Tue, 3 Feb 2009 11:21:05 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>,
        Christoph Hellwig <hch@infradead.org>,
        Eric Sandeen <sandeen@sandeen.net>, mfasheh@suse.com,
        joel.becker@oracle.com, linux-kernel@vger.kernel.org,
        xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk,
        Ankit Jain <me@ankitjain.org>, linux-fsdevel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>, xfs@oss.sgi.com,
        ocfs2-devel@oss.oracle.com
X-ASG-Orig-Subj: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Subject: Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls
Message-ID: <20090203112105.GD11926@shareable.org>
References: <20090130171423.f99c88d0.akpm@linux-foundation.org> <20090201164130.GA32276@infradead.org> <4985D48A.6090007@panasas.com> <200902020131.04203.arnd@arndb.de> <4986AEE8.5040609@panasas.com> <Pine.LNX.4.64.0902020942230.11930@anakin> <4986BE07.6090000@panasas.com> <20090202205102.GG28129@shareable.org> <4987F2B8.9070700@panasas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4987F2B8.9070700@panasas.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Barracuda-Connect: mail2.shareable.org[80.68.89.115]
X-Barracuda-Start-Time: 1233660158
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16892
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Boaz Harrosh wrote:
> I would at least expect a big fat comment explaining what happened to the
> structure on what known ARCHs, and how it is expected to look in memory.
> And a BUILD_BUG_ON to make sure of that.

You may have a point.

Struct layout on some architectures changes between compiler default
ABIs in these implicit-padding cases.  Kernel binary compatibility
will be affected.  It is a good reason why we have explicit padding to
natural alignment normally.

>From http://wiki.debian.org/ArmEabiPort

    "With the new ABI, default structure packing changes, as do some
    default data sizes and alignment (which also have a knock-on effect on
    structure packing). In particular the minimum size and alignment of a
    structure was 4 bytes. Under the EABI there is no minimum and the
    alignment is determined by the types of the components it
    contains. This will break programs that know too much about the way
    structures are packed and can break code that writes binary files by
    dumping and reading structures."

    "One of the key differences between the traditional GNU/Linux ABI
    and the EABI is that 64-bit types (like long long) are aligned
    differently. In the traditional ABI, these types had 4-byte alignment;
    in the EABI they have 8-byte alignment. As a result, if you use the
    same structure definitions (in a header file) and include it in code
    used in both the kernel and in application code, you may find that the
    structure size and alignment differ."

-- Jamie

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 09:49:49 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13FnnPM072507
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 09:49:49 -0600
X-ASG-Debug-ID: 1233676149-08e003bb0000-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 4BD7EDF7C7
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 07:49:09 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id cjCX0WpjDQGV867J for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 07:49:09 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUNWO-0007G2-FO; Tue, 03 Feb 2009 15:49:08 +0000
Date: Tue, 3 Feb 2009 10:49:08 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090203154907.GA21278@infradead.org>
References: <498376CF.8020806@renderforce.de> <200902031022.38583@zmi.at> <20090203093239.GA14963@infradead.org> <200902031140.08576@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902031140.08576@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233676150
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 11:40:08AM +0100, Michael Monnerie wrote:
> On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > Yes. ?I would hope raid controllers disable the write cache on disks,
> > but for lower end controllers I'm not sure they really do it.
> 
> On Areca Controllers, I can select if I want it on or off. Could an 
> information about the disk cache be written to the FAQ? Would for sure 
> save some people's data... :-)
> 
> So battery backed controller cache on, disk cache off, barriers off.
> Quite simple once you know it :-))

Yeah, that sounds correct.  Do you volunteer for the FAQ entry?  xfs.org
is a wiki so you could add it.  I'm happy to proof-read it if you want.

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 09:52:27 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13FqQIm072663
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 09:52:27 -0600
X-ASG-Debug-ID: 1233676307-3f68001d0000-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 154841C01DD6
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 07:51:47 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id CYHO6skMDHKIa7g7 for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 07:51:47 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUNYx-0007Om-5Q; Tue, 03 Feb 2009 15:51:47 +0000
Date: Tue, 3 Feb 2009 10:51:47 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com, Nick Piggin <nickpiggin@yahoo.com.au>
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203155147.GB21278@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090201161458.GA5930@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233676308
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Sun, Feb 01, 2009 at 11:14:58AM -0500, Christoph Hellwig wrote:
> On Sun, Feb 01, 2009 at 03:12:24AM -0500, Christoph Hellwig wrote:
> > When running xfsqa on the current xfs development tree (sometimes two
> > runs are needed to trigger it) I get the following oops.  This seems to
> > have been introduced by the last mainling merge (with
> > 5ee810072175042775e39bdd3eaaa68884c27805), but I'd need to bisect it to
> > make sure my gut feeling is right.
> 
> Still happens with a commit before that mainline merge.  Looking for
> a good candiate for bisection now.

I bisected it down to commit 0087167c9d5b1273e7e6bbe39a9ab13bdb9a39bb
"[XFS] use scalable vmap API".

Nick, any idea what this could be?

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 10:05:56 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13G5t4l073394
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 10:05:55 -0600
X-ASG-Debug-ID: 1233677115-435700870000-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 2C5861C0205B
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 08:05:16 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id YE34sItoCsoAju1q for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 08:05:16 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUNlz-00022Z-Jl; Tue, 03 Feb 2009 16:05:15 +0000
Date: Tue, 3 Feb 2009 11:05:15 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203160515.GA30986@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902040303.13933.nickpiggin@yahoo.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233677116
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 03:03:13AM +1100, Nick Piggin wrote:
> Hmm, seems similar to the other one Dave saw. I suppose it could
> be due to bad parameters being passed to vmap API, but quite
> likely it could be a bug in vmap as well.
> 
> Any chance you can print out va_start and va_end from va and tmp
> before going bug? (or if you like, I can try reproduce it with
> xfsqa if there is a URL for it -- a quick google didn't help me).

It's at http://git.kernel.org/?p=fs/xfs/xfstests-dev.git

Right now I'm doing two verification runs with the current codebase
and just that patch reverted as a second verification.  After that
I can do a patch with the debug printks.

From felixb@oss.sgi.com Tue Feb  3 10:31:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13GV5f6074977
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 10:31:05 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13GV1PG074953;
	Tue, 3 Feb 2009 10:31:01 -0600
Date: Tue, 3 Feb 2009 10:31:01 -0600
Message-Id: <200902031631.n13GV1PG074953@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, mainline, updated. v2.6.28-rc3-12440-gb1792e3
X-Git-Refname: refs/heads/mainline
X-Git-Reftype: branch
X-Git-Oldrev: 5ee810072175042775e39bdd3eaaa68884c27805
X-Git-Newrev: b1792e367053968f2ddb48bc911d314143ce6242

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, mainline has been updated
      from  5ee810072175042775e39bdd3eaaa68884c27805 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
-----------------------------------------------------------------------

Summary of changes:


hooks/post-receive
-- 
XFS development tree

From felixb@oss.sgi.com Tue Feb  3 10:31:08 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13GV8H3075022
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 10:31:08 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13GV5lA074982;
	Tue, 3 Feb 2009 10:31:05 -0600
Date: Tue, 3 Feb 2009 10:31:05 -0600
Message-Id: <200902031631.n13GV5lA074982@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.28-rc3-12465-g3228149
X-Git-Refname: refs/heads/master
X-Git-Reftype: branch
X-Git-Oldrev: aaca4ff0917f62433f222f9fb0d04c1d61ad68cf
X-Git-Newrev: 3228149ceb8b045e324cd268be9182bb26e6488b

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, master has been updated
  3228149 xfs: Check buffer lengths in log recovery
      from  aaca4ff0917f62433f222f9fb0d04c1d61ad68cf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 3228149ceb8b045e324cd268be9182bb26e6488b
Author: Dave Chinner <david@fromorbit.com>
Date:   Thu Jan 22 15:37:47 2009 +1100

    xfs: Check buffer lengths in log recovery
    
    Before trying to obtain, read or write a buffer,
    check that the buffer length is actually valid. If
    it is not valid, then something read in the recovery
    process has been corrupted and we should abort
    recovery.
    
    Reported-by: Eric Sesterhenn <snakebyte@gmx.de>
    Tested-by: Eric Sesterhenn <snakebyte@gmx.de>
    Reviewed-by: Christoph Hellwig <hch@infradead.org>
    Reviewed-by: Felix Blyakher <felixb@sgi.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Felix Blyakher <felixb@sgi.com>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_log_recover.c |   31 +++++++++++++++++++++++++------
 1 files changed, 25 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
XFS development tree

From felixb@oss.sgi.com Tue Feb  3 10:31:17 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13GVHjr076189
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 10:31:17 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13GV8QH075026;
	Tue, 3 Feb 2009 10:31:08 -0600
Date: Tue, 3 Feb 2009 10:31:08 -0600
Message-Id: <200902031631.n13GV8QH075026@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, xfs-dev, updated. v2.6.28-rc3-12034-g608f91c
X-Git-Refname: refs/heads/xfs-dev
X-Git-Reftype: branch
X-Git-Oldrev: 0f0254fa8ddce39ce4e98113e7050e1cd88ff884
X-Git-Newrev: 608f91cef04116f1ab25455d46e58cee78c9cf82

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, xfs-dev has been updated
  ac12b4e don't reallocate sxp variable passed into xfs_swapext
  5e10657 [XFS] Warn on transaction in flight on read-only remount
  957274d Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs
  5253a11 [XFS] remove always-true #ifndef HAVE_FORMAT32 tests
  33ad965 Long btree pointers are still 64 bit on disk
  2809f76 xfs: sanity check attr fork size
  7884bc8 xfs: fix bad_features2 fixups for the root filesystem
  98b8c7a xfs: add a lock class for group/project dquots
  5bb87a3 xfs: lockdep annotations for xfs_dqlock2
  a4edd1d xfs: add a separate lock class for the per-mount list of dquots
  178eae3 xfs: use mnt_want_write in compat_attrmulti ioctl
  d296d30 xfs: fix dentry aliasing issues in open_by_handle
  9d87c31 [XFS] Remove the rest of the macro-to-function indirections.
  c088f4e Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
  8e96187 filesystem freeze: remove XFS specific ioctl interfaces for freeze feature
  c4be0c1 filesystem freeze: add error handling of write_super_lockfs/unlockfs
  ce79735 Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/xfs
  058652a [XFS] make xfs_ino_t an unsigned long long
  1544031 [XFS] truncate readdir offsets to signed 32 bit values
  e6edbd1 [XFS] fix compile of xfs_btree_readahead_lblock on m68k
  fb82557 [XFS] Remove macro-to-function indirections in the mask code
  c9fb86a [XFS] Remove macro-to-function indirections in attr code
  9800b55 [XFS] Remove several unused typedefs.
  c9a9855 [XFS] pass XFS_IGET_BULKSTAT to xfs_iget for handle operations
  6206aa8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
  025dfda trivial: fix then -> than typos in comments and documentation
  95f8e30 [XFS] use scalable vmap API
  d285975 [XFS] remove old vmap cache
  0a8c539 [XFS] Fix merge failures
  cbacc2c Merge branch 'next' into for-linus
  2505115 [XFS] Fix race in xfs_write() between direct and buffered I/O with DMAPI
  ad1ad96 [XFS] handle unaligned data in xfs_bmbt_disk_get_all
  efc5575 [XFS] avoid memory allocations in xfs_fs_vcmn_err
  9f6c92b [XFS] Fix speculative allocation beyond eof
  4fdc778 [XFS] Remove XFS_BUF_SHUT() and friends
  d415867 [XFS] Use the incore inode size in xfs_file_readdir()
  4d9d4eb Merge branch 'master' of git+ssh://git.melbourne.sgi.com/git/xfs
  cfbe526 [XFS] set b_error from bio error in xfs_buf_bio_end_io
  c4cd747 [XFS] use inode_change_ok for setattr permission checking
  4d4be48 [XFS] add a FMODE flag to make XFS invisible I/O less hacky
  6d73cf1 [XFS] resync headers with libxfs
  2175dd9 [XFS] simplify projid check in xfs_rename
  15ac08a [XFS] replace b_fspriv with b_mount
  e055f13 [XFS] Remove unused tracing code
  576a488 [XFS] Fix hang after disallowed rename across directory quota domains
  797eaed [XFS] Remove unnecessary assertion
  a5b429d [XFS] Remove unused variable in ktrace_free()
  c642261 [XFS] Check return value of xfs_buf_get_noaddr()
  6a0775a [XFS] Fix hang after disallowed rename across directory quota domains
  8bb5732 [XFS] Fix compile with CONFIG_COMPAT enabled
  5a8d0f3 move inode tracing out of xfs_vnode.
  25e41b3 move vn_iowait / vn_iowake into xfs_aops.c
  583fa58 kill vn_ioerror
  f95099b kill xfs_unmount_flush
  e57481d no explicit xfs_iflush for special inodes during unmount
  070c461 use xfs_trans_ijoin in xfs_trans_iget
  b56757b remove leftovers of shared read-only support
  e88f11a remove unused m_inode_quiesce member from struct xfs_mount
  6bd16ff kill dead inode flags
  5efcbb8 cleanup xfs_sb.h feature flag helpers
  df6771b kill dead quota flags
  63ad2a5 remove dead code from sv_t implementation
  39e2def reduce l_icloglock roundtrips
  d9424b3 stop using igrab in xfs_vn_link
  5d765b9 kill xfs_buf_iostart
  5cafdeb cleanup the inode reclaim path
  ccd0be6 remove unused prototypes for xfs_ihash_init / xfs_ihash_free
  73e6335 remove unused behvavior cruft in xfs_super.h
  2234d54 remove useless mnt_want_write call in xfs_write
  ddcd856 [XFS] fix compile on 32 bit systems
  e5d412f [XFS] Reorder xfs_ioctl32.c for some tidiness
  710d62a [XFS] Hook up compat XFS_IOC_FSSETDM_BY_HANDLE ioctl handler
  2875097 [XFS] Hook up compat XFS_IOC_ATTRMULTI_BY_HANDLE ioctl handler
  ebeecd2 [XFS] Hook up compat XFS_IOC_ATTRLIST_BY_HANDLE ioctl handler
  af819d2 [XFS] Fix compat XFS_IOC_FSBULKSTAT_SINGLE ioctl
  65fbaf2 [XFS] Fix xfs_bulkstat_one size checks & error handling
  2ee4fa5 [XFS] Make the bulkstat_one compat ioctl handling more sane
  471d591 [XFS] Add compat handlers for data & rt growfs ioctls
  e94fc4a [XFS] Add compat handlers for swapext ioctl
  d5547f9 [XFS] Clean up some existing compat ioctl calls
  ffae263 [XFS] Move compat ioctl structs & numbers into xfs_ioctl32.h
  743bb46 [XFS] Move copy_from_user calls out of ioctl helpers into ioctl switch.
  0e44667 [XFS] fix error handling in xlog_recover_process_one_iunlink
  24f211b [XFS] move inode allocation out xfs_iread
  b48d8d6 [XFS] kill the XFS_IMAP_BULKSTAT flag
  92bfc6e [XFS] embededd struct xfs_imap into xfs_inode
  94e1b69 [XFS] merge xfs_imap into xfs_dilocate
  a194189 [XFS] remove dead code for old inode item recovery
  76d8b27 [XFS] stop using xfs_itobp in xfs_iread
  23fac50 [XFS] split up xlog_recover_process_iunlinks
  51ce16d [XFS] kill XFS_DINODE_VERSION_ defines
  81591fe [XFS] kill xfs_dinode_core_t
  d42f08f [XFS] kill xfs_ialloc_log_di
  b28708d [XFS] sanitize xlog_in_core_t definition
  4805621 [XFS] factor out xfs_read_agf helper
  5e1be0f [XFS] factor out xfs_read_agi helper
  26c5295 [XFS] remove i_gen from incore inode
  207fcfa [XFS] remove xfs_vfsops.h
  2b5decd [XFS] remove xfs_vfs.h
  00dd402 [XFS] remove bhv_statvfs_t typedef
  f35642e [XFS] Hook up the fiemap ioctl.
  5af317c [XFS] Add new getbmap flags.
  8a7141a [XFS] convert xfs_getbmap to take formatter functions
  0924b58 [XFS] fix uninitialised variable bug in dquot release.
  2e65609 [XFS] fix error inversion problems with data flushing
  6579591 [XFS] fix spurious gcc warnings
  6c31b93 [XFS] allow inode64 mount option on 32 bit systems
  f999a5b [XFS] wire up ->open for directories
  bac8dca [XFS] fix NULL pointer dereference in xfs_log_force_umount
  cc09c0d [XFS] Fix double free of log tickets
  2b82892 Merge branch 'master' into next
  745ca24 CRED: Pass credentials through dentry_open()
  b6dff3e CRED: Separate task security context from task_struct
  82ab8de CRED: Wrap task credential accesses in the XFS filesystem
  220ca31 [XFS] XFS: Check for valid transaction headers in recovery
  8f330f5 [XFS] handle memory allocation failures during log initialisation
  6f9f51a [XFS] Account for allocated blocks when expanding directories
  2cf7f0d [XFS] Wait for all I/O on truncate to zero file size
  9ccbece [XFS] Fix use-after-free with log and quotas
  6307091 [XFS] Avoid using inodes that haven't been completely initialised
  cb4f0d1 [XFS] fix uninitialised variable bug in dquot release
  644c356 [XFS] handle memory allocation failures during log initialisation
  91b7771 CRED: Wrap task credential accesses in the XFS filesystem
  6bfb3d0 [XFS] Fix race when looking up reclaimable inodes
  e0b8e8b [XFS] remove restricted chown parameter from xfs linux
  ea5a3dc8 [XFS] kill sys_cred
  7ee49ac [XFS] correctly select first log item to push
  9ed0451 [XFS] free partially initialized inodes using destroy_inode
  c679eef [XFS] stop using xfs_itobp in xfs_bulkstat
  455486b [XFS] avoid all reclaimable inodes in xfs_sync_inodes_ag
  56e73ec [XFS] Can't lock inodes in radix tree preload region
  2b7035f [XFS] Trivial xfs_remove comment fixup
  1ec7944 [XFS] fix biosize option
  469fc23 [XFS] fix the noquota mount option
  9d565ff [XFS] kill struct xfs_mount_args
  5a792c4 [XFS] XFS: Check for valid transaction headers in recovery
  783a2f6 [XFS] Finish removing the mount pointer from the AIL API
  fc1829f [XFS] Add ail pointer into log items
  a9c21c1 [XFS] Given the log a pointer to the AIL
  c7e8f26 [XFS] Move the AIL lock into the struct xfs_ail
  7b2e2a3 [XFS] Allow 64 bit machines to avoid the AIL lock during flushes
  5b00f14 [XFS] move the AIl traversal over to a consistent interface
  27d8d5f [XFS] Use a cursor for AIL traversal.
  82fa901 [XFS] Allocate the struct xfs_ail
  a744405 [XFS] Account for allocated blocks when expanding directories
  8c38ab0 [XFS] Prevent looping in xfs_sync_inodes_ag
  1165451 [XFS] kill deleted inodes list
  7a3be02 [XFS] use the inode radix tree for reclaiming inodes
  396beb8 [XFS] mark inodes for reclaim via a tag in the inode radix tree
  1dc3318 [XFS] rename inode reclaim functions
  fce08f2 [XFS] move inode reclaim functions to xfs_sync.c
  493dca6 [XFS] Fix build warning - xfs_fs_alloc_inode() needs a return statement
  99fa8cb [XFS] Prevent use-after-free caused by synchronous inode reclaim
  bf90424 [XFS] Combine the XFS and Linux inodes
  94b97e3 [XFS] Never call mark_inode_dirty_sync() directly
  6441e54 [XFS] factor xfs_iget_core() into hit and miss cases
  3471394 [XFS] fix instant oops with tracing enabled
  76bf105 [XFS] Move remaining quiesce code.
  a4e4c4f [XFS] Kill xfs_sync()
  cb56a4b [XFS] Kill SYNC_CLOSE
  e9f1c6e [XFS] make SYNC_DELWRI no longer use xfs_sync
  be97d9d [XFS] make SYNC_ATTR no longer use xfs_sync
  aacaa88 [XFS] xfssyncd: don't call xfs_sync
  dfd837a [XFS] kill xfs_syncsub
  2030b5a [XFS] use xfs_sync_inodes rather than xfs_syncsub
  bc60a99 [XFS] Use struct inodes instead of vnodes to kill vn_grab
  2af75df [XFS] split out two helpers from xfs_syncsub
  4e8938f [XFS] Move XFS_BMAP_SANITY_CHECK out of line.
  7cc95a8 [XFS] Always use struct xfs_btree_block instead of short / longform
  136341b [XFS] cleanup btree record / key / ptr addressing macros.
  6c7699c [XFS] remove the mount inode list
  60197e8 [XFS] Cleanup maxrecs calculation.
  5b4d89a [XFS] Traverse inode trees when releasing dquots
  683a897 [XFS] Use the inode tree for finding dirty inodes
  2f8a3ce [XFS] don't block in xfs_qm_dqflush() during async writeback.
  75c68f4 [XFS] Remove xfs_iflush_all and clean up xfs_finish_reclaim_all()
  a167b17 [XFS] move xfssyncd code to xfs_sync.c
  fe4fa4b [XFS] move sync code to its own file
  34519da [XFS] Show buffer address with debug hexdump on corruption
  89b2839 [XFS] Check agf_btreeblks is valid when reading in the AGF
  847fff5 [XFS] Sync up kernel and user-space headers
  24ee0e4 [XFS] Make xfs_btree_check_ptr() debug-only code.
  d1de802 [XFS] Fix build brakage from patch "Clean up dquot pincount code"
  bc3048e [XFS] Clean up dquot pincount code.
  d112f29 [XFS] Wait for all I/O on truncate to zero file size
  7f7c39c [XFS] make btree tracing generic
  3cc7524 [XFS] mark various functions in xfs_btree.c static
  4a26e66 [XFS] add keys_inorder and recs_inorder btree methods
  fd6bcc5 [XFS] kill xfs_bmbt_log_block and xfs_bmbt_log_recs
  8cc938f [XFS] implement generic xfs_btree_get_rec
  91cca5d [XFS] implement generic xfs_btree_delete/delrec
  d4b3a4b [XFS] move xfs_bmbt_killroot to common code
  4b22a57 [XFS] implement generic xfs_btree_insert/insrec
  ea77b0a [XFS] move xfs_bmbt_newroot to common code
  344207c [XFS] implement semi-generic xfs_btree_new_root
  f5eb8e7 [XFS] implement generic xfs_btree_split
  687b890 [XFS] implement generic xfs_btree_lshift
  9eaead5 [XFS] implement generic xfs_btree_rshift
  278d0ca [XFS] implement generic xfs_btree_update
  38bb742 [XFS] implement generic xfs_btree_updkey
  fe033cc [XFS] implement generic xfs_btree_lookup
  8df4da4 [XFS] implement generic xfs_btree_decrement
  637aa50 [XFS] implement generic xfs_btree_increment
  65f1eae [XFS] add helpers for addressing entities inside a btree block
  ce5e42d [XFS] add get_maxrecs btree operation
  8c4ed63 [XFS] make btree tracing generic
  854929f [XFS] add new btree statistics
  a23f6ef [XFS] refactor btree validation helpers
  b524bfe [XFS] refactor xfs_btree_readahead
  e99ab90 [XFS] add a long pointers flag to xfs_btree_cur
  8186e51 [XFS] make btree root in inode support generic
  de227dd [XFS] add generic btree types
  561f7d1 [XFS] split up xfs_btree_init_cursor
  f2277f0 [XFS] kill struct xfs_btree_hdr
  f338f90 [XFS] Unlock inode before calling xfs_idestroy()
  a357a12 [XFS] Fix use-after-free with log and quotas
  4603992 [XFS] Remove final remnants of dirv1 macros and other stuff
  d07c60e [XFS] Use xfs_idestroy() to cleanup an inode.
  be8b78a [XFS] Remove kmem_zone_t argument from xfs_inode_init_once()
  07c8f67 [XFS] Make use of the init-once slab optimisation.
  2248485 Merge git://git.kernel.org/pub/scm/linux/kernel/git/viro/bdev
  d88f183 [PATCH] Remove XFS buffered readdir hack
  4400372 [PATCH] switch all filesystems over to d_obtain_alias
  30c40d2 [PATCH] propagate mode through open_bdev_excl/close_bdev_excl
      from  0f0254fa8ddce39ce4e98113e7050e1cd88ff884 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/Kconfig                 |    1 +
 fs/xfs/Makefile                |    6 +-
 fs/xfs/linux-2.6/sv.h          |   22 +-
 fs/xfs/linux-2.6/xfs_aops.c    |   66 +-
 fs/xfs/linux-2.6/xfs_aops.h    |    5 +-
 fs/xfs/linux-2.6/xfs_buf.c     |  166 +--
 fs/xfs/linux-2.6/xfs_buf.h     |   30 +-
 fs/xfs/linux-2.6/xfs_cred.h    |   12 +-
 fs/xfs/linux-2.6/xfs_export.c  |   56 +-
 fs/xfs/linux-2.6/xfs_file.c    |  317 +---
 fs/xfs/linux-2.6/xfs_fs_subr.c |   23 +-
 fs/xfs/linux-2.6/xfs_globals.c |    8 -
 fs/xfs/linux-2.6/xfs_globals.h |    1 -
 fs/xfs/linux-2.6/xfs_ioctl.c   |  533 +++----
 fs/xfs/linux-2.6/xfs_ioctl.h   |   85 +
 fs/xfs/linux-2.6/xfs_ioctl32.c |  783 ++++++----
 fs/xfs/linux-2.6/xfs_ioctl32.h |  214 +++-
 fs/xfs/linux-2.6/xfs_iops.c    |  122 ++-
 fs/xfs/linux-2.6/xfs_iops.h    |    1 -
 fs/xfs/linux-2.6/xfs_linux.h   |   13 +-
 fs/xfs/linux-2.6/xfs_lrw.c     |   50 +-
 fs/xfs/linux-2.6/xfs_stats.c   |    6 +-
 fs/xfs/linux-2.6/xfs_stats.h   |   65 +
 fs/xfs/linux-2.6/xfs_super.c   |  915 ++++-------
 fs/xfs/linux-2.6/xfs_super.h   |   15 -
 fs/xfs/linux-2.6/xfs_sync.c    |  766 +++++++++
 fs/xfs/linux-2.6/xfs_sync.h    |   55 +
 fs/xfs/linux-2.6/xfs_sysctl.c  |   11 -
 fs/xfs/linux-2.6/xfs_sysctl.h  |    3 +-
 fs/xfs/linux-2.6/xfs_vfs.h     |   77 -
 fs/xfs/linux-2.6/xfs_vnode.c   |  145 --
 fs/xfs/linux-2.6/xfs_vnode.h   |   72 +-
 fs/xfs/quota/xfs_dquot.c       |   77 +-
 fs/xfs/quota/xfs_dquot.h       |   14 +-
 fs/xfs/quota/xfs_dquot_item.c  |   45 +-
 fs/xfs/quota/xfs_qm.c          |   66 +-
 fs/xfs/quota/xfs_qm.h          |    3 +-
 fs/xfs/quota/xfs_qm_bhv.c      |    5 +-
 fs/xfs/quota/xfs_qm_syscalls.c |  151 +-
 fs/xfs/support/debug.c         |   39 +-
 fs/xfs/support/debug.h         |    2 -
 fs/xfs/support/ktrace.c        |    9 +-
 fs/xfs/xfs.h                   |    2 +-
 fs/xfs/xfs_acl.c               |    8 +-
 fs/xfs/xfs_acl.h               |    1 -
 fs/xfs/xfs_ag.h                |   23 +-
 fs/xfs/xfs_alloc.c             |  264 +++-
 fs/xfs/xfs_alloc.h             |   27 +-
 fs/xfs/xfs_alloc_btree.c       | 2387 ++++-----------------------
 fs/xfs/xfs_alloc_btree.h       |  107 +-
 fs/xfs/xfs_arch.h              |   39 +-
 fs/xfs/xfs_attr.c              |   26 +-
 fs/xfs/xfs_attr_leaf.c         |   72 +-
 fs/xfs/xfs_attr_leaf.h         |   12 -
 fs/xfs/xfs_bit.h               |   13 +-
 fs/xfs/xfs_bmap.c              |  574 ++++---
 fs/xfs/xfs_bmap.h              |   74 +-
 fs/xfs/xfs_bmap_btree.c        | 2711 ++++++------------------------
 fs/xfs/xfs_bmap_btree.h        |  175 +--
 fs/xfs/xfs_btree.c             | 3596 +++++++++++++++++++++++++++++++++++-----
 fs/xfs/xfs_btree.h             |  392 +++--
 fs/xfs/xfs_btree_trace.c       |  249 +++
 fs/xfs/xfs_btree_trace.h       |  116 ++
 fs/xfs/xfs_buf_item.c          |   45 +-
 fs/xfs/xfs_clnt.h              |  105 --
 fs/xfs/xfs_da_btree.c          |   13 +-
 fs/xfs/xfs_da_btree.h          |   24 +-
 fs/xfs/xfs_dfrag.c             |   18 +-
 fs/xfs/xfs_dfrag.h             |    2 +-
 fs/xfs/xfs_dinode.h            |  148 +--
 fs/xfs/xfs_dir2.c              |    6 +
 fs/xfs/xfs_dir2_block.c        |    7 +-
 fs/xfs/xfs_dir2_leaf.c         |    6 +-
 fs/xfs/xfs_dir2_sf.c           |   15 +-
 fs/xfs/xfs_dir2_sf.h           |    7 -
 fs/xfs/xfs_dmops.c             |    5 +-
 fs/xfs/xfs_error.c             |   15 -
 fs/xfs/xfs_error.h             |   12 +-
 fs/xfs/xfs_extfree_item.c      |   45 +-
 fs/xfs/xfs_extfree_item.h      |    6 -
 fs/xfs/xfs_fs.h                |   26 +-
 fs/xfs/xfs_fsops.c             |   41 +-
 fs/xfs/xfs_fsops.h             |    2 +-
 fs/xfs/xfs_ialloc.c            |  453 +++--
 fs/xfs/xfs_ialloc.h            |   33 +-
 fs/xfs/xfs_ialloc_btree.c      | 2193 +++----------------------
 fs/xfs/xfs_ialloc_btree.h      |  112 +-
 fs/xfs/xfs_iget.c              |  735 +++++----
 fs/xfs/xfs_imap.h              |   40 -
 fs/xfs/xfs_inode.c             |  608 ++-----
 fs/xfs/xfs_inode.h             |  377 +++--
 fs/xfs/xfs_inode_item.c        |   45 +-
 fs/xfs/xfs_inode_item.h        |   39 +-
 fs/xfs/xfs_iomap.c             |   38 +-
 fs/xfs/xfs_itable.c            |  108 +-
 fs/xfs/xfs_itable.h            |   14 +
 fs/xfs/xfs_log.c               |  120 +-
 fs/xfs/xfs_log.h               |    4 +
 fs/xfs/xfs_log_priv.h          |   48 +-
 fs/xfs/xfs_log_recover.c       |  424 ++---
 fs/xfs/xfs_mount.c             |  112 +-
 fs/xfs/xfs_mount.h             |   82 +-
 fs/xfs/xfs_qmops.c             |    5 +-
 fs/xfs/xfs_quota.h             |    8 +-
 fs/xfs/xfs_rename.c            |   63 +-
 fs/xfs/xfs_rtalloc.c           |   43 +-
 fs/xfs/xfs_rw.c                |    2 +-
 fs/xfs/xfs_rw.h                |    1 -
 fs/xfs/xfs_sb.h                |  169 +-
 fs/xfs/xfs_trans.c             |   22 +-
 fs/xfs/xfs_trans.h             |  322 ++--
 fs/xfs/xfs_trans_ail.c         |  362 +++--
 fs/xfs/xfs_trans_buf.c         |    7 +-
 fs/xfs/xfs_trans_inode.c       |   30 +-
 fs/xfs/xfs_trans_item.c        |   10 +
 fs/xfs/xfs_trans_priv.h        |   98 +-
 fs/xfs/xfs_types.h             |    4 +-
 fs/xfs/xfs_utils.c             |   12 +-
 fs/xfs/xfs_vfsops.c            |  757 ---------
 fs/xfs/xfs_vfsops.h            |   16 -
 fs/xfs/xfs_vnodeops.c          |  374 +----
 fs/xfs/xfs_vnodeops.h          |   16 +-
 122 files changed, 10858 insertions(+), 13519 deletions(-)
 create mode 100644 fs/xfs/linux-2.6/xfs_ioctl.h
 create mode 100644 fs/xfs/linux-2.6/xfs_sync.c
 create mode 100644 fs/xfs/linux-2.6/xfs_sync.h
 delete mode 100644 fs/xfs/linux-2.6/xfs_vfs.h
 delete mode 100644 fs/xfs/linux-2.6/xfs_vnode.c
 create mode 100644 fs/xfs/xfs_btree_trace.c
 create mode 100644 fs/xfs/xfs_btree_trace.h
 delete mode 100644 fs/xfs/xfs_clnt.h
 delete mode 100644 fs/xfs/xfs_imap.h
 delete mode 100644 fs/xfs/xfs_vfsops.c
 delete mode 100644 fs/xfs/xfs_vfsops.h


hooks/post-receive
-- 
XFS development tree

From felixb@oss.sgi.com Tue Feb  3 10:40:23 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13GeNN3076776
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 10:40:23 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13GeLaS076754;
	Tue, 3 Feb 2009 10:40:21 -0600
Date: Tue, 3 Feb 2009 10:40:21 -0600
Message-Id: <200902031640.n13GeLaS076754@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-12442-g6d2160b
X-Git-Refname: refs/heads/for-linus
X-Git-Reftype: branch
X-Git-Oldrev: f0e0059b9c18426cffdcc04161062251a8f9741e
X-Git-Newrev: 6d2160bfe7826aca1c94b4bca77093908a452ae7

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-linus has been updated
      from  f0e0059b9c18426cffdcc04161062251a8f9741e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
-----------------------------------------------------------------------

Summary of changes:


hooks/post-receive
-- 
XFS development tree

From felixb@oss.sgi.com Tue Feb  3 11:02:28 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13H2RfJ078098
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 11:02:27 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13H2PPC078064;
	Tue, 3 Feb 2009 11:02:25 -0600
Date: Tue, 3 Feb 2009 11:02:25 -0600
Message-Id: <200902031702.n13H2PPC078064@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-12443-g6139a23
X-Git-Refname: refs/heads/for-linus
X-Git-Reftype: branch
X-Git-Oldrev: 6d2160bfe7826aca1c94b4bca77093908a452ae7
X-Git-Newrev: 6139a2360987f55e4490a7813cf69df74ec8b93a

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-linus has been updated
  6139a23 xfs: Check buffer lengths in log recovery
      from  6d2160bfe7826aca1c94b4bca77093908a452ae7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 6139a2360987f55e4490a7813cf69df74ec8b93a
Author: Dave Chinner <david@fromorbit.com>
Date:   Thu Jan 22 15:37:47 2009 +1100

    xfs: Check buffer lengths in log recovery
    
    Before trying to obtain, read or write a buffer,
    check that the buffer length is actually valid. If
    it is not valid, then something read in the recovery
    process has been corrupted and we should abort
    recovery.
    
    Reported-by: Eric Sesterhenn <snakebyte@gmx.de>
    Tested-by: Eric Sesterhenn <snakebyte@gmx.de>
    Reviewed-by: Christoph Hellwig <hch@infradead.org>
    Reviewed-by: Felix Blyakher <felixb@sgi.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Felix Blyakher <felixb@sgi.com>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_log_recover.c |   31 +++++++++++++++++++++++++------
 1 files changed, 25 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
XFS development tree

From felixb@oss.sgi.com Tue Feb  3 11:06:01 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13H61Un078436
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 11:06:01 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13H5xpL078407;
	Tue, 3 Feb 2009 11:05:59 -0600
Date: Tue, 3 Feb 2009 11:05:59 -0600
Message-Id: <200902031705.n13H5xpL078407@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-12444-g43f3f05
X-Git-Refname: refs/heads/for-linus
X-Git-Reftype: branch
X-Git-Oldrev: 6139a2360987f55e4490a7813cf69df74ec8b93a
X-Git-Newrev: 43f3f057c56d030546145696627f13f95735be95

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-linus has been updated
  43f3f05 [XFS] Warn on transaction in flight on read-only remount
      from  6139a2360987f55e4490a7813cf69df74ec8b93a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 43f3f057c56d030546145696627f13f95735be95
Author: Felix Blyakher <felixb@sgi.com>
Date:   Thu Jan 22 21:34:05 2009 -0600

    [XFS] Warn on transaction in flight on read-only remount
    
    Till VFS can correctly support read-only remount without racing,
    use WARN_ON instead of BUG_ON on detecting transaction in flight
    after quiescing filesystem.
    
    Signed-off-by: Felix Blyakher <felixb@sgi.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/linux-2.6/xfs_sync.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
XFS development tree

From felixb@sgi.com Tue Feb  3 11:08:23 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13H8NFU078644
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 11:08:23 -0600
Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44])
	by relay3.corp.sgi.com (Postfix) with ESMTP id 35CDAAC02D;
	Tue,  3 Feb 2009 09:07:41 -0800 (PST)
Received: by attica.americas.sgi.com (Postfix, from userid 29043)
	id 538E91418C93B; Tue,  3 Feb 2009 11:07:40 -0600 (CST)
Date: Tue, 03 Feb 2009 11:07:40 -0600
To: torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, xfs@sgi.com, akpm@linux-foundation.org
Subject: [GIT PULL] XFS update for 2.6.29-rc4
User-Agent: Heirloom mailx 12.2 01/07/07
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20090203170740.538E91418C93B@attica.americas.sgi.com>
From: felixb@sgi.com (Felix Blyakher)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

The following changes since commit b1792e367053968f2ddb48bc911d314143ce6242:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6

are available in the git repository at:

  git://oss.sgi.com/xfs/xfs for-linus

Dave Chinner (1):
      xfs: Check buffer lengths in log recovery

Eric Sandeen (1):
      don't reallocate sxp variable passed into xfs_swapext

Felix Blyakher (2):
      Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6 into for-linus
      [XFS] Warn on transaction in flight on read-only remount

 fs/xfs/linux-2.6/xfs_sync.c |    6 +++++-
 fs/xfs/xfs_dfrag.c          |   10 +---------
 fs/xfs/xfs_log_recover.c    |   31 +++++++++++++++++++++++++------
 3 files changed, 31 insertions(+), 16 deletions(-)

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 12:45:20 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13IjKJX084249
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 12:45:20 -0600
X-ASG-Debug-ID: 1233686680-7bf2028c0000-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 65089E1426
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 10:44:40 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id rgAu12qeiRTj4w88 for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 10:44:40 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUQFl-0006rr-Lk; Tue, 03 Feb 2009 18:44:09 +0000
Date: Tue, 3 Feb 2009 13:44:09 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203184409.GA22204@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au> <20090203160515.GA30986@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090203160515.GA30986@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233686681
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 11:05:15AM -0500, Christoph Hellwig wrote:
> On Wed, Feb 04, 2009 at 03:03:13AM +1100, Nick Piggin wrote:
> > Hmm, seems similar to the other one Dave saw. I suppose it could
> > be due to bad parameters being passed to vmap API, but quite
> > likely it could be a bug in vmap as well.
> > 
> > Any chance you can print out va_start and va_end from va and tmp
> > before going bug? (or if you like, I can try reproduce it with
> > xfsqa if there is a URL for it -- a quick google didn't help me).
> 
> It's at http://git.kernel.org/?p=fs/xfs/xfstests-dev.git
> 
> Right now I'm doing two verification runs with the current codebase
> and just that patch reverted as a second verification.  After that
> I can do a patch with the debug printks.

With that patch reverted it completes three complete xfsqa runs without
problems.  Now running with the debug printks instead.

From felixb@oss.sgi.com Tue Feb  3 13:56:03 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.0-rupdated
Received: from oss.sgi.com (localhost [127.0.0.1])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13Ju3s6088694
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 13:56:03 -0600
Received: (from felixb@localhost)
	by oss.sgi.com (8.14.3/8.14.3/Submit) id n13Ju13E088669;
	Tue, 3 Feb 2009 13:56:01 -0600
Date: Tue, 3 Feb 2009 13:56:01 -0600
Message-Id: <200902031956.n13Ju13E088669@oss.sgi.com>
From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, xfs-dev, updated. v2.6.28-rc3-12035-g48f392c
X-Git-Refname: refs/heads/xfs-dev
X-Git-Reftype: branch
X-Git-Oldrev: 608f91cef04116f1ab25455d46e58cee78c9cf82
X-Git-Newrev: 48f392c1d468f93d79c735f76dd2a124d7022778

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, xfs-dev has been updated
      from  608f91cef04116f1ab25455d46e58cee78c9cf82 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
-----------------------------------------------------------------------

Summary of changes:


hooks/post-receive
-- 
XFS development tree

From mpatocka@redhat.com Tue Feb  3 14:19:16 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13KJFXr090166
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 14:19:16 -0600
X-ASG-Debug-ID: 1233692315-62b300d50000-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 C7DF5E1C3B
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 12:18:35 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id 2iTYKzO5rwYPVZIY for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 12:18:35 -0800 (PST)
X-ASG-Whitelist: Barracuda Reputation
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 n13K58uA015721;
	Tue, 3 Feb 2009 15:05:08 -0500
Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34])
	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n13K59vK029300;
	Tue, 3 Feb 2009 15:05:09 -0500
Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1])
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n13K58gc032530;
	Tue, 3 Feb 2009 15:05:08 -0500
Received: from localhost (mpatocka@localhost)
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n13K57qV032524;
	Tue, 3 Feb 2009 15:05:08 -0500
X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs
Date: Tue, 3 Feb 2009 15:05:07 -0500 (EST)
From: Mikulas Patocka <mpatocka@redhat.com>
X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com
To: Dave Chinner <david@fromorbit.com>
cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
In-Reply-To: <20090203032740.GG24173@disturbed>
Message-ID: <Pine.LNX.4.64.0902031459350.28433@hs20-bc2-1.build.redhat.com>
References: <20090118173144.GA1999@infradead.org>
 <Pine.LNX.4.64.0901201430250.4603@hs20-bc2-1.build.redhat.com>
 <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org>
 <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com>
 <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com>
 <20090131235725.GA24173@disturbed> <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com>
 <20090203032740.GG24173@disturbed>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 1233692316
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, 3 Feb 2009, Dave Chinner wrote:

> > No, if you turn it into a trylock, it will randomly fail if any other 
> > process is holding the lock for whatever reason. So you will still get 
> > spurious -ENOSPCs, although with lower probability.
> 
> The flush is never, ever going to be perfect. While we are blocking
> waiting for the flush, other concurrent writes could be doing more
> delayed allocation. The flush won't catch these, so we can still get
> spurious ENOSPCs even with a *perfect* flush.

So you can turn it into a loop --- while there are delayed allocations, 
flush and retry.

... and if you turn it into trylock, what are you going to do with the 
inode that is just being written to? You should definitely flush it, but 
trylock will skip it because it's already locked.

> Hence there is no point in trying to make the code perfect - we
> can look at more complex solutions if and only if the simple
> solution is not sufficient.
> 
> > > If you make the xfs_ilock() there xfs_ilock_nowait() and avoid data
> > > writeback if we don't get the lock the deadlock goes away, right?
> > 
> > But that premature ENOSPC possibility will still exist.
> > The only right solution that I see is to drop this flushing code at all 
> > (because it's unfixable), catch -ENOSPCs exactly before you are about to 
> > return them to Linux VFS, flush at this point (you are not holding any 
> > locks here) and retry.
> 
> Still not perfect as soon as you consider concurrency (as per above).
> 
> > There seems to be more bugs with forgetting to flush delayed allocation 
> > --- you should flush delayed allocation after *every* failed allocate 
> > attempt, but the code flushes it only after failed delayed allocate 
> > attempt --- i.e. nondelayed allocators, such as xfs_iomap_write_direct 
> > (and maybe other places) will still return -ENOSPC without attempting to 
> > flush other inodes with delayed allocation.
> 
> xfs_iomap_write_direct() is for direct IO, and if that fails due to
> ENOSPC, we're going to return the error rather than try to flush
> delayed allocation blocks. Users of direct IO care more about
> deterministic response than trying to use every last byte of the
> filesystem. Such users also don't tend to mix buffered writes
> (hence delayed allocation) and direct IO on the same filesystem
> precisely because of the non-deterministic nature of buffered IO.
> Hence we don't flush here.
> 
> xfs_iomap_write_allocate() does the allocation of delayed extents,
> which we've already guaranteed that there is space for due to the
> flushing in xfs_iomap_write_delay(). Hence we don't flush here,
> either.
> 
> For metadata allocations (all over the place), we take a reservation
> first

And what if the reservation fails? Do you flush in this case?

> and so we could trigger a flush in certain circumstances if
> the reservation fails (to avoid recursion and transaction subsystem
> deadlocks). However, if you are not getting spurious enospc on
> creating inodes (as opposed to writing to them) then I see no
> immediate need for flushes there, either....
> 
> > Syncing should be really moved at the topmost place.
> 
> This can only be considered a best effort flush, not a sync.
> 
> > This is what I tried: I turned that 500ms wait into a completion:
> > 
> > 
> > Use xfs_sync_inodes and not sync_blockdev. sync_blockdev writes dirty 
> > metadata buffers, it doesn't touch inodes and pages at all.
> > 
> > Also, change that 500ms delay to a wait for completion, so that the
> > behavior is not dependent on magic timeout values. XFS developers insist
> > that it can't deadlock (I hope they're right).
> > 
> > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> .....
> > @@ -415,6 +419,7 @@ xfs_syncd_queue_work(
> >   * has failed with ENOSPC and we are in the process of scratching our
> >   * heads, looking about for more room...
> >   */
> > +#if 0
> >  STATIC void
> >  xfs_flush_inode_work(
> >  	struct xfs_mount *mp,
> > @@ -424,16 +429,20 @@ xfs_flush_inode_work(
> >  	filemap_flush(inode->i_mapping);
> >  	iput(inode);
> >  }
> > +#endif
> >  
> >  void
> >  xfs_flush_inode(
> >  	xfs_inode_t	*ip)
> >  {
> > +#if 0
> >  	struct inode	*inode = VFS_I(ip);
> > +	DECLARE_COMPLETION_ONSTACK(completion);
> >  
> >  	igrab(inode);
> > -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
> > -	delay(msecs_to_jiffies(500));
> > +	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work, &completion);
> > +	wait_for_completion(&completion);
> > +#endif
> 
> Why did you turn off the initial inode flush?

Because it recurses into Linux VFS layer and deadlocks.

You can avoid XFS deadlock with trylock, but you can't avoid Linux VFS 
deadlocks --- you just must not call it.

> >  }
> >  
> >  /*
> > @@ -446,7 +455,7 @@ xfs_flush_device_work(
> >  	void		*arg)
> >  {
> >  	struct inode	*inode = arg;
> > -	sync_blockdev(mp->m_super->s_bdev);
> > +	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_IOWAIT);
> >  	iput(inode);
> 
> This should be:
> 
> 	xfs_sync_inodes(mp, SYNC_DELWRI);
> 	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_IOWAIT);
> 
> As it will flush the inodes asynchronously and then the second
> pass will wait for all the IO to complete. That will be much
> more efficient than synchronous flushing.

I see, I didn't know about this trick.

Mikulas

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 15:05:34 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13L5Xda092570
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 15:05:34 -0600
X-ASG-Debug-ID: 1233695094-639e01660000-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 B098518B7B3B
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 13:04:54 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id eXhkv5IGmn5RcUTj for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 13:04:54 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUSRT-0001Yy-El; Tue, 03 Feb 2009 21:04:23 +0000
Date: Tue, 3 Feb 2009 16:04:23 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203210423.GA26628@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au> <20090203160515.GA30986@infradead.org> <20090203184409.GA22204@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090203184409.GA22204@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233695094
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

[ 3138.799436] XFS mounting filesystem vde
[ 3138.813184] va->va_start = 4290777088, va->va_end = 4096
[ 3138.834754] tmp->va_start = 4195352576, tmp->va_end = 4196401152
[ 3138.846352] ------------[ cut here ]------------
[ 3138.850332] kernel BUG at mm/vmalloc.c:298!
[ 3138.850332] invalid opcode: 0000 [#1] SMP 

The first va_end looks suspicious to me..

From sandeen@sandeen.net Tue Feb  3 15:19:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13LJDSa093470
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 15:19:14 -0600
X-ASG-Debug-ID: 1233695913-639f01be0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 8581218B7F16
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 13:18:33 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id gIV7Qo3SSvUcoUjP for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 13:18:33 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n13KmhHV029285;
	Tue, 3 Feb 2009 15:48:44 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n13Kmh8t027632;
	Tue, 3 Feb 2009 15:48:44 -0500
Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n13Kmhfc003605;
	Tue, 3 Feb 2009 15:48:43 -0500
Message-ID: <4988ADAA.8040400@sandeen.net>
Date: Tue, 03 Feb 2009 14:48:42 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Dave Chinner <david@fromorbit.com>, xfs mailing list <xfs@oss.sgi.com>
X-ASG-Orig-Subj: Re: [PATCH] Re: Corrupted XFS log replay oops.
Subject: Re: [PATCH] Re: Corrupted XFS log replay oops.
References: <20090113142147.GE16333@alice> <20090120173455.GC21339@alice>	<20090121035703.GH10158@disturbed>	<200901211503.07308.nickpiggin@yahoo.com.au> <20090122043747.GU10158@disturbed>
In-Reply-To: <20090122043747.GU10158@disturbed>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233695914
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16929
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Dave Chinner wrote:
> On Wed, Jan 21, 2009 at 03:03:06PM +1100, Nick Piggin wrote:
>> On Wednesday 21 January 2009 14:57:03 Dave Chinner wrote:
>>>> [  235.250167] ------------[ cut here ]------------
>>>> [  235.250354] kernel BUG at mm/vmalloc.c:164!
>>>> [  235.250478] invalid opcode: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
>>>> [  235.250869] last sysfs file: /sys/block/ram9/range
>>>> [  235.250998] Modules linked in:
> ......
>>>> [  235.251037] Call Trace:
>>>> [  235.251037]  [<c01414cf>] ? trace_hardirqs_on+0xb/0xd
>>>> [  235.251037]  [<c018367c>] ? vm_map_ram+0x36e/0x38a
>>>> [  235.251037]  [<c03b2e1e>] ? _xfs_buf_map_pages+0x42/0x6d
>>>> [  235.251037]  [<c03b3773>] ? xfs_buf_get_noaddr+0xbc/0x11f
>>>> [  235.251037]  [<c03a2406>] ? xlog_get_bp+0x5a/0x5d
>>>> [  235.251037]  [<c03a28fa>] ? xlog_find_verify_log_record+0x26/0x208
>>>> [  235.251037]  [<c03a3521>] ? xlog_find_zeroed+0x1d6/0x214
>>>> [  235.251037]  [<c03a3584>] ? xlog_find_head+0x25/0x358
>>> .....
>>>
>>> Ok, that's crashing in the new vmap code. It might take a couple
>>> of days before I get a chance to look at this, but I've cc'd Nick Piggin
>>> in case he has a chance to look at it before that. It's probably
>>> an XFS bug, anyway.
>> Hmm, it is crashing in BUG_ON(addr >= end); where this could happen
>> if XFS asks to map a really huge (or -ve) number of pages and wraps
>> the range, or if vmap subsystem returns an address right near the
>> end of the address range and addr+size wraps (which would be a bug
>> in vmap of course, but I think maybe less likely).
> 
> It's a zero length range, not a negative value. A debug XFS would
> have assert failed on it, but it was completely unchecked on
> production builds. The following patch checks the length of blocks
> to build/read/write for being valid. Instead of an oops, we get:

Dave, this patch seems like a candidate for 2.6.27-stable too, yes?

-Eric

> [ 1572.665001] XFS mounting filesystem loop0
> [ 1572.666942] XFS: Invalid block length (0x0) given for buffer
> [ 1572.667141] XFS: Log inconsistent (didn't find previous header)
> [ 1572.667141] XFS: empty log check failed
> [ 1572.667141] XFS: log mount/recovery failed: error 5
> [ 1572.671487] XFS: log mount failed
> 
> Cheers,
> 
> Dave.

From david@fromorbit.com Tue Feb  3 15:46:17 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13LkGnu095629
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 15:46:17 -0600
X-ASG-Debug-ID: 1233697535-6287029a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail05.adl2.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 7E132E2340
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 13:45:36 -0800 (PST)
Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by cuda.sgi.com with ESMTP id 6d6PLcGjHp8ZUHP4 for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 13:45:36 -0800 (PST)
Received: from ppp121-44-157-170.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.157.170])
  by ipmail05.adl2.internode.on.net with ESMTP; 04 Feb 2009 08:13:13 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUT2b-0005cX-Bx; Wed, 04 Feb 2009 08:42:45 +1100
Date: Wed, 4 Feb 2009 08:42:45 +1100
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203214245.GJ24173@disturbed>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>, xfs@oss.sgi.com
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au> <20090203160515.GA30986@infradead.org> <20090203184409.GA22204@infradead.org> <20090203210423.GA26628@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090203210423.GA26628@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail05.adl2.internode.on.net[203.16.214.145]
X-Barracuda-Start-Time: 1233697537
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16931
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 04:04:23PM -0500, Christoph Hellwig wrote:
> [ 3138.799436] XFS mounting filesystem vde
> [ 3138.813184] va->va_start = 4290777088, va->va_end = 4096
> [ 3138.834754] tmp->va_start = 4195352576, tmp->va_end = 4196401152
> [ 3138.846352] ------------[ cut here ]------------
> [ 3138.850332] kernel BUG at mm/vmalloc.c:298!
> [ 3138.850332] invalid opcode: 0000 [#1] SMP 
> 
> The first va_end looks suspicious to me..

That is on i386, Christoph? If so, I'd suspect a 32 bit overflow
as 4290777088 = 0xFFC01000 and va_start/va_end are unsigned longs.
If we tried to map exactly 4MB the with va_start at 0xFFC01000 we'd
end up with va_end at 0x100001000 which would wrap to 0x1000 = 4096.

Nick - this one is probably yours ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 15:53:45 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13LriHK096035
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 15:53:45 -0600
X-ASG-Debug-ID: 1233697662-629802b90000-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 44890E235A
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 13:47:42 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id GyBRbSBHV7JK1ku1 for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 13:47:42 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUT6t-0006Zk-DU; Tue, 03 Feb 2009 21:47:11 +0000
Date: Tue, 3 Feb 2009 16:47:11 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>,
        Nick Piggin <nickpiggin@yahoo.com.au>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203214711.GA24837@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au> <20090203160515.GA30986@infradead.org> <20090203184409.GA22204@infradead.org> <20090203210423.GA26628@infradead.org> <20090203214245.GJ24173@disturbed>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090203214245.GJ24173@disturbed>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233697662
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 08:42:45AM +1100, Dave Chinner wrote:
> On Tue, Feb 03, 2009 at 04:04:23PM -0500, Christoph Hellwig wrote:
> > [ 3138.799436] XFS mounting filesystem vde
> > [ 3138.813184] va->va_start = 4290777088, va->va_end = 4096
> > [ 3138.834754] tmp->va_start = 4195352576, tmp->va_end = 4196401152
> > [ 3138.846352] ------------[ cut here ]------------
> > [ 3138.850332] kernel BUG at mm/vmalloc.c:298!
> > [ 3138.850332] invalid opcode: 0000 [#1] SMP 
> > 
> > The first va_end looks suspicious to me..
> 
> That is on i386, Christoph? If so, I'd suspect a 32 bit overflow
> as 4290777088 = 0xFFC01000 and va_start/va_end are unsigned longs.
> If we tried to map exactly 4MB the with va_start at 0xFFC01000 we'd
> end up with va_end at 0x100001000 which would wrap to 0x1000 = 4096.

Yeah, this is 32-bit x86.  Exactly my thoughts, but just to make sure
the overflow is in vmap and not in XFS I'm running with your checking
patch included now.

From SRS0+aa3a967023aa76948da5+1990+infradead.org+hch@bombadil.srs.infradead.org Tue Feb  3 16:08:49 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n13M8mj5096656
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 16:08:49 -0600
X-ASG-Debug-ID: 1233698889-2b1901140000-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 E966FE2584
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 14:08:09 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id KPRVAqmjlmrfRowT for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 14:08:09 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUTRB-0002oV-3K; Tue, 03 Feb 2009 22:08:09 +0000
Date: Tue, 3 Feb 2009 17:08:09 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>,
        Nick Piggin <nickpiggin@yahoo.com.au>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090203220808.GA9195@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090201161458.GA5930@infradead.org> <20090203155147.GB21278@infradead.org> <200902040303.13933.nickpiggin@yahoo.com.au> <20090203160515.GA30986@infradead.org> <20090203184409.GA22204@infradead.org> <20090203210423.GA26628@infradead.org> <20090203214245.GJ24173@disturbed> <20090203214711.GA24837@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090203214711.GA24837@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233698889
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 04:47:11PM -0500, Christoph Hellwig wrote:
> On Wed, Feb 04, 2009 at 08:42:45AM +1100, Dave Chinner wrote:
> > On Tue, Feb 03, 2009 at 04:04:23PM -0500, Christoph Hellwig wrote:
> > > [ 3138.799436] XFS mounting filesystem vde
> > > [ 3138.813184] va->va_start = 4290777088, va->va_end = 4096
> > > [ 3138.834754] tmp->va_start = 4195352576, tmp->va_end = 4196401152
> > > [ 3138.846352] ------------[ cut here ]------------
> > > [ 3138.850332] kernel BUG at mm/vmalloc.c:298!
> > > [ 3138.850332] invalid opcode: 0000 [#1] SMP 
> > > 
> > > The first va_end looks suspicious to me..
> > 
> > That is on i386, Christoph? If so, I'd suspect a 32 bit overflow
> > as 4290777088 = 0xFFC01000 and va_start/va_end are unsigned longs.
> > If we tried to map exactly 4MB the with va_start at 0xFFC01000 we'd
> > end up with va_end at 0x100001000 which would wrap to 0x1000 = 4096.
> 
> Yeah, this is 32-bit x86.  Exactly my thoughts, but just to make sure
> the overflow is in vmap and not in XFS I'm running with your checking
> patch included now.

Nope, your check doesn't trigger.  Looks like it's indeed in vmap.

From george@alink.co.za Tue Feb  3 18:59:37 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n140xa0M105573
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 18:59:37 -0600
X-ASG-Debug-ID: 1233709136-2fe601860000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from poopey.oranged.to (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 94BF9E2FCC
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 16:58:56 -0800 (PST)
Received: from poopey.oranged.to (poopey.oranged.to [213.198.65.20]) by cuda.sgi.com with ESMTP id cTCAF3CFeJreGWvn for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 16:58:56 -0800 (PST)
Received: (qmail 16112 invoked by uid 89); 4 Feb 2009 00:32:14 -0000
Received: from unknown (HELO spoem.sydney.atlassian.com) (george@alink.co.za@203.63.130.33)
  by 0 with ESMTPA; 4 Feb 2009 00:32:13 -0000
Message-Id: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>
From: George Barnett <george@alink.co.za>
To: xfs@oss.sgi.com
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
X-ASG-Orig-Subj: XFS corruption on ubuntu 2.6.27-9-server
Subject: XFS corruption on ubuntu 2.6.27-9-server
Date: Wed, 4 Feb 2009 11:32:11 +1100
X-Mailer: Apple Mail (2.930.3)
X-Barracuda-Connect: poopey.oranged.to[213.198.65.20]
X-Barracuda-Start-Time: 1233709137
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16944
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hi,

I'm seeing the following errors:

[822153.422851] Filesystem "md2": XFS internal error xfs_da_do_buf(2)  
at line 2107 of file /build/buildd/linux-2.6.27/fs/xfs/ 
xfs_da_btree.c.  Caller 0xffffffffa03be8da
[822153.422903] Pid: 3273, comm: du Not tainted 2.6.27-9-server #1
[822153.422905]
[822153.422906] Call Trace:
[822153.422931]  [<ffffffffa03cab23>] xfs_error_report+0x43/0x50 [xfs]
[822153.422956]  [<ffffffffa03be8da>] ? xfs_da_read_buf+0x2a/0x30 [xfs]
[822153.422976]  [<ffffffffa03cab8d>] xfs_corruption_error+0x5d/0x80  
[xfs]
[822153.422995]  [<ffffffffa03be808>] xfs_da_do_buf+0x6a8/0x700 [xfs]
[822153.423014]  [<ffffffffa03be8da>] ? xfs_da_read_buf+0x2a/0x30 [xfs]
[822153.423019]  [<ffffffff80305b06>] ? mntput_no_expire+0x36/0x160
[822153.423022]  [<ffffffff803866e1>] ? aa_permission+0x21/0xd0
[822153.423041]  [<ffffffffa03be8da>] xfs_da_read_buf+0x2a/0x30 [xfs]
[822153.423061]  [<ffffffffa03c34fa>] ? xfs_dir2_block_getdents+0x9a/ 
0x210 [xfs]
[822153.423080]  [<ffffffffa03c34fa>] xfs_dir2_block_getdents+0x9a/ 
0x210 [xfs]
[822153.423099]  [<ffffffffa03adf7b>] ? xfs_bmap_last_offset+0x13b/ 
0x150 [xfs]
[822153.423119]  [<ffffffffa03f9970>] ? xfs_hack_filldir+0x0/0x60 [xfs]
[822153.423138]  [<ffffffffa03f9970>] ? xfs_hack_filldir+0x0/0x60 [xfs]
[822153.423157]  [<ffffffffa03c148b>] xfs_readdir+0x9b/0xf0 [xfs]
[822153.423176]  [<ffffffffa03f98a6>] xfs_file_readdir+0xd6/0x1a0 [xfs]
[822153.423180]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
[822153.423183]  [<ffffffff80386821>] ? aa_file_permission+0x21/0xf0
[822153.423185]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
[822153.423188]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
[822153.423191]  [<ffffffff802f8a9b>] vfs_readdir+0xbb/0xe0
[822153.423194]  [<ffffffff802f8c28>] sys_getdents+0x88/0xe0
[822153.423199]  [<ffffffff8021285a>] system_call_fastpath+0x16/0x1b

This seems to happen reasonably regularly on my system and causes the  
filesystem to be marked as dirty.  xfs_repair runs fine, but I end up  
with a bunch of files moved to lost+found. There are no device errors  
logged when this happens.

Mount options:

/dev/md2 on /data type xfs (rw,noatime)

Kernel:

Linux slut 2.6.27-9-server #1 SMP Thu Nov 20 22:56:07 UTC 2008 x86_64  
GNU/Linux

Device:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]  
[raid4] [raid10]
md2 : active raid10 sda2[0] sdd2[3] sdb2[1]
       1947655680 blocks super 1.2 128K chunks 2 far-copies [4/3] [UUUU]

# xfs_info /dev/md2
meta-data=/dev/md2               isize=256    agcount=32,  
agsize=15216064 blks
          =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=486913920,  
imaxpct=25
          =                       sunit=32     swidth=128 blks
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
          =                       sectsz=512   sunit=0 blks, lazy- 
count=0
realtime =none                   extsz=524288 blocks=0, rtextents=0

Any assistance would be greatly appreciated.

George

From sandeen@sandeen.net Tue Feb  3 19:29:27 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n141TRmI107294
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 19:29:27 -0600
X-ASG-Debug-ID: 1233710926-4ecc02700000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id F0FC018B8A5F
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:28:47 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id CnvTqOg85i5vn4gY for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:28:47 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n141Sf6A015672;
	Tue, 3 Feb 2009 20:28:41 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n141SPrv008400;
	Tue, 3 Feb 2009 20:28:26 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n141SOFQ006935;
	Tue, 3 Feb 2009 20:28:25 -0500
Message-ID: <4988EF37.7020306@sandeen.net>
Date: Tue, 03 Feb 2009 19:28:23 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: George Barnett <george@alink.co.za>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: XFS corruption on ubuntu 2.6.27-9-server
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
References: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>
In-Reply-To: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233710928
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: -0.92
X-Barracuda-Spam-Status: No, SCORE=-0.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA081
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16946
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	1.10 BSF_SC0_SA081          Custom Rule SA081
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

George Barnett wrote:
> Hi,
> 
> I'm seeing the following errors:
> 
> [822153.422851] Filesystem "md2": XFS internal error xfs_da_do_buf(2)  
> at line 2107 of file /build/buildd/linux-2.6.27/fs/xfs/ 

we really should make that more informative.

What it means is that you read a piece of metadata that did not match
any of the metadata magic numbers.

hard to say whether it might be an xfs bug I think; this does come up
occasionally though and it'd at least be nice to print more details on
the error (what the magic *was*, what block, etc)

Do you happen to have the repair output?

Did your md raid lose power w/ write cache enabled?

-Eric

> xfs_da_btree.c.  Caller 0xffffffffa03be8da
> [822153.422903] Pid: 3273, comm: du Not tainted 2.6.27-9-server #1
> [822153.422905]
> [822153.422906] Call Trace:
> [822153.422931]  [<ffffffffa03cab23>] xfs_error_report+0x43/0x50 [xfs]
> [822153.422956]  [<ffffffffa03be8da>] ? xfs_da_read_buf+0x2a/0x30 [xfs]
> [822153.422976]  [<ffffffffa03cab8d>] xfs_corruption_error+0x5d/0x80  
> [xfs]
> [822153.422995]  [<ffffffffa03be808>] xfs_da_do_buf+0x6a8/0x700 [xfs]
> [822153.423014]  [<ffffffffa03be8da>] ? xfs_da_read_buf+0x2a/0x30 [xfs]
> [822153.423019]  [<ffffffff80305b06>] ? mntput_no_expire+0x36/0x160
> [822153.423022]  [<ffffffff803866e1>] ? aa_permission+0x21/0xd0
> [822153.423041]  [<ffffffffa03be8da>] xfs_da_read_buf+0x2a/0x30 [xfs]
> [822153.423061]  [<ffffffffa03c34fa>] ? xfs_dir2_block_getdents+0x9a/ 
> 0x210 [xfs]
> [822153.423080]  [<ffffffffa03c34fa>] xfs_dir2_block_getdents+0x9a/ 
> 0x210 [xfs]
> [822153.423099]  [<ffffffffa03adf7b>] ? xfs_bmap_last_offset+0x13b/ 
> 0x150 [xfs]
> [822153.423119]  [<ffffffffa03f9970>] ? xfs_hack_filldir+0x0/0x60 [xfs]
> [822153.423138]  [<ffffffffa03f9970>] ? xfs_hack_filldir+0x0/0x60 [xfs]
> [822153.423157]  [<ffffffffa03c148b>] xfs_readdir+0x9b/0xf0 [xfs]
> [822153.423176]  [<ffffffffa03f98a6>] xfs_file_readdir+0xd6/0x1a0 [xfs]
> [822153.423180]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
> [822153.423183]  [<ffffffff80386821>] ? aa_file_permission+0x21/0xf0
> [822153.423185]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
> [822153.423188]  [<ffffffff802f8810>] ? filldir+0x0/0xe0
> [822153.423191]  [<ffffffff802f8a9b>] vfs_readdir+0xbb/0xe0
> [822153.423194]  [<ffffffff802f8c28>] sys_getdents+0x88/0xe0
> [822153.423199]  [<ffffffff8021285a>] system_call_fastpath+0x16/0x1b
> 
> This seems to happen reasonably regularly on my system and causes the  
> filesystem to be marked as dirty.  xfs_repair runs fine, but I end up  
> with a bunch of files moved to lost+found. There are no device errors  
> logged when this happens.
> 
> Mount options:
> 
> /dev/md2 on /data type xfs (rw,noatime)
> 
> Kernel:
> 
> Linux slut 2.6.27-9-server #1 SMP Thu Nov 20 22:56:07 UTC 2008 x86_64  
> GNU/Linux
> 
> Device:
> 
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]  
> [raid4] [raid10]
> md2 : active raid10 sda2[0] sdd2[3] sdb2[1]
>        1947655680 blocks super 1.2 128K chunks 2 far-copies [4/3] [UUUU]
> 
> # xfs_info /dev/md2
> meta-data=/dev/md2               isize=256    agcount=32,  
> agsize=15216064 blks
>           =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=486913920,  
> imaxpct=25
>           =                       sunit=32     swidth=128 blks
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=32768, version=1
>           =                       sectsz=512   sunit=0 blks, lazy- 
> count=0
> realtime =none                   extsz=524288 blocks=0, rtextents=0
> 
> Any assistance would be greatly appreciated.
> 
> George
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

From george@alink.co.za Tue Feb  3 19:35:30 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n141ZUAb107633
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 19:35:30 -0600
X-ASG-Debug-ID: 1233711290-2fe102230000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from poopey.oranged.to (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 2CC48E2C34
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:34:50 -0800 (PST)
Received: from poopey.oranged.to (poopey.oranged.to [213.198.65.20]) by cuda.sgi.com with ESMTP id 69wlpoZWrfOETcgT for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:34:50 -0800 (PST)
Received: (qmail 23631 invoked by uid 89); 4 Feb 2009 01:34:49 -0000
Received: from unknown (HELO spoem.sydney.atlassian.com) (george@alink.co.za@203.63.130.33)
  by 0 with ESMTPA; 4 Feb 2009 01:34:48 -0000
Cc: xfs@oss.sgi.com
Message-Id: <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za>
From: George Barnett <george@alink.co.za>
To: Eric Sandeen <sandeen@sandeen.net>
In-Reply-To: <4988EF37.7020306@sandeen.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
X-ASG-Orig-Subj: Re: XFS corruption on ubuntu 2.6.27-9-server
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
Date: Wed, 4 Feb 2009 12:34:45 +1100
References: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za> <4988EF37.7020306@sandeen.net>
X-Mailer: Apple Mail (2.930.3)
X-Barracuda-Connect: poopey.oranged.to[213.198.65.20]
X-Barracuda-Start-Time: 1233711291
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16946
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On 04/02/2009, at 12:28 PM, Eric Sandeen wrote:

> George Barnett wrote:
>> Hi,
>>
>> I'm seeing the following errors:
>>
>> [822153.422851] Filesystem "md2": XFS internal error xfs_da_do_buf(2)
>> at line 2107 of file /build/buildd/linux-2.6.27/fs/xfs/
>
> we really should make that more informative.
>
> What it means is that you read a piece of metadata that did not match
> any of the metadata magic numbers.
>
> hard to say whether it might be an xfs bug I think; this does come up
> occasionally though and it'd at least be nice to print more details on
> the error (what the magic *was*, what block, etc)
>
> Do you happen to have the repair output?
>
> Did your md raid lose power w/ write cache enabled?

Hi Eric,

Thanks for your response.  The system did not lose power.  This  
failure just "happens".  I have a cronjob which rsync's /data to a  
spare drive that's not on raid.  It seems that is enough to cause this  
failure.

Fortunately, I still have the xfs_repair output in my term buffer:

root@slut:/# xfs_repair /dev/md2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
         - zero log...
         - scan filesystem freespace and inode maps...
         - found root inode chunk
Phase 3 - for each AG...
         - scan and clear agi unlinked lists...
         - process known inodes and perform inode discovery...
         - agno = 0
bad magic number 0x0 on inode 18042
bad version number 0x0 on inode 18042
bad magic number 0x0 on inode 18043
bad version number 0x0 on inode 18043
bad magic number 0x0 on inode 18044
bad version number 0x0 on inode 18044
bad magic number 0x0 on inode 18045
bad version number 0x0 on inode 18045
bad magic number 0x0 on inode 18046
bad version number 0x0 on inode 18046
bad magic number 0x0 on inode 18047
bad version number 0x0 on inode 18047
bad directory block magic # 0 in block 0 for directory inode 18000
corrupt block 0 in directory inode 18000
	will junk block
no . entry for directory 18000
no .. entry for directory 18000
problem with directory contents in inode 18000
cleared inode 18000
bad directory block magic # 0 in block 0 for directory inode 18006
corrupt block 0 in directory inode 18006
	will junk block
no . entry for directory 18006
no .. entry for directory 18006
problem with directory contents in inode 18006
cleared inode 18006
bad magic number 0x0 on inode 18042, resetting magic number
bad version number 0x0 on inode 18042, resetting version number
imap claims a free inode 18042 is in use, correcting imap and clearing  
inode
cleared inode 18042
bad magic number 0x0 on inode 18043, resetting magic number
bad version number 0x0 on inode 18043, resetting version number
imap claims a free inode 18043 is in use, correcting imap and clearing  
inode
cleared inode 18043
bad magic number 0x0 on inode 18044, resetting magic number
bad version number 0x0 on inode 18044, resetting version number
imap claims a free inode 18044 is in use, correcting imap and clearing  
inode
cleared inode 18044
bad magic number 0x0 on inode 18045, resetting magic number
bad version number 0x0 on inode 18045, resetting version number
imap claims a free inode 18045 is in use, correcting imap and clearing  
inode
cleared inode 18045
bad magic number 0x0 on inode 18046, resetting magic number
bad version number 0x0 on inode 18046, resetting version number
imap claims a free inode 18046 is in use, correcting imap and clearing  
inode
cleared inode 18046
bad magic number 0x0 on inode 18047, resetting magic number
bad version number 0x0 on inode 18047, resetting version number
imap claims a free inode 18047 is in use, correcting imap and clearing  
inode
cleared inode 18047
         - agno = 1
         - agno = 2
         - agno = 3
         - agno = 4
         - agno = 5
         - agno = 6
         - agno = 7
         - agno = 8
         - agno = 9
         - agno = 10
         - agno = 11
         - agno = 12
         - agno = 13
         - agno = 14
         - agno = 15
         - agno = 16
         - agno = 17
         - agno = 18
         - agno = 19
         - agno = 20
         - agno = 21
         - agno = 22
         - agno = 23
         - agno = 24
         - agno = 25
         - agno = 26
         - agno = 27
         - agno = 28
         - agno = 29
         - agno = 30
         - agno = 31
         - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
         - setting up duplicate extent list...
         - check for inodes claiming duplicate blocks...
         - agno = 0
         - agno = 1
         - agno = 2
         - agno = 3
entry "classes.nib" in shortform directory 18009 references free inode  
18047
junking entry "classes.nib" in directory inode 18009
         - agno = 4
         - agno = 5
         - agno = 6
         - agno = 7
entry "Spanish.lproj" at block 0 offset 296 in directory inode  
1610630695 references free inode 18000
	clearing inode number in entry at offset 296...
         - agno = 8
         - agno = 9
         - agno = 10
         - agno = 11
         - agno = 12
         - agno = 13
         - agno = 14
         - agno = 15
         - agno = 16
         - agno = 17
         - agno = 18
         - agno = 19
         - agno = 20
         - agno = 21
         - agno = 22
         - agno = 23
         - agno = 24
         - agno = 25
         - agno = 26
         - agno = 27
         - agno = 28
         - agno = 29
         - agno = 30
         - agno = 31
entry "Resources" in shortform directory 4049684106 references free  
inode 18006
junking entry "Resources" in directory inode 4049684106
Phase 5 - rebuild AG headers and trees...
         - reset superblock...
Phase 6 - check inode connectivity...
         - resetting contents of realtime bitmap and summary inodes
         - traversing filesystem ...
bad hash table for directory inode 1610630695 (no data entry):  
rebuilding
rebuilding directory inode 1610630695
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
disconnected dir inode 18007, moving to lost+found
disconnected inode 18024, moving to lost+found
disconnected inode 18025, moving to lost+found
disconnected inode 18026, moving to lost+found
disconnected inode 18027, moving to lost+found
disconnected inode 18028, moving to lost+found
disconnected inode 18029, moving to lost+found
disconnected inode 18030, moving to lost+found
disconnected inode 18031, moving to lost+found
disconnected inode 18037, moving to lost+found
disconnected inode 18038, moving to lost+found
disconnected inode 18039, moving to lost+found
disconnected inode 18040, moving to lost+found
disconnected inode 18041, moving to lost+found
disconnected dir inode 268452448, moving to lost+found
disconnected dir inode 268452449, moving to lost+found
disconnected dir inode 536889431, moving to lost+found
disconnected dir inode 536889432, moving to lost+found
disconnected dir inode 805323820, moving to lost+found
disconnected dir inode 805323821, moving to lost+found
disconnected dir inode 1073761501, moving to lost+found
disconnected dir inode 1073761502, moving to lost+found
disconnected dir inode 1342194790, moving to lost+found
disconnected dir inode 1342194791, moving to lost+found
disconnected dir inode 1610630702, moving to lost+found
disconnected dir inode 1879067163, moving to lost+found
disconnected dir inode 2147967564, moving to lost+found
disconnected dir inode 2436769389, moving to lost+found
disconnected dir inode 2703685645, moving to lost+found
disconnected dir inode 2703685648, moving to lost+found
disconnected dir inode 2970453601, moving to lost+found
disconnected dir inode 3240533616, moving to lost+found
disconnected dir inode 3508468806, moving to lost+found
disconnected dir inode 3777743419, moving to lost+found
disconnected dir inode 4049684107, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 5682 nlinks from 2 to 24
resetting inode 1610630695 nlinks from 21 to 20
resetting inode 4049684106 nlinks from 3 to 2
done

Regards,

George

From sandeen@sandeen.net Tue Feb  3 19:46:59 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n141kwGW108407
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 19:46:59 -0600
X-ASG-Debug-ID: 1233711978-3557023e0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 762F4E3480
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:46:19 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id A0bF6Y7kCcS6sAzw for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:46:19 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n141kDGu018686;
	Tue, 3 Feb 2009 20:46:14 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n141kDlC012380;
	Tue, 3 Feb 2009 20:46:13 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n141kCEd012667;
	Tue, 3 Feb 2009 20:46:13 -0500
Message-ID: <4988F363.1070708@sandeen.net>
Date: Tue, 03 Feb 2009 19:46:11 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: George Barnett <george@alink.co.za>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: XFS corruption on ubuntu 2.6.27-9-server
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
References: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>	<4988EF37.7020306@sandeen.net> <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za>
In-Reply-To: <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233711979
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16946
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

George Barnett wrote:
> On 04/02/2009, at 12:28 PM, Eric Sandeen wrote:
> 
>> George Barnett wrote:
>>> Hi,
>>>
>>> I'm seeing the following errors:
>>>
>>> [822153.422851] Filesystem "md2": XFS internal error xfs_da_do_buf(2)
>>> at line 2107 of file /build/buildd/linux-2.6.27/fs/xfs/
>> we really should make that more informative.
>>
>> What it means is that you read a piece of metadata that did not match
>> any of the metadata magic numbers.
>>
>> hard to say whether it might be an xfs bug I think; this does come up
>> occasionally though and it'd at least be nice to print more details on
>> the error (what the magic *was*, what block, etc)
>>
>> Do you happen to have the repair output?
>>
>> Did your md raid lose power w/ write cache enabled?
> 
> Hi Eric,
> 
> Thanks for your response.  The system did not lose power.  This  
> failure just "happens".  I have a cronjob which rsync's /data to a  
> spare drive that's not on raid.  It seems that is enough to cause this  
> failure.
> 
> Fortunately, I still have the xfs_repair output in my term buffer:
> 
> root@slut:/# xfs_repair /dev/md2
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>          - zero log...
>          - scan filesystem freespace and inode maps...
>          - found root inode chunk
> Phase 3 - for each AG...
>          - scan and clear agi unlinked lists...
>          - process known inodes and perform inode discovery...
>          - agno = 0
> bad magic number 0x0 on inode 18042
> bad version number 0x0 on inode 18042
> bad magic number 0x0 on inode 18043
> bad version number 0x0 on inode 18043
> bad magic number 0x0 on inode 18044
> bad version number 0x0 on inode 18044
> bad magic number 0x0 on inode 18045
> bad version number 0x0 on inode 18045
> bad magic number 0x0 on inode 18046
> bad version number 0x0 on inode 18046
> bad magic number 0x0 on inode 18047
> bad version number 0x0 on inode 18047
> bad directory block magic # 0 in block 0 for directory inode 18000

Interesting that all the bad magic numbers were 0... not sure what to
make of that, offhand, I'm afraid...

-Eric

From george@alink.co.za Tue Feb  3 19:54:23 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n141sMvl108709
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 19:54:22 -0600
X-ASG-Debug-ID: 1233712422-355602870000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from poopey.oranged.to (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 3AF02E2E0E
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 17:53:42 -0800 (PST)
Received: from poopey.oranged.to (poopey.oranged.to [213.198.65.20]) by cuda.sgi.com with ESMTP id Lud6jdgFxxyMJhSJ for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 17:53:42 -0800 (PST)
Received: (qmail 25649 invoked by uid 89); 4 Feb 2009 01:53:41 -0000
Received: from unknown (HELO spoem.sydney.atlassian.com) (george@alink.co.za@203.63.130.33)
  by 0 with ESMTPA; 4 Feb 2009 01:53:41 -0000
Cc: xfs@oss.sgi.com
Message-Id: <7B2E904E-498E-4EEC-A09F-4DE823E4FAB0@alink.co.za>
From: George Barnett <george@alink.co.za>
To: Eric Sandeen <sandeen@sandeen.net>
In-Reply-To: <4988F363.1070708@sandeen.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
X-ASG-Orig-Subj: Re: XFS corruption on ubuntu 2.6.27-9-server
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
Date: Wed, 4 Feb 2009 12:53:38 +1100
References: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>	<4988EF37.7020306@sandeen.net> <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za> <4988F363.1070708@sandeen.net>
X-Mailer: Apple Mail (2.930.3)
X-Barracuda-Connect: poopey.oranged.to[213.198.65.20]
X-Barracuda-Start-Time: 1233712423
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16948
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On 04/02/2009, at 12:46 PM, Eric Sandeen wrote:

>> bad version number 0x0 on inode 18046
>> bad magic number 0x0 on inode 18047
>> bad version number 0x0 on inode 18047
>> bad directory block magic # 0 in block 0 for directory inode 18000
>
> Interesting that all the bad magic numbers were 0... not sure what to
> make of that, offhand, I'm afraid...

Oh dear.

I'm going to try moving the filesystem to ext3 to see if this  
continues.  If it does, it would suggest a bug in the underlying  
raid10 implementation or a problem with the disks, although they're  
not reporting any errors [1].

Is there any further debugging I can do before I start fresh?

George


1.  The hardware ecc recovered smartctl metric is /very/ high,  
although I'm told this may be normal for samsung drives.  I cant think  
of any way to confirm a disk problem without a CRC checking fs though.

From sandeen@sandeen.net Tue Feb  3 20:06:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n1426DUA109222
	for <xfs@oss.sgi.com>; Tue, 3 Feb 2009 20:06:14 -0600
X-ASG-Debug-ID: 1233713134-39d102ba0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id F2297E3007
	for <xfs@oss.sgi.com>; Tue,  3 Feb 2009 18:05:34 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id zLbgcupesLxZKFRz for <xfs@oss.sgi.com>; Tue, 03 Feb 2009 18:05:34 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1425USv021636;
	Tue, 3 Feb 2009 21:05:30 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1425U2q017801;
	Tue, 3 Feb 2009 21:05:30 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1425SSt015939;
	Tue, 3 Feb 2009 21:05:29 -0500
Message-ID: <4988F7E7.9050008@sandeen.net>
Date: Tue, 03 Feb 2009 20:05:27 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: George Barnett <george@alink.co.za>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: XFS corruption on ubuntu 2.6.27-9-server
Subject: Re: XFS corruption on ubuntu 2.6.27-9-server
References: <2653B83E-85DA-4949-BCED-AF2BA3D324E1@alink.co.za>	<4988EF37.7020306@sandeen.net> <5CCF20F5-33D5-409E-BB27-5E1C5CB4D9E5@alink.co.za> <4988F363.1070708@sandeen.net> <7B2E904E-498E-4EEC-A09F-4DE823E4FAB0@alink.co.za>
In-Reply-To: <7B2E904E-498E-4EEC-A09F-4DE823E4FAB0@alink.co.za>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233713134
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16948
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

George Barnett wrote:
> On 04/02/2009, at 12:46 PM, Eric Sandeen wrote:
> 
>>> bad version number 0x0 on inode 18046
>>> bad magic number 0x0 on inode 18047
>>> bad version number 0x0 on inode 18047
>>> bad directory block magic # 0 in block 0 for directory inode 18000
>> Interesting that all the bad magic numbers were 0... not sure what to
>> make of that, offhand, I'm afraid...
> 
> Oh dear.
> 
> I'm going to try moving the filesystem to ext3 to see if this  
> continues.  If it does, it would suggest a bug in the underlying  
> raid10 implementation or a problem with the disks, although they're  
> not reporting any errors [1].

one thing to note is that xfs is very good at detecting on-disk
corruption, not sure ext3 will be as good.  So ext3 may seem to run
finer, longer, even if there is an underlying problem.

> Is there any further debugging I can do before I start fresh?

well, it'd be great to have an isolated testcase, if you can reproduce
it succinctly.

Also I don't know what exact kernel ubuntu uses or what patches are in
it; you might try a stock upstream kernel w/ the same config,
2.6.27.$LATEST, and see if you continue to have problems.

-Eric

> George
> 
> 
> 1.  The hardware ecc recovered smartctl metric is /very/ high,  
> although I'm told this may be normal for samsung drives.  I cant think  
> of any way to confirm a disk problem without a CRC checking fs though.
> 

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 02:16:28 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n148GRot131650
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 02:16:28 -0600
X-ASG-Debug-ID: 1233735348-66d9011e0000-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 021E218BB653
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 00:15:48 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id kR84E1GWYR9Deh4O for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 00:15:48 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUcvD-0006Tk-3k; Wed, 04 Feb 2009 08:15:47 +0000
Date: Wed, 4 Feb 2009 03:15:47 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090204081547.GA21487@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090203214711.GA24837@infradead.org> <20090203220808.GA9195@infradead.org> <200902041648.55603.nickpiggin@yahoo.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902041648.55603.nickpiggin@yahoo.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233735349
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 04:48:55PM +1100, Nick Piggin wrote:
> OK, I could reproduce this directly with a vmap test. With this patch,
> I'm no longer able to. (not sure how this mail client goes with attaching
> patches, sorry if it messes up)

With that patch applies I run into a different issue:

[ 4909.811804] XFS mounting filesystem vde
[ 4909.986343] ------------[ cut here ]------------
[ 4909.999285] WARNING: at mm/vmalloc.c:105
vmap_page_range+0x159/0x1b0()
[ 4910.021800] Hardware name: 
[ 4910.032628] Modules linked in:
[ 4910.043549] Pid: 6770, comm: mount Not tainted 2.6.29-rc3-xfs #43
[ 4910.069113] Call Trace:
[ 4910.080264]  [<c079fbf6>] ? printk+0x18/0x1a
[ 4910.091954]  [<c014cca3>] warn_slowpath+0x73/0xd0
[ 4910.103164]  [<c019bb00>] ? __rmqueue_smallest+0xf0/0x170
[ 4910.124547]  [<c01b547a>] ? alloc_vmap_area+0x6a/0x240
[ 4910.139940]  [<c0139a05>] ? kvm_set_pte_at+0x45/0x50
[ 4910.161273]  [<c01b4f49>] vmap_page_range+0x159/0x1b0
[ 4910.172548]  [<c01b5931>] vm_map_ram+0x2e1/0x3a0
[ 4910.193782]  [<c0453c19>] ? kmem_alloc+0x59/0xf0
[ 4910.204960]  [<c0456eb9>] _xfs_buf_map_pages+0x89/0xc0
[ 4910.216249]  [<c0457027>] xfs_buf_get_noaddr+0x137/0x170
[ 4910.237660]  [<c0442ace>] xlog_get_bp+0x2e/0xd0
[ 4910.248825]  [<c0443a6b>] xlog_write_log_records+0x4b/0x260
[ 4910.270258]  [<c07a26e2>] ? _spin_unlock_irq+0x22/0x30
[ 4910.282965]  [<c0443d22>] xlog_clear_stale_blocks+0xa2/0x180
[ 4910.304712]  [<c0444fcc>] xlog_find_tail+0x46c/0x4f0
[ 4910.326012]  [<c0445064>] xlog_recover+0x14/0xa0
[ 4910.341291]  [<c043d9c0>] xfs_log_mount+0xa0/0x180
[ 4910.352791]  [<c04481e8>] xfs_mountfs+0x348/0x6d0
[ 4910.374052]  [<c05ac4e9>] ? __debug_object_init+0x229/0x340
[ 4910.385427]  [<c05ac647>] ? debug_object_init+0x17/0x20
[ 4910.406761]  [<c0156570>] ? init_timer+0x10/0x30
[ 4910.422081]  [<c0448ca4>] ? xfs_mru_cache_create+0x114/0x150
[ 4910.443597]  [<c045f01f>] xfs_fs_fill_super+0x1cf/0x310
[ 4910.464931]  [<c01c6dd3>] get_sb_bdev+0x123/0x150
[ 4910.476212]  [<c01dad87>] ? alloc_vfsmnt+0x77/0x100
[ 4910.487458]  [<c01a7e11>] ? kstrdup+0x31/0x60
[ 4910.508628]  [<c045d181>] xfs_fs_get_sb+0x21/0x30
[ 4910.520744]  [<c045ee50>] ? xfs_fs_fill_super+0x0/0x310
[ 4910.542092]  [<c01c5ada>] vfs_kern_mount+0x3a/0xa0
[ 4910.553307]  [<c01c5b99>] do_kern_mount+0x39/0xe0
[ 4910.564518]  [<c01dbacb>] do_mount+0x3ab/0x780
[ 4910.585736]  [<c05ab621>] ? _raw_spin_lock+0x41/0x120
[ 4910.597002]  [<c01da0ac>] ? copy_mount_options+0x3c/0x130
[ 4910.621489]  [<c01dbf29>] sys_mount+0x89/0xc0
[ 4910.632621]  [<c0120dfe>] syscall_call+0x7/0xb
[ 4910.643772]  [<c0120000>] ? restore_sigcontext+0x140/0x150
[ 4910.665203] ---[ end trace 5a228d052300b60a ]---
[ 4910.676954] xfs_buf_get_noaddr: failed to map pages

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 02:29:27 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n148TQYj132141
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 02:29:27 -0600
X-ASG-Debug-ID: 1233736128-7bb9030c0000-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 3E79618BB549
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 00:28:48 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AR3J4OAzhfjL92kB for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 00:28:48 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUd7J-0003I6-0x; Wed, 04 Feb 2009 08:28:17 +0000
Date: Wed, 4 Feb 2009 03:28:17 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: A rescue tool: xfs_irecover
Subject: Re: A rescue tool: xfs_irecover
Message-ID: <20090204082816.GA9111@infradead.org>
References: <alpine.LSU.2.00.0812292059020.15355@fbirervta.pbzchgretzou.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.0812292059020.15355@fbirervta.pbzchgretzou.qr>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233736128
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

I looked into importing this into xfsprogs, and from a quick look
it could be simplified a lot by using code from libxfs or maybe even
by merging it into xfs_db and using the infrastructure there.

But xfsprogs is licensed under GPLv2 and will stay that way as it shares
a lot of code with the kernel.  Are you willing to relicense the tool
under GPLv2 or later?

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 02:31:48 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n148VlCc132337
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 02:31:48 -0600
X-ASG-Debug-ID: 1233736268-053401690000-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 3A328E3D37
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 00:31:08 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id kCDg2O3H6YCFMCIE for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 00:31:08 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUd9Z-0006eJ-N1; Wed, 04 Feb 2009 08:30:37 +0000
Date: Wed, 4 Feb 2009 03:30:37 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090204083037.GA17493@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090203214711.GA24837@infradead.org> <20090203220808.GA9195@infradead.org> <200902041648.55603.nickpiggin@yahoo.com.au> <20090204081547.GA21487@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090204081547.GA21487@infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233736269
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 03:15:47AM -0500, Christoph Hellwig wrote:
> On Wed, Feb 04, 2009 at 04:48:55PM +1100, Nick Piggin wrote:
> > OK, I could reproduce this directly with a vmap test. With this patch,
> > I'm no longer able to. (not sure how this mail client goes with attaching
> > patches, sorry if it messes up)
> 
> With that patch applies I run into a different issue:

And later on we run out of vmalloc space a lot getting warnings like
this:

[ 5796.986579] vmap allocation for size 4194304 failed: use
vmalloc=<size> to increase size.
[ 5797.008728] xfs_buf_get_noaddr: failed to map pages


This didn't happen before.  Maybe it's a result of some of the more
lazy TLB flushing?

From michael.monnerie@is.it-management.at Wed Feb  4 02:53:29 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n148rTi1134020
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 02:53:29 -0600
X-ASG-Debug-ID: 1233737567-0a9e01470000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 0417F18BA0B3
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 00:52:47 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id izDzQHcwJNN4F99H for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 00:52:47 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 73ABC3D2E
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 09:52:45 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id D3EDB40016F
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 09:52:45 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 09:52:45 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <200902031140.08576@zmi.at> <20090203154907.GA21278@infradead.org>
In-Reply-To: <20090203154907.GA21278@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200902040952.45440@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233737568
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16974
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> Yeah, that sounds correct. =A0Do you volunteer for the FAQ entry?
> =A0xfs.org is a wiki so you could add it. =A0I'm happy to proof-read it
> if you want.

I don't know if it's good and correct, I just put this in the wiki, and=20
additionally changed 2 sections, please check the wiki log if it's=20
correct:

=3D=3D Q. What about the hard disk write cache? =3D=3D

The problem with hard disk write caches is that their contents are lost=20
in case of a power outage. With hard disk cache sizes of currently up to=20
32MB that can be a lot of valuable information.

With a single hard disk and barriers turned on (on=3Ddefault), a powerfail=
=20
"only" looses data in the cache but at least does not destroy the=20
filesystem.

With a RAID controller with battery backed cache, you should turn off=20
barriers, as recommended above. But then you *must* disable the hard=20
disk write cache in order to ensure to keep the filesystem intact after=20
a power failure.

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From jengelh@medozas.de Wed Feb  4 03:34:09 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n149Y9LY136471
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 03:34:09 -0600
X-ASG-Debug-ID: 1233740009-592f03700000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from sovereign.computergmbh.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 576BAE4201
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 01:33:29 -0800 (PST)
Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by cuda.sgi.com with ESMTP id 0iH2CYk05MWMVoWV for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 01:33:29 -0800 (PST)
Received: by sovereign.computergmbh.de (Postfix, from userid 25121)
	id 46479E4A68; Wed,  4 Feb 2009 10:33:28 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by sovereign.computergmbh.de (Postfix) with ESMTP id 453D042514AC;
	Wed,  4 Feb 2009 10:33:28 +0100 (CET)
Date: Wed, 4 Feb 2009 10:33:28 +0100 (CET)
From: Jan Engelhardt <jengelh@medozas.de>
Sender: jengelh@sovereign.computergmbh.de
To: Christoph Hellwig <hch@infradead.org>
cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: A rescue tool: xfs_irecover
Subject: Re: A rescue tool: xfs_irecover
In-Reply-To: <20090204082816.GA9111@infradead.org>
Message-ID: <alpine.LSU.2.00.0902041032510.27900@fbirervta.pbzchgretzou.qr>
References: <alpine.LSU.2.00.0812292059020.15355@fbirervta.pbzchgretzou.qr> <20090204082816.GA9111@infradead.org>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Barracuda-Connect: sovereign.computergmbh.de[85.214.69.204]
X-Barracuda-Start-Time: 1233740010
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16976
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wednesday 2009-02-04 09:28, Christoph Hellwig wrote:

>I looked into importing this into xfsprogs, and from a quick look
>it could be simplified a lot by using code from libxfs or maybe even
>by merging it into xfs_db and using the infrastructure there.
>
>But xfsprogs is licensed under GPLv2 and will stay that way as it shares
>a lot of code with the kernel.  Are you willing to relicense the tool
>under GPLv2 or later?

Yes; I updated the repository to reflect this (and add a manpage).

From michael.monnerie@is.it-management.at Wed Feb  4 04:28:29 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14ASS93143092
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 04:28:29 -0600
X-ASG-Debug-ID: 1233743267-71d0010c0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 2DC9C18BC22C
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 02:27:48 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id IVeeJBpyVSbotOn2 for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 02:27:48 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 9AB3D3D31
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 11:27:46 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id 279FD40016F
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 11:27:47 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 11:27:46 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at>
In-Reply-To: <200902040952.45440@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902041127.46714@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233743269
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16980
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Mittwoch 04 Februar 2009 Michael Monnerie wrote:
> == Q. What about the hard disk write cache? ==

What just comes to my mind: what about XEN/VMware?

What settings should be used within a virtual machine? Even if I have 
battery backed cache and nobarrier on the host, the VM itself could 
crash, or the whole host freeze. Is "nobarrier" save within a VM?

mfg zmi
-- 
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From david@fromorbit.com Wed Feb  4 06:09:57 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14C9uSF150532
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 06:09:57 -0600
X-ASG-Debug-ID: 1233749353-7a7700d40000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id AFFE6E5711
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 04:09:14 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id 3mIoH8v35621JB7O for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 04:09:14 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAFASiUl5LClx/2dsb2JhbADQNIQWBg
X-IronPort-AV: E=Sophos;i="4.37,378,1231075800"; 
   d="scan'208";a="282627264"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 04 Feb 2009 22:38:54 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUgYm-0006tH-Kb; Wed, 04 Feb 2009 23:08:52 +1100
Date: Wed, 4 Feb 2009 23:08:52 +1100
From: Dave Chinner <david@fromorbit.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
Message-ID: <20090204120852.GK24173@disturbed>
Mail-Followup-To: Mikulas Patocka <mpatocka@redhat.com>,
	Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
	linux-kernel@vger.kernel.org
References: <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com> <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com> <20090131235725.GA24173@disturbed> <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com> <20090203032740.GG24173@disturbed> <Pine.LNX.4.64.0902031459350.28433@hs20-bc2-1.build.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0902031459350.28433@hs20-bc2-1.build.redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233749357
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16985
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Tue, Feb 03, 2009 at 03:05:07PM -0500, Mikulas Patocka wrote:
> On Tue, 3 Feb 2009, Dave Chinner wrote:
> 
> > > No, if you turn it into a trylock, it will randomly fail if any other 
> > > process is holding the lock for whatever reason. So you will still get 
> > > spurious -ENOSPCs, although with lower probability.
> > 
> > The flush is never, ever going to be perfect. While we are blocking
> > waiting for the flush, other concurrent writes could be doing more
> > delayed allocation. The flush won't catch these, so we can still get
> > spurious ENOSPCs even with a *perfect* flush.
> 
> So you can turn it into a loop --- while there are delayed allocations, 
> flush and retry.

I don't think that is necessary having just instrumented the code:

[42949497.350000] Ai 7040, tl 7037, f 7037, w 0
[42949497.510000] i 6528, tl 6528, f 6528, w 0
[42949497.510000] i 3648, tl 3648, f 3648, w 0
[42949497.530000] i 1977, tl 1977, f 1977, w 0
[42949497.530000] Bi 7040, tl 7037, f 7037, w 7037
[42949497.550000] i 6528, tl 6528, f 6528, w 6528
[42949497.550000] i 3648, tl 3648, f 3648, w 3648
[42949497.550000] i 1977, tl 1977, f 1977, w 1977
[42949497.550000] CDd

A = start of xfs_flush_device
i = inodes in AG scanned for writeback
tl = trylocks that succeeded
f = number flushed
w = number waited for.
(there is 4 of these groups due to 4 AGs in the fs)
B = startof blocking flush
C = completion signaled
D = completion complete
d = xfs_flush_device done.

As you can see, there are only 3 inodes (of ~19,200) that weren't
successfully trylocked in the flush. I haven't seen any more than
that, either.

> ... and if you turn it into trylock, what are you going to do with the 
> inode that is just being written to? You should definitely flush it, but 
> trylock will skip it because it's already locked.

We've already flushed it directly. You disabled that code fearing
deadlocks. I've made it synchronous (i.e. not handed off to
xfssyncd) because the flush path requires us to hold the lock we are
already holding....

> > > There seems to be more bugs with forgetting to flush delayed allocation 
> > > --- you should flush delayed allocation after *every* failed allocate 
> > > attempt, but the code flushes it only after failed delayed allocate 
> > > attempt --- i.e. nondelayed allocators, such as xfs_iomap_write_direct 
> > > (and maybe other places) will still return -ENOSPC without attempting to 
> > > flush other inodes with delayed allocation.
.....
> > For metadata allocations (all over the place), we take a reservation
> > first
> 
> And what if the reservation fails? Do you flush in this case?

Well, if you read the rest of the paragraph you'd have the answer
to that question. I'll leave it quoted because it is relevant:

> > and so we could trigger a flush in certain circumstances if
> > the reservation fails (to avoid recursion and transaction subsystem
> > deadlocks). However, if you are not getting spurious enospc on
> > creating inodes (as opposed to writing to them) then I see no
> > immediate need for flushes there, either....

It is relevant because the test case Eric provided fails repeatedly
in xfs_create() on a reservation rather than on a data write, and
without a flush there no further data writes will occur to flush out
the blocks.

So a flush there is needed, too.

> > > @@ -415,6 +419,7 @@ xfs_syncd_queue_work(
> > >   * has failed with ENOSPC and we are in the process of scratching our
> > >   * heads, looking about for more room...
> > >   */
> > > +#if 0
> > >  STATIC void
> > >  xfs_flush_inode_work(
> > >  	struct xfs_mount *mp,
> > > @@ -424,16 +429,20 @@ xfs_flush_inode_work(
> > >  	filemap_flush(inode->i_mapping);
> > >  	iput(inode);
> > >  }
> > > +#endif
> > >  
> > >  void
> > >  xfs_flush_inode(
> > >  	xfs_inode_t	*ip)
> > >  {
> > > +#if 0
> > >  	struct inode	*inode = VFS_I(ip);
> > > +	DECLARE_COMPLETION_ONSTACK(completion);
> > >  
> > >  	igrab(inode);
> > > -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
> > > -	delay(msecs_to_jiffies(500));
> > > +	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work, &completion);
> > > +	wait_for_completion(&completion);
> > > +#endif
> > 
> > Why did you turn off the initial inode flush?
> 
> Because it recurses into Linux VFS layer and deadlocks.

Not at all. It calls into the writeback code (not the VFS)
which does not take any locks except page locks before it
calls back into ->writepages....

I've attached the WIP patch I have right now (based on yours) that
allows the test case to pass. It will need a bit of cleanup before
it is ready for prime-time, but is passes xfsqa here including the
ENOSPC stress tests.  Can you see if it fixes your test case and
whether it deadlocks?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com


Use xfs_sync_inodes and not sync_blockdev. XFS keeps it's dirty
metadata in different address spaces to the block device, so
sync_blockdev does nothing.

Change that 500ms delay to a wait for completion, so that the
behavior is not dependent on magic timeout values.

Add a trylock option to xfs_sync_inodes() so that it won't
deadlock if we are already holding an inode lock.

Add xfs_flush_device() to inode allocation failure in the create
path as that is the other place that typically falls over due to
outstanding delayed allocation extents.

Based on work from Mikulas Patocka <mpatocka@redhat.com>.

---
 fs/xfs/linux-2.6/xfs_fs_subr.c |   14 ++++----
 fs/xfs/linux-2.6/xfs_sync.c    |   66 +++++++++++++++++++--------------------
 fs/xfs/linux-2.6/xfs_sync.h    |    6 ++-
 fs/xfs/xfs_mount.h             |    2 +-
 fs/xfs/xfs_vnodeops.c          |    6 ++++
 5 files changed, 50 insertions(+), 44 deletions(-)

diff --git a/fs/xfs/linux-2.6/xfs_fs_subr.c b/fs/xfs/linux-2.6/xfs_fs_subr.c
index 5aeb777..08be36d 100644
--- a/fs/xfs/linux-2.6/xfs_fs_subr.c
+++ b/fs/xfs/linux-2.6/xfs_fs_subr.c
@@ -74,14 +74,14 @@ xfs_flush_pages(
 
 	if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
 		xfs_iflags_clear(ip, XFS_ITRUNCATED);
-		ret = filemap_fdatawrite(mapping);
-		if (flags & XFS_B_ASYNC)
-			return -ret;
-		ret2 = filemap_fdatawait(mapping);
-		if (!ret)
-			ret = ret2;
+		ret = -filemap_fdatawrite(mapping);
 	}
-	return -ret;
+	if (flags & XFS_B_ASYNC)
+		return ret;
+	ret2 = xfs_wait_on_pages(ip, first, last);
+	if (!ret)
+		ret = ret2;
+	return ret;
 }
 
 int
diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c
index a608e72..fddb9de 100644
--- a/fs/xfs/linux-2.6/xfs_sync.c
+++ b/fs/xfs/linux-2.6/xfs_sync.c
@@ -62,12 +62,6 @@ xfs_sync_inodes_ag(
 	uint32_t	first_index = 0;
 	int		error = 0;
 	int		last_error = 0;
-	int		fflag = XFS_B_ASYNC;
-
-	if (flags & SYNC_DELWRI)
-		fflag = XFS_B_DELWRI;
-	if (flags & SYNC_WAIT)
-		fflag = 0;		/* synchronous overrides all */
 
 	do {
 		struct inode	*inode;
@@ -128,12 +122,23 @@ xfs_sync_inodes_ag(
 		 * If we have to flush data or wait for I/O completion
 		 * we need to hold the iolock.
 		 */
-		if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) {
-			xfs_ilock(ip, XFS_IOLOCK_SHARED);
-			lock_flags |= XFS_IOLOCK_SHARED;
-			error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE);
-			if (flags & SYNC_IOWAIT)
+		if (flags & SYNC_DELWRI) {
+			if (VN_DIRTY(inode)) {
+				if (flags & SYNC_TRYLOCK) {
+					if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED))
+						lock_flags |= XFS_IOLOCK_SHARED;
+				} else {
+					xfs_ilock(ip, XFS_IOLOCK_SHARED);
+					lock_flags |= XFS_IOLOCK_SHARED;
+				}
+				if (lock_flags & XFS_IOLOCK_SHARED) {
+					error = xfs_flush_pages(ip, 0, -1,
+							XFS_B_ASYNC, FI_NONE);
+				}
+			}
+			if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) {
 				xfs_ioend_wait(ip);
+			}
 		}
 		xfs_ilock(ip, XFS_ILOCK_SHARED);
 
@@ -388,7 +393,7 @@ xfs_quiesce_attr(
 }
 
 /*
- * Enqueue a work item to be picked up by the vfs xfssyncd thread.
+ * Enqueue a work item to be picked up by the xfssyncd thread.
  * Doing this has two advantages:
  * - It saves on stack space, which is tight in certain situations
  * - It can be used (with care) as a mechanism to avoid deadlocks.
@@ -398,15 +403,17 @@ STATIC void
 xfs_syncd_queue_work(
 	struct xfs_mount *mp,
 	void		*data,
-	void		(*syncer)(struct xfs_mount *, void *))
+	void		(*syncer)(struct xfs_mount *, void *),
+	struct completion *completion)
 {
-	struct bhv_vfs_sync_work *work;
+	struct xfs_sync_work *work;
 
-	work = kmem_alloc(sizeof(struct bhv_vfs_sync_work), KM_SLEEP);
+	work = kmem_zalloc(sizeof(struct xfs_sync_work), KM_SLEEP);
 	INIT_LIST_HEAD(&work->w_list);
 	work->w_syncer = syncer;
 	work->w_data = data;
 	work->w_mount = mp;
+	work->w_completion = completion;
 	spin_lock(&mp->m_sync_lock);
 	list_add_tail(&work->w_list, &mp->m_sync_list);
 	spin_unlock(&mp->m_sync_lock);
@@ -419,25 +426,11 @@ xfs_syncd_queue_work(
  * has failed with ENOSPC and we are in the process of scratching our
  * heads, looking about for more room...
  */
-STATIC void
-xfs_flush_inode_work(
-	struct xfs_mount *mp,
-	void		*arg)
-{
-	struct inode	*inode = arg;
-	filemap_flush(inode->i_mapping);
-	iput(inode);
-}
-
 void
 xfs_flush_inode(
 	xfs_inode_t	*ip)
 {
-	struct inode	*inode = VFS_I(ip);
-
-	igrab(inode);
-	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
-	delay(msecs_to_jiffies(500));
+	xfs_flush_pages(ip, 0, -1, 0, FI_NONE);
 }
 
 /*
@@ -450,7 +443,8 @@ xfs_flush_device_work(
 	void		*arg)
 {
 	struct inode	*inode = arg;
-	sync_blockdev(mp->m_super->s_bdev);
+	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK);
+	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK | SYNC_IOWAIT);
 	iput(inode);
 }
 
@@ -459,10 +453,11 @@ xfs_flush_device(
 	xfs_inode_t	*ip)
 {
 	struct inode	*inode = VFS_I(ip);
+	DECLARE_COMPLETION_ONSTACK(completion);
 
 	igrab(inode);
-	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work);
-	delay(msecs_to_jiffies(500));
+	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work, &completion);
+	wait_for_completion(&completion);
 	xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC);
 }
 
@@ -497,7 +492,7 @@ xfssyncd(
 {
 	struct xfs_mount	*mp = arg;
 	long			timeleft;
-	bhv_vfs_sync_work_t	*work, *n;
+	xfs_sync_work_t		*work, *n;
 	LIST_HEAD		(tmp);
 
 	set_freezable();
@@ -530,6 +525,8 @@ xfssyncd(
 		list_for_each_entry_safe(work, n, &tmp, w_list) {
 			(*work->w_syncer)(mp, work->w_data);
 			list_del(&work->w_list);
+			if (work->w_completion)
+				complete(work->w_completion);
 			if (work == &mp->m_sync_work)
 				continue;
 			kmem_free(work);
@@ -545,6 +542,7 @@ xfs_syncd_init(
 {
 	mp->m_sync_work.w_syncer = xfs_sync_worker;
 	mp->m_sync_work.w_mount = mp;
+	mp->m_sync_work.w_completion = NULL;
 	mp->m_sync_task = kthread_run(xfssyncd, mp, "xfssyncd");
 	if (IS_ERR(mp->m_sync_task))
 		return -PTR_ERR(mp->m_sync_task);
diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h
index 5f6de1e..de87a7f 100644
--- a/fs/xfs/linux-2.6/xfs_sync.h
+++ b/fs/xfs/linux-2.6/xfs_sync.h
@@ -20,18 +20,20 @@
 
 struct xfs_mount;
 
-typedef struct bhv_vfs_sync_work {
+typedef struct xfs_sync_work {
 	struct list_head	w_list;
 	struct xfs_mount	*w_mount;
 	void			*w_data;	/* syncer routine argument */
 	void			(*w_syncer)(struct xfs_mount *, void *);
-} bhv_vfs_sync_work_t;
+	struct completion	*w_completion;
+} xfs_sync_work_t;
 
 #define SYNC_ATTR		0x0001	/* sync attributes */
 #define SYNC_DELWRI		0x0002	/* look at delayed writes */
 #define SYNC_WAIT		0x0004	/* wait for i/o to complete */
 #define SYNC_BDFLUSH		0x0008	/* BDFLUSH is calling -- don't block */
 #define SYNC_IOWAIT		0x0010  /* wait for all I/O to complete */
+#define SYNC_TRYLOCK		0x0020  /* only try to lock inodes */
 
 int xfs_syncd_init(struct xfs_mount *mp);
 void xfs_syncd_stop(struct xfs_mount *mp);
diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index f5e9937..775a2ac 100644
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -322,7 +322,7 @@ typedef struct xfs_mount {
 #endif
 	struct xfs_mru_cache	*m_filestream;  /* per-mount filestream data */
 	struct task_struct	*m_sync_task;	/* generalised sync thread */
-	bhv_vfs_sync_work_t	m_sync_work;	/* work item for VFS_SYNC */
+	xfs_sync_work_t		m_sync_work;	/* work item for VFS_SYNC */
 	struct list_head	m_sync_list;	/* sync thread work item list */
 	spinlock_t		m_sync_lock;	/* work item list lock */
 	int			m_sync_seq;	/* sync thread generation no. */
diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
index 0e55c5d..e1099e7 100644
--- a/fs/xfs/xfs_vnodeops.c
+++ b/fs/xfs/xfs_vnodeops.c
@@ -1449,6 +1449,12 @@ xfs_create(
 	error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0,
 			XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);
 	if (error == ENOSPC) {
+		/* flush delalloc blocks and retry */
+		xfs_flush_device(dp);
+		error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0,
+			XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);
+	}
+	if (error == ENOSPC) {
 		resblks = 0;
 		error = xfs_trans_reserve(tp, 0, XFS_CREATE_LOG_RES(mp), 0,
 				XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);

From david@fromorbit.com Wed Feb  4 06:23:24 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14CNOMJ151233
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 06:23:24 -0600
X-ASG-Debug-ID: 1233750163-76e9010a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 628B81BB51F9
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 04:22:44 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id GcfPnUZVxOKONv4i for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 04:22:44 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAAsWiUl5LClx/2dsb2JhbADQL4QWBg
X-IronPort-AV: E=Sophos;i="4.37,378,1231075800"; 
   d="scan'208";a="282631863"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 04 Feb 2009 22:52:42 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUgm9-0007GA-Ic; Wed, 04 Feb 2009 23:22:41 +1100
Date: Wed, 4 Feb 2009 23:22:41 +1100
From: Dave Chinner <david@fromorbit.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204122241.GL24173@disturbed>
Mail-Followup-To: Michael Monnerie <michael.monnerie@is.it-management.at>,
	xfs@oss.sgi.com
References: <498376CF.8020806@renderforce.de> <200902031140.08576@zmi.at> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200902040952.45440@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233750165
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16987
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 09:52:45AM +0100, Michael Monnerie wrote:
> On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > Yeah, that sounds correct.  Do you volunteer for the FAQ entry?
> >  xfs.org is a wiki so you could add it.  I'm happy to proof-read it
> > if you want.
> 
> I don't know if it's good and correct, I just put this in the wiki, and 
> additionally changed 2 sections, please check the wiki log if it's 
> correct:
> 
> == Q. What about the hard disk write cache? ==
> 
> The problem with hard disk write caches is that their contents are lost 
> in case of a power outage. With hard disk cache sizes of currently up to 
> 32MB that can be a lot of valuable information.
> 
> With a single hard disk and barriers turned on (on=default), a powerfail 
> "only" looses data in the cache but at least does not destroy the 
> filesystem.

I'd drop this paragraph - powerfail can destroy filesystems even on
a single disk (e.g. root directory gets corrupted).

> With a RAID controller with battery backed cache, you should turn off 
> barriers, as recommended above. But then you *must* disable the hard 
> disk write cache in order to ensure to keep the filesystem intact after 
> a power failure.

I'd change this to say "*must* disable the individual hard disk
write caches" to make it clear that it is referencing the disks
behind the raid controller. I'd also say "The method for doing this
is different for each RAID controller. Please consult your RAID
controller documentation to determine how to change these settings."

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From david@fromorbit.com Wed Feb  4 06:27:08 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14CR7Bm151424
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 06:27:08 -0600
X-ASG-Debug-ID: 1233750387-71dc03350000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id EBF7C1BB6271
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 04:26:28 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id MVBsz7SeBvWOhWBC for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 04:26:28 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAAsWiUl5LClx/2dsb2JhbADQL4QWBg
X-IronPort-AV: E=Sophos;i="4.37,378,1231075800"; 
   d="scan'208";a="282633014"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 04 Feb 2009 22:56:26 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUgpl-0007Ko-Mc; Wed, 04 Feb 2009 23:26:25 +1100
Date: Wed, 4 Feb 2009 23:26:25 +1100
From: Dave Chinner <david@fromorbit.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204122625.GM24173@disturbed>
Mail-Followup-To: Michael Monnerie <michael.monnerie@is.it-management.at>,
	xfs@oss.sgi.com
References: <498376CF.8020806@renderforce.de> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at> <200902041127.46714@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902041127.46714@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233750388
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0013 1.0000 -2.0128
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -2.01
X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16987
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 11:27:46AM +0100, Michael Monnerie wrote:
> On Mittwoch 04 Februar 2009 Michael Monnerie wrote:
> > == Q. What about the hard disk write cache? ==
> 
> What just comes to my mind: what about XEN/VMware?
> 
> What settings should be used within a virtual machine? Even if I have 
> battery backed cache and nobarrier on the host, the VM itself could 
> crash, or the whole host freeze. Is "nobarrier" save within a VM?

Depends on the implementation of the hypervisor.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From eflorac@intellique.com Wed Feb  4 06:46:22 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22,
	RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14CkMoc152320
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 06:46:22 -0600
X-ASG-Debug-ID: 1233751540-1fb401450000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from smtp6-g21.free.fr (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id A96A7E5D1A
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 04:45:41 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by cuda.sgi.com with ESMTP id eSaLgmBsAMbBDNR6 for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 04:45:41 -0800 (PST)
Received: from smtp6-g21.free.fr (localhost [127.0.0.1])
	by smtp6-g21.free.fr (Postfix) with ESMTP id ED62FE0814F;
	Wed,  4 Feb 2009 13:45:37 +0100 (CET)
Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72])
	by smtp6-g21.free.fr (Postfix) with ESMTP id CC162E081C6;
	Wed,  4 Feb 2009 13:45:34 +0100 (CET)
Date: Wed, 4 Feb 2009 13:45:38 +0100
From: Emmanuel Florac <eflorac@intellique.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Michael Monnerie <michael.monnerie@is.it-management.at>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204134538.24c2b4ac@harpe.intellique.com>
In-Reply-To: <20090204122241.GL24173@disturbed>
References: <498376CF.8020806@renderforce.de>
	<200902031140.08576@zmi.at>
	<20090203154907.GA21278@infradead.org>
	<200902040952.45440@zmi.at>
	<20090204122241.GL24173@disturbed>
Organization: Intellique
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Barracuda-Connect: smtp6-g21.free.fr[212.27.42.6]
X-Barracuda-Start-Time: 1233751543
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16987
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Le Wed, 4 Feb 2009 23:22:41 +1100
Dave Chinner <david@fromorbit.com> =E9crivait:

>  Please consult your RAID
> controller documentation to determine how to change these settings."

I have some controllers at hand, and I had a quick glance :

- Adaptec : allows setting individual drives cache
	 arcconf setcache <disk> wb|wt
<disk
- 3ware : no information

- Xyratex : no information

- Areca : Allows setting individual cache for passthru disks, needs
actual testing for drives part of an array.



--=20
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

From Peter.Kelemen@cern.ch Wed Feb  4 08:02:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14E2rqC154599
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 08:02:53 -0600
X-ASG-Debug-ID: 1233756132-3aec00410000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ninsei.hu (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 0169118BC7E3
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 06:02:12 -0800 (PST)
Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by cuda.sgi.com with ESMTP id djYasZNCHwQgXNXo for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 06:02:12 -0800 (PST)
Received: from kyra (lns-bzn-35-82-250-247-85.adsl.proxad.net [82.250.247.85])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by chatsubo.ninsei.hu (Postfix) with ESMTP id 46D427834;
	Wed,  4 Feb 2009 15:01:34 +0100 (CET)
Received: by kyra (Postfix, from userid 32266)
	id BFB85204A368; Wed,  4 Feb 2009 15:01:13 +0100 (CET)
Date: Wed, 4 Feb 2009 15:01:13 +0100
From: KELEMEN Peter <Peter.Kelemen@cern.ch>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: Dave Chinner <david@fromorbit.com>,
        Michael Monnerie <michael.monnerie@is.it-management.at>,
        xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204140113.GP11617@kyra>
Mail-Followup-To: Emmanuel Florac <eflorac@intellique.com>,
	Dave Chinner <david@fromorbit.com>,
	Michael Monnerie <michael.monnerie@is.it-management.at>,
	xfs@oss.sgi.com
References: <498376CF.8020806@renderforce.de> <200902031140.08576@zmi.at> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at> <20090204122241.GL24173@disturbed> <20090204134538.24c2b4ac@harpe.intellique.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20090204134538.24c2b4ac@harpe.intellique.com>
Errors-To: Peter.Kelemen@free.fr
Organization: CERN European Laboratory for Particle Physics, Switzerland
X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03
X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356  7BF0 8F3E CAB6 9FF0 CABE
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ninsei.hu[212.92.23.158]
X-Barracuda-Start-Time: 1233756133
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0190
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16992
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

* Emmanuel Florac (eflorac@intellique.com) [20090204 13:45]:

> - 3ware : no information

	/cX/uX set cache=off

http://www.3ware.com/support/UserDocs/CLIGuide-9.5.1.1.pdf , page 86

HTH,
Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen@cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From michael.monnerie@is.it-management.at Wed Feb  4 09:04:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14F44An157782
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:04:05 -0600
X-ASG-Debug-ID: 1233759803-594002480000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 4AD4D18C21D7
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:03:24 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id AGsPVHKFBalvOIbt for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:03:24 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 273183D47
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:03:23 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id E9CA8400171
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:03:22 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 16:03:22 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <200902041127.46714@zmi.at> <20090204122625.GM24173@disturbed>
In-Reply-To: <20090204122625.GM24173@disturbed>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart4131192.kjtSvqH3vs";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902041603.22541@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233759805
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16996
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart4131192.kjtSvqH3vs
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Mittwoch 04 Februar 2009 Dave Chinner wrote:
> > What just comes to my mind: what about XEN/VMware?
> >
> > What settings should be used within a virtual machine? Even if I
> > have battery backed cache and nobarrier on the host, the VM itself
> > could crash, or the whole host freeze. Is "nobarrier" save within a
> > VM?
>
> Depends on the implementation of the hypervisor.

OK, so we don't know?=20
I guess VMware will be the most used for Linux systems, and XEN usage=20
will soon grow a lot as it's directly in the kernel now. Does anybody=20
know for those two, whether "nobarrier" is save/needed/a bad thing?

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart4131192.kjtSvqH3vs
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmJrjoACgkQzhSR9xwSCbTDcwCgs4dPquiLURx2rdkfCEm5Crye
srsAniOxT5NISyvo7jDBkn23mQ2bUsN2
=hccy
-----END PGP SIGNATURE-----

--nextPart4131192.kjtSvqH3vs--

From eflorac@intellique.com Wed Feb  4 09:16:45 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53,
	RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14FGiJC158823
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:16:45 -0600
X-ASG-Debug-ID: 1233760560-3af3015b0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from smtp5-g21.free.fr (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 1807718C24D0
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:16:04 -0800 (PST)
Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by cuda.sgi.com with ESMTP id Pmbpbl7Rl6cdHYss for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:16:04 -0800 (PST)
Received: from smtp5-g21.free.fr (localhost [127.0.0.1])
	by smtp5-g21.free.fr (Postfix) with ESMTP id 2A089D480E6;
	Wed,  4 Feb 2009 16:15:56 +0100 (CET)
Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72])
	by smtp5-g21.free.fr (Postfix) with ESMTP id 0B52ED4812E;
	Wed,  4 Feb 2009 16:15:54 +0100 (CET)
Date: Wed, 4 Feb 2009 16:15:59 +0100
From: Emmanuel Florac <eflorac@intellique.com>
To: KELEMEN Peter <Peter.Kelemen@cern.ch>
Cc: Dave Chinner <david@fromorbit.com>,
        Michael Monnerie
 <michael.monnerie@is.it-management.at>,
        xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204161559.347679f7@harpe.intellique.com>
In-Reply-To: <20090204140113.GP11617@kyra>
References: <498376CF.8020806@renderforce.de>
	<200902031140.08576@zmi.at>
	<20090203154907.GA21278@infradead.org>
	<200902040952.45440@zmi.at>
	<20090204122241.GL24173@disturbed>
	<20090204134538.24c2b4ac@harpe.intellique.com>
	<20090204140113.GP11617@kyra>
Organization: Intellique
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Barracuda-Connect: smtp5-g21.free.fr[212.27.42.5]
X-Barracuda-Start-Time: 1233760566
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16996
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Le Wed, 4 Feb 2009 15:01:13 +0100
KELEMEN Peter <Peter.Kelemen@cern.ch> =E9crivait:

> > - 3ware : no information =20
>=20
> 	/cX/uX set cache=3Doff

Yes but it set cache for the array globally, I don't find anything about
the individual disks write cache specifically. Same thing for Xyratex.

BTW I checked LSI MegaRAID  and it allows setting individual disks
cache too :

MegaCli -AdpCacheFlush -aN|-a0,1,2|-aALL -EnDskCache|DisDskCache=20

So for now we have the following :

disk cache settings control

3Ware : no
Xyratex : no
Adaptec : yes
LSI : yes
Areca : possibly...

--=20
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

From michael.monnerie@is.it-management.at Wed Feb  4 09:25:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14FPDgA159134
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:25:13 -0600
X-ASG-Debug-ID: 1233761073-1035029f0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 747EFE6A27
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:24:33 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id 302X1c7yJABvl4PM for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:24:33 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 3D42A3D4F
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:24:33 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id EC9A9400171
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:24:32 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 16:24:27 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <200902040952.45440@zmi.at> <20090204122241.GL24173@disturbed>
In-Reply-To: <20090204122241.GL24173@disturbed>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart5224402.24jGHsuhDg";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902041624.32354@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233761074
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16998
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart5224402.24jGHsuhDg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

(compressing 2 answers here)

On Mittwoch 04 Februar 2009 Dave Chinner wrote:
> > With a single hard disk and barriers turned on (on=3Ddefault), a
> > powerfail "only" looses data in the cache but at least does not
> > destroy the filesystem.
>
> I'd drop this paragraph - powerfail can destroy filesystems even on
> a single disk (e.g. root directory gets corrupted).

Isn't that what barriers are for? If I understand correctly, barriers=20
help against destroying the filesys, except root dir? But that should=20
"easily" be fixable with xfs_repair or so?

I'd like to have a paragraph for normal XFS users, a PC with harddisks,=20
maybe with onboard RAID1 or 10. So if I could let the paragraph, that=20
should be OK (as I hope the root dir destroy is a very, very seldom=20
case).

> > With a RAID controller with battery backed cache, you should turn
> > off barriers, as recommended above. But then you *must* disable the
> > hard disk write cache in order to ensure to keep the filesystem
> > intact after a power failure.
>
> I'd change this to say "*must* disable the individual hard disk
> write caches" to make it clear that it is referencing the disks
> behind the raid controller. I'd also say "The method for doing this
> is different for each RAID controller. Please consult your RAID
> controller documentation to determine how to change these settings."

That sounds good and I'll put it in.

On Mittwoch 04 Februar 2009 Emmanuel Florac wrote:
> I have some controllers at hand, and I had a quick glance :
> - Areca : Allows setting individual cache for passthru disks, needs
> actual testing for drives part of an array.

Areca allows "Disk Write Cache Mode" on/off under "System Controls" ->=20
"System Config" in the archttpd web interface, plus per Volume write=20
back cache on/off, but that's not relevant when using battery (and those=20
who don't - don't care anyway about their data).

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart5224402.24jGHsuhDg
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmJszAACgkQzhSR9xwSCbTaoACg6udMEqM+KztpqeWtO8CwTFXD
PjoAoN7wdkuplK2pidl1hHP/k8saBtpF
=5vXg
-----END PGP SIGNATURE-----

--nextPart5224402.24jGHsuhDg--

From michael.monnerie@is.it-management.at Wed Feb  4 09:26:22 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14FQMH8159273
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:26:22 -0600
X-ASG-Debug-ID: 1233761143-3af2018f0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 9816018C252D
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:25:43 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id wyaK9ifUWuwblzAX for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:25:43 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 932213D51
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:25:42 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id 67195400171
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:25:42 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 16:25:41 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090204140113.GP11617@kyra> <20090204161559.347679f7@harpe.intellique.com>
In-Reply-To: <20090204161559.347679f7@harpe.intellique.com>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart2294972.TRfJqUbHsh";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902041625.42174@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233761143
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16998
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart2294972.TRfJqUbHsh
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Mittwoch 04 Februar 2009 Emmanuel Florac wrote:

[This talk is about which controllers allow individual disk write cache=20
to be turned off]
> 3Ware : no
> Xyratex : no
> Adaptec : yes
> LSI : yes
> Areca : possibly...

correcting:
Areca: yes

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart2294972.TRfJqUbHsh
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmJs3YACgkQzhSR9xwSCbR/FgCg9zdCkkNmGS61f3sYGWQuKcUP
+SQAoMzmTNnsaIvg2U+e2aDt0bbdlnPQ
=hKuD
-----END PGP SIGNATURE-----

--nextPart2294972.TRfJqUbHsh--

From ralf@theco.de Wed Feb  4 09:34:09 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14FY879159535
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:34:08 -0600
X-ASG-Debug-ID: 1233761605-1aa302520000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from theco.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 7853618C1B62
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:33:25 -0800 (PST)
Received: from theco.de (scout.theco.de.mind.de [212.42.230.55]) by cuda.sgi.com with ESMTP id vc8xWwfknJLKQsGt for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:33:25 -0800 (PST)
Received: (qmail 11036 invoked from network); 4 Feb 2009 15:33:21 -0000
Received: from pd956aa94.dip0.t-ipconnect.de (HELO theco.de) (217.86.170.148)
  by scout.theco.de.mind.de with DES-CBC3-SHA encrypted SMTP cert admin@theco.de; 4 Feb 2009 15:33:21 -0000
Received: (qmail 31881 invoked from network); 4 Feb 2009 15:33:23 -0000
Received: from photon.intern.theco.de (HELO theco.de) (192.168.194.153)
  by neutron.intern.theco.de with SMTP; 4 Feb 2009 15:33:23 -0000
Received: by theco.de (sSMTP sendmail emulation); Wed, 4 Feb 2009 16:33:22 +0100
Date: Wed, 4 Feb 2009 16:33:22 +0100
From: Ralf Liebenow <ralf@theco.de>
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204153322.GC15454@theco.de>
Reply-To: ralf@theco.de
References: <498376CF.8020806@renderforce.de> <200902031140.08576@zmi.at> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at> <20090204122241.GL24173@disturbed>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20090204122241.GL24173@disturbed>
Organization: theCo.de AG
User-Agent: Mutt/1.5.9i
X-Barracuda-Connect: scout.theco.de.mind.de[212.42.230.55]
X-Barracuda-Start-Time: 1233761606
X-Barracuda-Bayes: INNOCENT GLOBAL 0.1886 1.0000 -0.8886
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -0.89
X-Barracuda-Spam-Status: No, SCORE=-0.89 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16998
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hello !

Maybe this is a stupid question:

Should Battery backed RAID controllers not always set their discs cache off ?

As I see it (in case of a power failure):
  - the discs are connectet to the main power, so if there is a power
    failure they're offline at that moment in time and their (write) cache will
    be gone in that instance of time too 

  - if they are connected to a battery backed RAID cache, I assume that
    this cache will be written as soon as the system is online again
    (if the battery lasts that long)

  - if a RAID controller does not turn off the disks write cache, the controller
    cannot know if previous writes have made it to the disk. A good
    RAID Controller would also use its cache to re-organise the disc 
    writes to minimize seek times doing somthing like intelligent
    command queuing. This would also mean, that any order of writes
    to a disk could have been changed by the controller. This would
    ultimately break any filesystem which does not explicitly fsyncing
    consistent checkpoints to the disk, which would make battery backed
    RAID Systems pretty useless ... would it ?
  
    So .. a battery backed RAID controller should default to "no disk write cache"
    should it ? Otherwise why should anyone want to use such expensive
    controllers ... it just does not make sense to have a battery backed
    cache on the controller, when things get inconsistent at a power
    outage ... It wouldn't have any purpuse ... I hope developers of
    battery backed RAID controllers are aware of that implication ...

  Greets
    Ralf

> On Wed, Feb 04, 2009 at 09:52:45AM +0100, Michael Monnerie wrote:
> > On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > > Yeah, that sounds correct.  Do you volunteer for the FAQ entry?
> > >  xfs.org is a wiki so you could add it.  I'm happy to proof-read it
> > > if you want.
> > 
> > I don't know if it's good and correct, I just put this in the wiki, and 
> > additionally changed 2 sections, please check the wiki log if it's 
> > correct:
> > 
> > == Q. What about the hard disk write cache? ==
> > 
> > The problem with hard disk write caches is that their contents are lost 
> > in case of a power outage. With hard disk cache sizes of currently up to 
> > 32MB that can be a lot of valuable information.
> > 
> > With a single hard disk and barriers turned on (on=default), a powerfail 
> > "only" looses data in the cache but at least does not destroy the 
> > filesystem.
> 
> I'd drop this paragraph - powerfail can destroy filesystems even on
> a single disk (e.g. root directory gets corrupted).
> 
> > With a RAID controller with battery backed cache, you should turn off 
> > barriers, as recommended above. But then you *must* disable the hard 
> > disk write cache in order to ensure to keep the filesystem intact after 
> > a power failure.
> 
> I'd change this to say "*must* disable the individual hard disk
> write caches" to make it clear that it is referencing the disks
> behind the raid controller. I'd also say "The method for doing this
> is different for each RAID controller. Please consult your RAID
> controller documentation to determine how to change these settings."
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

-- 
theCode AG 
HRB 78053, Amtsgericht Charlottenbg
USt-IdNr.: DE204114808
Vorstand: Ralf Liebenow, Michael Oesterreich, Peter Witzel
Aufsichtsratsvorsitzender: Wolf von Jaduczynski
Oranienstr. 10-11, 10997 Berlin [×]
fon +49 30 617 897-0  fax -10
ralf@theCo.de http://www.theCo.de

From Peter.Kelemen@cern.ch Wed Feb  4 09:42:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14Fgqw4159768
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 09:42:53 -0600
X-ASG-Debug-ID: 1233762133-21e402600000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ninsei.hu (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 14480E6FCC
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 07:42:13 -0800 (PST)
Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by cuda.sgi.com with ESMTP id ACqIyVCliHu8g1DD for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 07:42:13 -0800 (PST)
Received: from kyra (lns-bzn-35-82-250-247-85.adsl.proxad.net [82.250.247.85])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by chatsubo.ninsei.hu (Postfix) with ESMTP id 830257834;
	Wed,  4 Feb 2009 16:42:12 +0100 (CET)
Received: by kyra (Postfix, from userid 32266)
	id D81E5204A368; Wed,  4 Feb 2009 16:41:53 +0100 (CET)
Date: Wed, 4 Feb 2009 16:41:53 +0100
From: KELEMEN Peter <Peter.Kelemen@cern.ch>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: Dave Chinner <david@fromorbit.com>,
        Michael Monnerie <michael.monnerie@is.it-management.at>,
        xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204154153.GQ11617@kyra>
Mail-Followup-To: Emmanuel Florac <eflorac@intellique.com>,
	Dave Chinner <david@fromorbit.com>,
	Michael Monnerie <michael.monnerie@is.it-management.at>,
	xfs@oss.sgi.com
References: <498376CF.8020806@renderforce.de> <200902031140.08576@zmi.at> <20090203154907.GA21278@infradead.org> <200902040952.45440@zmi.at> <20090204122241.GL24173@disturbed> <20090204134538.24c2b4ac@harpe.intellique.com> <20090204140113.GP11617@kyra> <20090204161559.347679f7@harpe.intellique.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20090204161559.347679f7@harpe.intellique.com>
Errors-To: Peter.Kelemen@free.fr
Organization: CERN European Laboratory for Particle Physics, Switzerland
X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03
X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356  7BF0 8F3E CAB6 9FF0 CABE
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ninsei.hu[212.92.23.158]
X-Barracuda-Start-Time: 1233762134
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.16998
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

* Emmanuel Florac (eflorac@intellique.com) [20090204 16:15]:

> Yes but it set cache for the array globally, I don't find
> anything about the individual disks write cache specifically.
> Same thing for Xyratex.

"Write cache includes the disk drive cache and controller cache."

I assume this means you can only set the drive caches and the unit
caches together.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \     Peter.Kelemen@cern.ch
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From michael.monnerie@is.it-management.at Wed Feb  4 10:02:16 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14G2FOI160571
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 10:02:16 -0600
X-ASG-Debug-ID: 1233763296-3afe020c0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id CAE8518C1C61
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 08:01:36 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id Yi0G97jFfd1ok8Ff for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 08:01:36 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 3F78B3D50
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 17:01:04 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id 0EE29400171
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 17:01:04 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 17:01:03 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090204161559.347679f7@harpe.intellique.com> <20090204154153.GQ11617@kyra>
In-Reply-To: <20090204154153.GQ11617@kyra>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart2970246.aGHt098iLf";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902041701.03803@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233763296
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17000
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart2970246.aGHt098iLf
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Mittwoch 04 Februar 2009 KELEMEN Peter wrote:
> I assume this means you can only set the drive caches and the unit
> caches together.

Should I write an overview as we had it here on the list into the wiki?=20
Could be a quick guide and therefore good I guess.

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart2970246.aGHt098iLf
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmJu78ACgkQzhSR9xwSCbTfagCg2ns7TK8B/h9OGip0uK4hebxW
7MwAoIJL898ADq8KYFhNUtvkdxpP1D5P
=G801
-----END PGP SIGNATURE-----

--nextPart2970246.aGHt098iLf--

From michael.monnerie@is.it-management.at Wed Feb  4 10:18:58 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14GIv1P161251
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 10:18:58 -0600
X-ASG-Debug-ID: 1233764296-21e503aa0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id DCFFEE7420
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 08:18:17 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id 8Q1MpqN5n1HjQzss for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 08:18:17 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id 514A83D51;
	Wed,  4 Feb 2009 17:18:16 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id 2DE2B400171;
	Wed,  4 Feb 2009 17:18:16 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: ralf@theco.de, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 17:18:15 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090204122241.GL24173@disturbed> <20090204153322.GC15454@theco.de>
In-Reply-To: <20090204153322.GC15454@theco.de>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart7276097.jXn00mXb1W";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902041718.15836@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233764297
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0291 1.0000 -1.8328
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.83
X-Barracuda-Spam-Status: No, SCORE=-1.83 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17000
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart7276097.jXn00mXb1W
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Mittwoch 04 Februar 2009 Ralf Liebenow wrote:
> Should Battery backed RAID controllers not always set their discs
> cache off ?
>
> As I see it (in case of a power failure):
>   - the discs are connectet to the main power, so if there is a power
>     failure they're offline at that moment in time and their (write)
> cache will be gone in that instance of time too

Normally a server is on a UPS, and that should report when there's a=20
power outage so the server has enough time to gracefully shut down.=20
Still, there can be other events such as:
=2D power supply error. Even with redundant PS, an outage can exist
=2D human error (coffee into the server, someone unplugging the cable=20
between UPS and server,...)
=2D and of course mainboard/cpu/ram total crashes
so you are basically never safe.

>   - if a RAID controller does not turn off the disks write cache, the
> controller cannot know if previous writes have made it to the disk.

The controller could keep in-transfer blocks in it's cache, waiting for=20
a confirm from the disk that the blocks are on the media, and only=20
afterwards remove it from cache. I don't know if controllers do that=20
actually. I'll ask Areca support on that.

> good RAID Controller would also use its cache to re-organise the disc
> writes to minimize seek times doing somthing like intelligent command
> queuing. This would also mean, that any order of writes to a disk
> could have been changed by the controller. This would ultimately
> break any filesystem which does not explicitly fsyncing consistent
> checkpoints to the disk, which would make battery backed RAID Systems
> pretty useless ... would it ?
>
>     So .. a battery backed RAID controller should default to "no disk
> write cache" should it ? Otherwise why should anyone want to use such
> expensive controllers ... it just does not make sense to have a
> battery backed cache on the controller, when things get inconsistent
> at a power outage ... It wouldn't have any purpuse ... I hope
> developers of battery backed RAID controllers are aware of that
> implication ...

Yes, imagine you have a RAID with 8 hard disks each having 32MB cache...=20
up to 256MB data lost, with a very big chance of having filesystem=20
metadata in cache, as that's written very often...
I'll be back on that once I have an official answer from Areca.

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart7276097.jXn00mXb1W
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmJv8cACgkQzhSR9xwSCbQB1gCglAMlVDsw8/hVRFZpfSKy4OY8
wCsAoK7Mefh8SVecgc8gFHE/dVXkDBwB
=UJPK
-----END PGP SIGNATURE-----

--nextPart7276097.jXn00mXb1W--

From eflorac@intellique.com Wed Feb  4 10:24:36 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14GOZ5d161454
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 10:24:36 -0600
X-ASG-Debug-ID: 1233764631-0b9e00bf0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from smtp4-g21.free.fr (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 1489CE7108
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 08:23:55 -0800 (PST)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id jYku4GMaEUmIf3qS for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 08:23:55 -0800 (PST)
Received: from smtp4-g21.free.fr (localhost [127.0.0.1])
	by smtp4-g21.free.fr (Postfix) with ESMTP id 18A834C822D;
	Wed,  4 Feb 2009 17:23:47 +0100 (CET)
Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72])
	by smtp4-g21.free.fr (Postfix) with ESMTP id CB3284C810D;
	Wed,  4 Feb 2009 17:23:44 +0100 (CET)
Date: Wed, 4 Feb 2009 17:23:50 +0100
From: Emmanuel Florac <eflorac@intellique.com>
To: KELEMEN Peter <Peter.Kelemen@cern.ch>
Cc: Dave Chinner <david@fromorbit.com>,
        Michael Monnerie
 <michael.monnerie@is.it-management.at>,
        xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090204172350.6049628c@harpe.intellique.com>
In-Reply-To: <20090204154153.GQ11617@kyra>
References: <498376CF.8020806@renderforce.de>
	<200902031140.08576@zmi.at>
	<20090203154907.GA21278@infradead.org>
	<200902040952.45440@zmi.at>
	<20090204122241.GL24173@disturbed>
	<20090204134538.24c2b4ac@harpe.intellique.com>
	<20090204140113.GP11617@kyra>
	<20090204161559.347679f7@harpe.intellique.com>
	<20090204154153.GQ11617@kyra>
Organization: Intellique
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4]
X-Barracuda-Start-Time: 1233764637
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17002
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Le Wed, 4 Feb 2009 16:41:53 +0100
KELEMEN Peter <Peter.Kelemen@cern.ch> =E9crivait:

> "Write cache includes the disk drive cache and controller cache."
>=20
> I assume this means you can only set the drive caches and the unit
> caches together.

Oh, you're right, I've missed that. I think we'll plan some testing
pulling out power cables under heavy write load pretty soon :)

--=20
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

From julian@hal-9k.de Wed Feb  4 10:29:14 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14GTDPp161607
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 10:29:14 -0600
X-ASG-Debug-ID: 1233764914-3af2029e0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from can12.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 40E071BB66AA
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 08:28:34 -0800 (PST)
Received: from can12.de (can12.de [213.203.199.141]) by cuda.sgi.com with ESMTP id QAog0JkS95OIqO34 for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 08:28:34 -0800 (PST)
Received: from [192.168.0.2] (p54AAE5F5.dip.t-dialin.net [84.170.229.245])
	by can12.de (can12.de) with ESMTP id 18F4E2B4FCF
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 17:28:05 +0100 (CET)
Message-Id: <4D4B8415-C82D-4A23-9A08-F06A67DC92BA@hal-9k.de>
From: Julian Einwag <julian@hal-9k.de>
To: xfs@oss.sgi.com
In-Reply-To: <4980A4BB.9050502@thebarn.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
X-ASG-Orig-Subj: Re: XFS trouble: task xfssyncd blocked for more than 120 seconds.
Subject: Re: XFS trouble: task xfssyncd blocked for more than 120 seconds.
Date: Wed, 4 Feb 2009 17:27:59 +0100
References: <A22069E0-B39A-41CF-9467-4524055B1970@hal-9k.de> <4980A4BB.9050502@thebarn.com>
X-Mailer: Apple Mail (2.930.3)
X-Barracuda-Connect: can12.de[213.203.199.141]
X-Barracuda-Start-Time: 1233764915
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0026 1.0000 -2.0042
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -2.00
X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17002
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hi!

Am 28.01.2009 um 19:32 schrieb Russell Cattelan:

> Could get a call trace of all process the next time this happens?
>
> srq-t
>
> That would help us to see what else is going on and what might be
> holding things up.


Just wanted to give a quick feedback here: We recently did an upgrade  
to Kernel 2.6.28.3 and things have been running smoothly so far, so  
we're hoping that the problem is gone.

Best regards,
Julian

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 13:37:47 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14JbkuU168318
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 13:37:47 -0600
X-ASG-Debug-ID: 1233776227-7bac02eb0000-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 DADEAE7DF9
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 11:37:07 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Kitd7tovMJLKgtxU for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 11:37:07 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUnYY-0006sH-M4
	for xfs@oss.sgi.com; Wed, 04 Feb 2009 19:37:06 +0000
Date: Wed, 4 Feb 2009 14:37:06 -0500
From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH 00/17] 2.6.30 queue
Subject: Re: [PATCH 00/17] 2.6.30 queue
Message-ID: <20090204193706.GA22805@infradead.org>
References: <20090126073136.384490000@bombadil.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090126073136.384490000@bombadil.infradead.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233776227
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Mon, Jan 26, 2009 at 02:31:36AM -0500, Christoph Hellwig wrote:
> Various misc small fixes and cleanups for 2.6.30.

All the patches that have been reviewed are not available to pull from

	git://git.kernel.org/pub/scm/fs/xfs/xfs.git

still waitinf for more reviews..

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 13:39:26 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14JdPjl168499
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 13:39:26 -0600
X-ASG-Debug-ID: 1233776327-6018034e0000-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 45D0718C7A77
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 11:38:47 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id vHWO44sWzHeryjD5 for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 11:38:47 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUnaA-0008Ib-9a; Wed, 04 Feb 2009 19:38:46 +0000
Date: Wed, 4 Feb 2009 14:38:46 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops
Subject: Re: reproducible xfs/vmap oops
Message-ID: <20090204193846.GA26436@infradead.org>
References: <20090201081224.GA22398@infradead.org> <20090204081547.GA21487@infradead.org> <20090204083037.GA17493@infradead.org> <200902042027.40762.nickpiggin@yahoo.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902042027.40762.nickpiggin@yahoo.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233776327
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 08:27:40PM +1100, Nick Piggin wrote:
> I've got a 32-bit machine running again. Is there any specific way to
> run xfsqa to reproduce the problem quickly?

Nothing quick unfortunately.  You need to set it up with a config
file pointing to at least two partitions and then run the auto group
using

	./check -g auto

I need a second run to trigger it most of the time, although sometimes
it gets hit in the first run.

From SRS0+63ac27d76a7b6820ad92+1991+infradead.org+hch@bombadil.srs.infradead.org Wed Feb  4 13:40:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14Je547168590
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 13:40:05 -0600
X-ASG-Debug-ID: 1233776366-7bab02c80000-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 0BE92E88A4
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 11:39:26 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id u9WIQ6AseYTuGopl for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 11:39:26 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LUnaJ-0008NK-Pp; Wed, 04 Feb 2009 19:38:55 +0000
Date: Wed, 4 Feb 2009 14:38:55 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: A rescue tool: xfs_irecover
Subject: Re: A rescue tool: xfs_irecover
Message-ID: <20090204193855.GB26436@infradead.org>
References: <alpine.LSU.2.00.0812292059020.15355@fbirervta.pbzchgretzou.qr> <20090204082816.GA9111@infradead.org> <alpine.LSU.2.00.0902041032510.27900@fbirervta.pbzchgretzou.qr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.0902041032510.27900@fbirervta.pbzchgretzou.qr>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233776367
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 10:33:28AM +0100, Jan Engelhardt wrote:
> On Wednesday 2009-02-04 09:28, Christoph Hellwig wrote:
> 
> >I looked into importing this into xfsprogs, and from a quick look
> >it could be simplified a lot by using code from libxfs or maybe even
> >by merging it into xfs_db and using the infrastructure there.
> >
> >But xfsprogs is licensed under GPLv2 and will stay that way as it shares
> >a lot of code with the kernel.  Are you willing to relicense the tool
> >under GPLv2 or later?
> 
> Yes; I updated the repository to reflect this (and add a manpage).

Thanks!

From markgw@sgi.com Wed Feb  4 14:05:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n14K55OQ170231
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 14:05:05 -0600
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by relay1.corp.sgi.com (Postfix) with SMTP id 1353A8F8039;
	Wed,  4 Feb 2009 12:04:20 -0800 (PST)
Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA21567; Thu, 5 Feb 2009 07:04:17 +1100
Message-ID: <4989F4C2.3030305@sgi.com>
Date: Thu, 05 Feb 2009 07:04:18 +1100
From: Mark Goodwin <markgw@sgi.com>
Reply-To: markgw@sgi.com
Organization: SGI Engineering
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: John Hesterberg <jh@sgi.com>
CC: Marizol Martinez <martinez@redhat.com>, Eric Sandeen <sandeen@redhat.com>,
        Ric Wheeler <rwheeler@redhat.com>,
        SGI Engineering Interfaces to Red Hat <redhat-interface@sgi.com>,
        Gary Hagensen <gwh@sgi.com>, George Beshers <gbeshers@sgi.com>,
        Tony Ernst <tee@sgi.com>, xfs-dev <xfs-dev@sgi.com>,
        xfs-oss <xfs@oss.sgi.com>
Subject: Re: IMPORTANT: XFS Documentation
References: <1231946704.3929.36.camel@localhost.localdomain> <20090120160346.GJ17616@sgi.com> <1232480744.23291.101.camel@localhost.localdomain> <20090128202715.GR16689@sgi.com> <1233175168.25011.155.camel@localhost.localdomain> <20090204183603.GA26714@sgi.com>
In-Reply-To: <20090204183603.GA26714@sgi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean



John Hesterberg wrote:
> FYI, this just happened internally:
>
>     ==========================
>     ADDITIONAL INFORMATION (TAKE)
>     From: mark goodwin <markgw@sgi.com>
>     Date: Feb 04 2009 02:34:02AM
>     ==========================
>
>     add Copyright using Creative Commons Attribute Share Alike license,
>     as approved by the OSRB for release to oss.sgi.com
>     ...
>     xfsdocs/xfs-website/training/docs/xfs_lab_01_build.doc - 1.3 - changed
>     ...
>
> Just wanted you to know this is still in process and not
> forgotten, since I hadn't seen any other communication about it
> since last week.
>

Sorry for the delay - the lawyers were pondering the GNU FDL Vrs the
Creative Commons license (and settled on the latter). So now that's 
resolved,
I've updated the copyrights in the doc sources and put them in a git tree:

	git://oss.sgi.com/xfs/cmds/xfsdocs.git

This repository is XFS group writable on oss.sgi.com. The directory 
structure
corresponds to (a subset of) the internal ptools tree below 
xfs-cmds/xfsdocs.
Since the files in this repository are binary, you'll need to co-ordinate
check-out/check-in to avoid merge failures (git handles binaries but 
can't merge
them). I think Eric and/or others inside Redhat will have the first go 
at it :)
I also regenerated the PDFs and committed them too since they're also 
present
in the internal ptools tree.

Thanks
-- Mark

From felixb@sgi.com Wed Feb  4 18:20:34 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n150KYpA180320
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 18:20:34 -0600
Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10])
	by relay3.corp.sgi.com (Postfix) with ESMTP id 87423AC012
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:19:52 -0800 (PST)
Received: from eagdhcp-232-197.americas.sgi.com (eagdhcp-232-197.americas.sgi.com [128.162.232.197])
	by estes.americas.sgi.com (Postfix) with ESMTP id B2DE17000103
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 18:19:51 -0600 (CST)
Message-Id: <86FA5963-93E1-4BB6-ACC1-70D1628CB926@sgi.com>
From: Felix Blyakher <felixb@sgi.com>
To: xfs@oss.sgi.com
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: xfsprogs 3.0.0 source tarball released
Date: Wed, 4 Feb 2009 18:19:51 -0600
X-Mailer: Apple Mail (2.926)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.0.0.tar.gz

This version contains important bug fixes and improvements
to xfsprogs 2.10.2:

xfsprogs-3.0.0 (4 February 2009)
         - Various smaller xfs_repair improvements.
         - Various gettext improvements, thanks to Jakub Bogusz.
         - Polish translation update, thanks to Jakub Bogusz.
         - Various xfs_quota fixes, thanks to Arkadiusz Miskiewicz.
         - Support parallel builds.
         - Detection of btrfs, gfs and gfs2 in libdisk.
         - Addition of the xfs_fsr and xfs_estimate tools previous found
           in the xfsdump package.
         - Resync libxfs to latest kernel implemenation.
         - Update all of xfsprogs to latest kernel interfaces.
         - Add sparse support to xfsprogs build.
         - Cleanup devel package for xfsctl, libhandle and libdisk only
           (remove libxfs interfaces).

From felixb@sgi.com Wed Feb  4 18:21:46 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n150LjGE180371
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 18:21:46 -0600
Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10])
	by relay3.corp.sgi.com (Postfix) with ESMTP id E4335AC002
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:21:06 -0800 (PST)
Received: from eagdhcp-232-197.americas.sgi.com (eagdhcp-232-197.americas.sgi.com [128.162.232.197])
	by estes.americas.sgi.com (Postfix) with ESMTP id F011B7000103
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 18:21:05 -0600 (CST)
Message-Id: <400220E1-CB3D-4CD3-B094-176629B246B5@sgi.com>
From: Felix Blyakher <felixb@sgi.com>
To: xfs@oss.sgi.com
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: xfsdump 3.0.0 source tarball released
Date: Wed, 4 Feb 2009 18:21:05 -0600
X-Mailer: Apple Mail (2.926)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsdump-3.0.0.tar.gz

This version contains important bug fixes to xfsdump 2.2.49:

xfsdump-3.0.0 (4 February 2009)
         - Bump major package version number to signify changed
           dependencies and moved binaries (xfs_fsr and estimate
           have moved into xfsprogs).
         - xfsdump should no longer make use of internal XFS
           headers and libraries, in particular no use of libxfs
           is permitted in this package anymore (such detailed
           on-disk format knowledge is the realm of xfsprogs).
         - Fix xfsdump/xfsrestore to work on systems with 64k
           page size.

From felixb@sgi.com Wed Feb  4 18:22:08 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n150M7vj180392
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 18:22:08 -0600
Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10])
	by relay2.corp.sgi.com (Postfix) with ESMTP id 8916D304062
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 16:21:26 -0800 (PST)
Received: from eagdhcp-232-197.americas.sgi.com (eagdhcp-232-197.americas.sgi.com [128.162.232.197])
	by estes.americas.sgi.com (Postfix) with ESMTP id B923C7000103
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 18:21:25 -0600 (CST)
Message-Id: <4E94A3D9-F39D-4FB2-93B8-B31E403446F3@sgi.com>
From: Felix Blyakher <felixb@sgi.com>
To: xfs@oss.sgi.com
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: dmapi 2.2.9 source tarball released
Date: Wed, 4 Feb 2009 18:21:25 -0600
X-Mailer: Apple Mail (2.926)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

ftp://oss.sgi.com/projects/xfs/cmd_tars/dmapi-2.2.9.tar.gz

This version contains changes since dmapi 2.2.8:

dmapi-2.2.9 (4 February 2009)
         - Various build system updates.


From mpatocka@redhat.com Wed Feb  4 22:32:22 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n154WL3X189630
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 22:32:21 -0600
X-ASG-Debug-ID: 1233808301-522c03200000-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 C37A91BB7E01
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 20:31:41 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id DjZsJ4BGVLfDKNB5 for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 20:31:41 -0800 (PST)
X-ASG-Whitelist: Barracuda Reputation
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 n154VPLp019327;
	Wed, 4 Feb 2009 23:31:26 -0500
Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34])
	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n154VRIl031915;
	Wed, 4 Feb 2009 23:31:27 -0500
Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1])
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id n154VQ71032159;
	Wed, 4 Feb 2009 23:31:26 -0500
Received: from localhost (mpatocka@localhost)
	by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) with ESMTP id n154VPbX032153;
	Wed, 4 Feb 2009 23:31:26 -0500
X-Authentication-Warning: hs20-bc2-1.build.redhat.com: mpatocka owned process doing -bs
Date: Wed, 4 Feb 2009 23:31:25 -0500 (EST)
From: Mikulas Patocka <mpatocka@redhat.com>
X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com
To: Dave Chinner <david@fromorbit.com>
cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
In-Reply-To: <20090204120852.GK24173@disturbed>
Message-ID: <Pine.LNX.4.64.0902042310240.27204@hs20-bc2-1.build.redhat.com>
References: <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org>
 <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com>
 <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com>
 <20090131235725.GA24173@disturbed> <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com>
 <20090203032740.GG24173@disturbed> <Pine.LNX.4.64.0902031459350.28433@hs20-bc2-1.build.redhat.com>
 <20090204120852.GK24173@disturbed>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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: 1233808302
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

> > ... and if you turn it into trylock, what are you going to do with the 
> > inode that is just being written to? You should definitely flush it, but 
> > trylock will skip it because it's already locked.
> 
> We've already flushed it directly. You disabled that code fearing
> deadlocks. I've made it synchronous (i.e. not handed off to
> xfssyncd) because the flush path requires us to hold the lock we are
> already holding....

This is not "fearing deadlocks". This was getting a real deadlock:

Jan 29 16:51:55 slunicko kernel: SysRq : Show Blocked State
Jan 29 16:51:55 slunicko kernel:   task                        PC stack   
pid father
Jan 29 16:51:55 slunicko kernel: xfssyncd      D 00000000004848e0     0 
13321
   2
Jan 29 16:51:55 slunicko kernel: Call Trace:
Jan 29 16:51:55 slunicko kernel:  [000000000060475c] io_schedule+0x20/0x44
Jan 29 16:51:55 slunicko kernel:  [00000000004848e0] sync_page+0x64/0x74
Jan 29 16:51:55 slunicko kernel:  [000000000060494c] 
__wait_on_bit_lock+0x5c/0x9c
Jan 29 16:51:55 slunicko kernel:  [0000000000484848] __lock_page+0x58/0x68
Jan 29 16:51:55 slunicko kernel:  [000000000048b3fc] 
write_cache_pages+0x170/0x38c
Jan 29 16:51:55 slunicko kernel:  [000000000048b64c] 
generic_writepages+0x34/0x48
Jan 29 16:51:55 slunicko kernel:  [00000000101d0d48] 
xfs_vm_writepages+0x3c/0x50 [xfs]
Jan 29 16:51:55 slunicko kernel:  [000000000048b6a4] 
do_writepages+0x44/0x7c
Jan 29 16:51:55 slunicko kernel:  [00000000004850f4] 
__filemap_fdatawrite_range+0x58/0x6c
Jan 29 16:51:55 slunicko kernel:  [0000000000485cc8] 
filemap_flush+0x20/0x34
Jan 29 16:51:55 slunicko kernel:  [00000000101dbc64] 
xfs_flush_inode_work+0x10/0x28 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000101dbf2c] xfssyncd+0x110/0x174 
[xfs]
Jan 29 16:51:55 slunicko kernel:  [000000000046556c] kthread+0x54/0x88
Jan 29 16:51:55 slunicko kernel:  [000000000042b2a0] 
kernel_thread+0x3c/0x54
Jan 29 16:51:55 slunicko kernel:  [00000000004653b8] kthreadd+0xac/0x160
Jan 29 16:51:55 slunicko kernel: pdflush       D 00000000004848e0     0 
15226
   2
Jan 29 16:51:55 slunicko kernel: Call Trace:
Jan 29 16:51:55 slunicko kernel:  [000000000060475c] io_schedule+0x20/0x44
Jan 29 16:51:55 slunicko kernel:  [00000000004848e0] sync_page+0x64/0x74
Jan 29 16:51:55 slunicko kernel:  [000000000060494c] 
__wait_on_bit_lock+0x5c/0x9c
Jan 29 16:51:55 slunicko kernel:  [0000000000484848] __lock_page+0x58/0x68
Jan 29 16:51:55 slunicko kernel:  [000000000048b3fc] 
write_cache_pages+0x170/0x38c
Jan 29 16:51:55 slunicko kernel:  [000000000048b64c] 
generic_writepages+0x34/0x48
Jan 29 16:51:55 slunicko kernel:  [00000000101d0d48] 
xfs_vm_writepages+0x3c/0x50 [xfs]
Jan 29 16:51:55 slunicko kernel:  [000000000048b6a4] 
do_writepages+0x44/0x7c
Jan 29 16:51:55 slunicko kernel:  [00000000004ca350] 
__writeback_single_inode+0x168/0x2e4
Jan 29 16:51:55 slunicko kernel:  [00000000004ca90c] 
generic_sync_sb_inodes+0x204/0x3a0
Jan 29 16:51:55 slunicko kernel:  [00000000004caabc] 
sync_sb_inodes+0x14/0x24
Jan 29 16:51:55 slunicko kernel:  [00000000004cacd8] 
writeback_inodes+0x8c/0x100
Jan 29 16:51:55 slunicko kernel:  [000000000048c274] wb_kupdate+0xc4/0x15c
Jan 29 16:51:55 slunicko kernel:  [000000000048c8dc] pdflush+0xfc/0x1cc
Jan 29 16:51:55 slunicko kernel:  [000000000046556c] kthread+0x54/0x88
Jan 29 16:51:55 slunicko kernel:  [000000000042b2a0] 
kernel_thread+0x3c/0x54
Jan 29 16:51:55 slunicko kernel: dd            D 00000000006045c4     0 
16610  16597
Jan 29 16:51:55 slunicko kernel: Call Trace:
Jan 29 16:51:55 slunicko kernel:  [00000000006047d8] 
schedule_timeout+0x24/0xb8
Jan 29 16:51:55 slunicko kernel:  [00000000006045c4] 
wait_for_common+0xe4/0x14c
Jan 29 16:51:55 slunicko kernel:  [0000000000604700] 
wait_for_completion+0x1c/0x2c
Jan 29 16:51:55 slunicko kernel:  [00000000101dc7d8] 
xfs_flush_inode+0xb0/0xc0 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000101b9b50] 
xfs_flush_space+0x54/0xd0 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000101b9ec0] 
xfs_iomap_write_delay+0x1bc/0x228 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000101ba4b8] xfs_iomap+0x1c4/0x2e0 
[xfs]Jan 29 16:51:55 slunicko kernel:  [00000000101d0f04] 
__xfs_get_blocks+0x74/0x240 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000101d112c] 
xfs_get_blocks+0x24/0x38 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000004d05f0] 
__block_prepare_write+0x184/0x41c
Jan 29 16:51:55 slunicko kernel:  [00000000004d095c] 
block_write_begin+0x84/0xe8
Jan 29 16:51:55 slunicko kernel:  [00000000101d047c] 
xfs_vm_write_begin+0x3c/0x50 [xfs]
Jan 29 16:51:55 slunicko kernel:  [0000000000485258] 
generic_file_buffered_write+0xe8/0x28c
Jan 29 16:51:55 slunicko kernel:  [00000000101d8ec4] xfs_write+0x40c/0x604 
[xfs]Jan 29 16:51:55 slunicko kernel:  [00000000101d4d3c] 
xfs_file_aio_write+0x74/0x84 [xfs]
Jan 29 16:51:55 slunicko kernel:  [00000000004ae70c] 
do_sync_write+0x8c/0xdc

This one was obtained on a machine with 4k filesystem blocks, 8k pages and 
dd bs=1 on a nearly full filesystem. Apparently it attempts to lock the 
page that is already locked when writing to it.

The deadlock happened when I modified it to use completions (instead of 
500ms wait) with the patch I already posted.

> > > > There seems to be more bugs with forgetting to flush delayed allocation 
> > > > --- you should flush delayed allocation after *every* failed allocate 
> > > > attempt, but the code flushes it only after failed delayed allocate 
> > > > attempt --- i.e. nondelayed allocators, such as xfs_iomap_write_direct 
> > > > (and maybe other places) will still return -ENOSPC without attempting to 
> > > > flush other inodes with delayed allocation.
> .....
> > > For metadata allocations (all over the place), we take a reservation
> > > first
> > 
> > And what if the reservation fails? Do you flush in this case?
> 
> Well, if you read the rest of the paragraph you'd have the answer
> to that question. I'll leave it quoted because it is relevant:
> 
> > > and so we could trigger a flush in certain circumstances if
> > > the reservation fails (to avoid recursion and transaction subsystem
> > > deadlocks). However, if you are not getting spurious enospc on
> > > creating inodes (as opposed to writing to them) then I see no
> > > immediate need for flushes there, either....
> 
> It is relevant because the test case Eric provided fails repeatedly
> in xfs_create() on a reservation rather than on a data write, and
> without a flush there no further data writes will occur to flush out
> the blocks.
> 
> So a flush there is needed, too.
> 
> > > > @@ -415,6 +419,7 @@ xfs_syncd_queue_work(
> > > >   * has failed with ENOSPC and we are in the process of scratching our
> > > >   * heads, looking about for more room...
> > > >   */
> > > > +#if 0
> > > >  STATIC void
> > > >  xfs_flush_inode_work(
> > > >  	struct xfs_mount *mp,
> > > > @@ -424,16 +429,20 @@ xfs_flush_inode_work(
> > > >  	filemap_flush(inode->i_mapping);
> > > >  	iput(inode);
> > > >  }
> > > > +#endif
> > > >  
> > > >  void
> > > >  xfs_flush_inode(
> > > >  	xfs_inode_t	*ip)
> > > >  {
> > > > +#if 0
> > > >  	struct inode	*inode = VFS_I(ip);
> > > > +	DECLARE_COMPLETION_ONSTACK(completion);
> > > >  
> > > >  	igrab(inode);
> > > > -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
> > > > -	delay(msecs_to_jiffies(500));
> > > > +	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work, &completion);
> > > > +	wait_for_completion(&completion);
> > > > +#endif
> > > 
> > > Why did you turn off the initial inode flush?
> > 
> > Because it recurses into Linux VFS layer and deadlocks.
> 
> Not at all. It calls into the writeback code (not the VFS)
> which does not take any locks except page locks before it
> calls back into ->writepages....

See the backtrace above.

> I've attached the WIP patch I have right now (based on yours) that
> allows the test case to pass. It will need a bit of cleanup before
> it is ready for prime-time, but is passes xfsqa here including the
> ENOSPC stress tests.  Can you see if it fixes your test case and
> whether it deadlocks?

I can try it, but that filemap_fdatawrite is still wrong. I tried to call 
filemap_fdatawrite myself with my patch and got the deadlock.

You just can't do it that you hold a page lock and call an generic kernel 
function that takes other page locks. Even if you hacked it somehow to be 
working now, over the long term it is unmaintainable.

Mikulas

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> 
> Use xfs_sync_inodes and not sync_blockdev. XFS keeps it's dirty
> metadata in different address spaces to the block device, so
> sync_blockdev does nothing.
> 
> Change that 500ms delay to a wait for completion, so that the
> behavior is not dependent on magic timeout values.
> 
> Add a trylock option to xfs_sync_inodes() so that it won't
> deadlock if we are already holding an inode lock.
> 
> Add xfs_flush_device() to inode allocation failure in the create
> path as that is the other place that typically falls over due to
> outstanding delayed allocation extents.
> 
> Based on work from Mikulas Patocka <mpatocka@redhat.com>.
> 
> ---
>  fs/xfs/linux-2.6/xfs_fs_subr.c |   14 ++++----
>  fs/xfs/linux-2.6/xfs_sync.c    |   66 +++++++++++++++++++--------------------
>  fs/xfs/linux-2.6/xfs_sync.h    |    6 ++-
>  fs/xfs/xfs_mount.h             |    2 +-
>  fs/xfs/xfs_vnodeops.c          |    6 ++++
>  5 files changed, 50 insertions(+), 44 deletions(-)
> 
> diff --git a/fs/xfs/linux-2.6/xfs_fs_subr.c b/fs/xfs/linux-2.6/xfs_fs_subr.c
> index 5aeb777..08be36d 100644
> --- a/fs/xfs/linux-2.6/xfs_fs_subr.c
> +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c
> @@ -74,14 +74,14 @@ xfs_flush_pages(
>  
>  	if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
>  		xfs_iflags_clear(ip, XFS_ITRUNCATED);
> -		ret = filemap_fdatawrite(mapping);
> -		if (flags & XFS_B_ASYNC)
> -			return -ret;
> -		ret2 = filemap_fdatawait(mapping);
> -		if (!ret)
> -			ret = ret2;
> +		ret = -filemap_fdatawrite(mapping);
>  	}
> -	return -ret;
> +	if (flags & XFS_B_ASYNC)
> +		return ret;
> +	ret2 = xfs_wait_on_pages(ip, first, last);
> +	if (!ret)
> +		ret = ret2;
> +	return ret;
>  }
>  
>  int
> diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c
> index a608e72..fddb9de 100644
> --- a/fs/xfs/linux-2.6/xfs_sync.c
> +++ b/fs/xfs/linux-2.6/xfs_sync.c
> @@ -62,12 +62,6 @@ xfs_sync_inodes_ag(
>  	uint32_t	first_index = 0;
>  	int		error = 0;
>  	int		last_error = 0;
> -	int		fflag = XFS_B_ASYNC;
> -
> -	if (flags & SYNC_DELWRI)
> -		fflag = XFS_B_DELWRI;
> -	if (flags & SYNC_WAIT)
> -		fflag = 0;		/* synchronous overrides all */
>  
>  	do {
>  		struct inode	*inode;
> @@ -128,12 +122,23 @@ xfs_sync_inodes_ag(
>  		 * If we have to flush data or wait for I/O completion
>  		 * we need to hold the iolock.
>  		 */
> -		if ((flags & SYNC_DELWRI) && VN_DIRTY(inode)) {
> -			xfs_ilock(ip, XFS_IOLOCK_SHARED);
> -			lock_flags |= XFS_IOLOCK_SHARED;
> -			error = xfs_flush_pages(ip, 0, -1, fflag, FI_NONE);
> -			if (flags & SYNC_IOWAIT)
> +		if (flags & SYNC_DELWRI) {
> +			if (VN_DIRTY(inode)) {
> +				if (flags & SYNC_TRYLOCK) {
> +					if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED))
> +						lock_flags |= XFS_IOLOCK_SHARED;
> +				} else {
> +					xfs_ilock(ip, XFS_IOLOCK_SHARED);
> +					lock_flags |= XFS_IOLOCK_SHARED;
> +				}
> +				if (lock_flags & XFS_IOLOCK_SHARED) {
> +					error = xfs_flush_pages(ip, 0, -1,
> +							XFS_B_ASYNC, FI_NONE);
> +				}
> +			}
> +			if (VN_CACHED(inode) && (flags & SYNC_IOWAIT)) {
>  				xfs_ioend_wait(ip);
> +			}
>  		}
>  		xfs_ilock(ip, XFS_ILOCK_SHARED);
>  
> @@ -388,7 +393,7 @@ xfs_quiesce_attr(
>  }
>  
>  /*
> - * Enqueue a work item to be picked up by the vfs xfssyncd thread.
> + * Enqueue a work item to be picked up by the xfssyncd thread.
>   * Doing this has two advantages:
>   * - It saves on stack space, which is tight in certain situations
>   * - It can be used (with care) as a mechanism to avoid deadlocks.
> @@ -398,15 +403,17 @@ STATIC void
>  xfs_syncd_queue_work(
>  	struct xfs_mount *mp,
>  	void		*data,
> -	void		(*syncer)(struct xfs_mount *, void *))
> +	void		(*syncer)(struct xfs_mount *, void *),
> +	struct completion *completion)
>  {
> -	struct bhv_vfs_sync_work *work;
> +	struct xfs_sync_work *work;
>  
> -	work = kmem_alloc(sizeof(struct bhv_vfs_sync_work), KM_SLEEP);
> +	work = kmem_zalloc(sizeof(struct xfs_sync_work), KM_SLEEP);
>  	INIT_LIST_HEAD(&work->w_list);
>  	work->w_syncer = syncer;
>  	work->w_data = data;
>  	work->w_mount = mp;
> +	work->w_completion = completion;
>  	spin_lock(&mp->m_sync_lock);
>  	list_add_tail(&work->w_list, &mp->m_sync_list);
>  	spin_unlock(&mp->m_sync_lock);
> @@ -419,25 +426,11 @@ xfs_syncd_queue_work(
>   * has failed with ENOSPC and we are in the process of scratching our
>   * heads, looking about for more room...
>   */
> -STATIC void
> -xfs_flush_inode_work(
> -	struct xfs_mount *mp,
> -	void		*arg)
> -{
> -	struct inode	*inode = arg;
> -	filemap_flush(inode->i_mapping);
> -	iput(inode);
> -}
> -
>  void
>  xfs_flush_inode(
>  	xfs_inode_t	*ip)
>  {
> -	struct inode	*inode = VFS_I(ip);
> -
> -	igrab(inode);
> -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_inode_work);
> -	delay(msecs_to_jiffies(500));
> +	xfs_flush_pages(ip, 0, -1, 0, FI_NONE);
>  }
>  
>  /*
> @@ -450,7 +443,8 @@ xfs_flush_device_work(
>  	void		*arg)
>  {
>  	struct inode	*inode = arg;
> -	sync_blockdev(mp->m_super->s_bdev);
> +	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK);
> +	xfs_sync_inodes(mp, SYNC_DELWRI | SYNC_TRYLOCK | SYNC_IOWAIT);
>  	iput(inode);
>  }
>  
> @@ -459,10 +453,11 @@ xfs_flush_device(
>  	xfs_inode_t	*ip)
>  {
>  	struct inode	*inode = VFS_I(ip);
> +	DECLARE_COMPLETION_ONSTACK(completion);
>  
>  	igrab(inode);
> -	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work);
> -	delay(msecs_to_jiffies(500));
> +	xfs_syncd_queue_work(ip->i_mount, inode, xfs_flush_device_work, &completion);
> +	wait_for_completion(&completion);
>  	xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC);
>  }
>  
> @@ -497,7 +492,7 @@ xfssyncd(
>  {
>  	struct xfs_mount	*mp = arg;
>  	long			timeleft;
> -	bhv_vfs_sync_work_t	*work, *n;
> +	xfs_sync_work_t		*work, *n;
>  	LIST_HEAD		(tmp);
>  
>  	set_freezable();
> @@ -530,6 +525,8 @@ xfssyncd(
>  		list_for_each_entry_safe(work, n, &tmp, w_list) {
>  			(*work->w_syncer)(mp, work->w_data);
>  			list_del(&work->w_list);
> +			if (work->w_completion)
> +				complete(work->w_completion);
>  			if (work == &mp->m_sync_work)
>  				continue;
>  			kmem_free(work);
> @@ -545,6 +542,7 @@ xfs_syncd_init(
>  {
>  	mp->m_sync_work.w_syncer = xfs_sync_worker;
>  	mp->m_sync_work.w_mount = mp;
> +	mp->m_sync_work.w_completion = NULL;
>  	mp->m_sync_task = kthread_run(xfssyncd, mp, "xfssyncd");
>  	if (IS_ERR(mp->m_sync_task))
>  		return -PTR_ERR(mp->m_sync_task);
> diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h
> index 5f6de1e..de87a7f 100644
> --- a/fs/xfs/linux-2.6/xfs_sync.h
> +++ b/fs/xfs/linux-2.6/xfs_sync.h
> @@ -20,18 +20,20 @@
>  
>  struct xfs_mount;
>  
> -typedef struct bhv_vfs_sync_work {
> +typedef struct xfs_sync_work {
>  	struct list_head	w_list;
>  	struct xfs_mount	*w_mount;
>  	void			*w_data;	/* syncer routine argument */
>  	void			(*w_syncer)(struct xfs_mount *, void *);
> -} bhv_vfs_sync_work_t;
> +	struct completion	*w_completion;
> +} xfs_sync_work_t;
>  
>  #define SYNC_ATTR		0x0001	/* sync attributes */
>  #define SYNC_DELWRI		0x0002	/* look at delayed writes */
>  #define SYNC_WAIT		0x0004	/* wait for i/o to complete */
>  #define SYNC_BDFLUSH		0x0008	/* BDFLUSH is calling -- don't block */
>  #define SYNC_IOWAIT		0x0010  /* wait for all I/O to complete */
> +#define SYNC_TRYLOCK		0x0020  /* only try to lock inodes */
>  
>  int xfs_syncd_init(struct xfs_mount *mp);
>  void xfs_syncd_stop(struct xfs_mount *mp);
> diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
> index f5e9937..775a2ac 100644
> --- a/fs/xfs/xfs_mount.h
> +++ b/fs/xfs/xfs_mount.h
> @@ -322,7 +322,7 @@ typedef struct xfs_mount {
>  #endif
>  	struct xfs_mru_cache	*m_filestream;  /* per-mount filestream data */
>  	struct task_struct	*m_sync_task;	/* generalised sync thread */
> -	bhv_vfs_sync_work_t	m_sync_work;	/* work item for VFS_SYNC */
> +	xfs_sync_work_t		m_sync_work;	/* work item for VFS_SYNC */
>  	struct list_head	m_sync_list;	/* sync thread work item list */
>  	spinlock_t		m_sync_lock;	/* work item list lock */
>  	int			m_sync_seq;	/* sync thread generation no. */
> diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
> index 0e55c5d..e1099e7 100644
> --- a/fs/xfs/xfs_vnodeops.c
> +++ b/fs/xfs/xfs_vnodeops.c
> @@ -1449,6 +1449,12 @@ xfs_create(
>  	error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0,
>  			XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);
>  	if (error == ENOSPC) {
> +		/* flush delalloc blocks and retry */
> +		xfs_flush_device(dp);
> +		error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0,
> +			XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);
> +	}
> +	if (error == ENOSPC) {
>  		resblks = 0;
>  		error = xfs_trans_reserve(tp, 0, XFS_CREATE_LOG_RES(mp), 0,
>  				XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT);
> 

From ralf@theco.de Wed Feb  4 23:39:30 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_82,
	J_CHICKENPOX_83 autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n155dUdr193171
	for <xfs@oss.sgi.com>; Wed, 4 Feb 2009 23:39:30 -0600
X-ASG-Debug-ID: 1233812329-45ba035a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from theco.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 6ABBF18CA437
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 21:38:49 -0800 (PST)
Received: from theco.de (scout.theco.de.mind.de [212.42.230.55]) by cuda.sgi.com with ESMTP id Q6tXg0dFPjQsXaPz for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 21:38:49 -0800 (PST)
Received: (qmail 30597 invoked from network); 5 Feb 2009 05:38:47 -0000
Received: from pd956aa94.dip0.t-ipconnect.de (HELO theco.de) (217.86.170.148)
  by scout.theco.de.mind.de with DES-CBC3-SHA encrypted SMTP cert admin@theco.de; 5 Feb 2009 05:38:47 -0000
Received: (qmail 6336 invoked from network); 5 Feb 2009 05:38:47 -0000
Received: from photon.intern.theco.de (HELO theco.de) (192.168.194.153)
  by neutron.intern.theco.de with SMTP; 5 Feb 2009 05:38:47 -0000
Received: by theco.de (sSMTP sendmail emulation); Thu, 5 Feb 2009 06:38:47 +0100
Date: Thu, 5 Feb 2009 06:38:47 +0100
From: Ralf Liebenow <ralf@theco.de>
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: XFS Kernel 2.6.27.7 oopses
Subject: Re: XFS Kernel 2.6.27.7 oopses
Message-ID: <20090205053847.GA24841@theco.de>
Reply-To: ralf@theco.de
References: <20090130222359.GB32142@theco.de> <20090201003744.GB24173@disturbed>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20090201003744.GB24173@disturbed>
Organization: theCo.de AG
User-Agent: Mutt/1.5.9i
X-Barracuda-Connect: scout.theco.de.mind.de[212.42.230.55]
X-Barracuda-Start-Time: 1233812330
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0207
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.52
X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17047
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.50 BSF_RULE7568M          Custom Rule 7568M
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hello !

Finally I found the time to compile and test the latest stable 2.6.28.3 kernel
but I can reproduce it:

Feb  5 03:00:19 up kernel: general protection fault: 0000 [#1] SMP
Feb  5 03:00:19 up kernel: last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
Feb  5 03:00:19 up kernel: CPU 2
Feb  5 03:00:19 up kernel: Modules linked in: vmnet parport_pc vsock vmci vmmon nfsd lockd nfs_acl auth_rpcgss snd_pcm_oss sunrpc snd_mi
xer_oss exportfs snd_seq snd_seq_device binfmt_misc microcode fuse loop dm_mod snd_hda_intel osst st snd_pcm snd_timer snd_page_alloc pp
dev shpchp rtc_cmos i2c_i801 rtc_core button snd_hwdep r8169 rtc_lib pcspkr ohci1394 intel_agp mii i2c_core parport sky2 pci_hotplug iTC
O_wdt ieee1394 iTCO_vendor_support snd sg soundcore raid456 async_xor async_memcpy async_tx xor raid0 sd_mod crc_t10dif ehci_hcd uhci_hc
d usbcore edd raid1 xfs fan ahci libata aic79xx scsi_transport_spi scsi_mod thermal processor thermal_sys hwmon [last unloaded: vmnet]
Feb  5 03:00:19 up kernel: Pid: 1462, comm: xfssyncd Not tainted 2.6.28.3-9-default #1
Feb  5 03:00:19 up kernel: RIP: 0010:[<ffffffff802327a1>]  [<ffffffff802327a1>] __wake_up_common+0x29/0x76
Feb  5 03:00:19 up kernel: RSP: 0018:ffff88012e56fcf0  EFLAGS: 00010086
Feb  5 03:00:19 up kernel: RAX: 7fff8800255b8a70 RBX: ffff8800255b8a60 RCX: 0000000000000000
Feb  5 03:00:19 up kernel: RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8800255b8a68
Feb  5 03:00:19 up kernel: RBP: ffff88012e56fd20 R08: 7fff8800255b8a58 R09: ffff880129d02e18
Feb  5 03:00:19 up kernel: R10: 0000000000000002 R11: 0000000300000000 R12: 0000000000000001
Feb  5 03:00:19 up kernel: R13: 0000000000000286 R14: ffff8800255b8a70 R15: 0000000000000000
Feb  5 03:00:19 up kernel: FS:  0000000000000000(0000) GS:ffff88012fb2e8c0(0000) knlGS:0000000000000000
Feb  5 03:00:19 up kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Feb  5 03:00:19 up kernel: CR2: 00007f075ee9ab00 CR3: 0000000000201000 CR4: 00000000000006e0
Feb  5 03:00:19 up kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb  5 03:00:19 up kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Feb  5 03:00:19 up kernel: Process xfssyncd (pid: 1462, threadinfo ffff88012e56e000, task ffff88012c842640)
Feb  5 03:00:19 up kernel: Stack:
Feb  5 03:00:19 up kernel:  0000000300000000 ffff8800255b8a60 ffff8800255b8a68 0000000000000286
Feb  5 03:00:19 up kernel:  ffff88012b922000 ffff88012a1eb000 ffff88012e56fd50 ffffffff8023410a
Feb  5 03:00:19 up kernel:  ffff8800255b87c0 0000000000000000 ffff8800255b8980 ffff88004dc64140
Feb  5 03:00:19 up kernel: Call Trace:
Feb  5 03:00:20 up kernel:  [<ffffffff8023410a>] complete+0x38/0x4c
Feb  5 03:00:20 up kernel:  [<ffffffffa01a2424>] xfs_iflush+0x7a/0x2b2 [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffff802241cc>] ? default_spin_lock_flags+0x17/0x1b
Feb  5 03:00:20 up kernel:  [<ffffffffa01b7cf9>] xfs_finish_reclaim+0x136/0x175 [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01b7dd0>] xfs_finish_reclaim_all+0x98/0xd4 [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01b694c>] xfs_syncsub+0x55/0x22f [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01b6b68>] xfs_sync+0x42/0x47 [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01c55fd>] xfs_sync_worker+0x1f/0x41 [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01c558f>] xfssyncd+0x15d/0x1ac [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffffa01c5432>] ? xfssyncd+0x0/0x1ac [xfs]
Feb  5 03:00:20 up kernel:  [<ffffffff802563e5>] kthread+0x49/0x76
Feb  5 03:00:20 up kernel:  [<ffffffff8020d659>] child_rip+0xa/0x11
Feb  5 03:00:20 up kernel:  [<ffffffff8025639c>] ? kthread+0x0/0x76
Feb  5 03:00:20 up kernel:  [<ffffffff8020d64f>] ? child_rip+0x0/0x11
Feb  5 03:00:20 up kernel: Code: c9 c3 55 48 89 e5 41 57 4d 89 c7 41 56 4c 8d 77 08 41 55 41 54 41 89 d4 53 48 83 ec 08 89 75 d4 89 4d d
0 48 8b 47 08 4c 8d 40 e8 <49> 8b 40 18 48 8d 58 e8 eb 2d 45 8b 28 4c 89 f9 8b 55 d0 8b 75
Feb  5 03:00:20 up kernel: RIP  [<ffffffff802327a1>] __wake_up_common+0x29/0x76
Feb  5 03:00:20 up kernel:  RSP <ffff88012e56fcf0>
Feb  5 03:00:20 up kernel: ---[ end trace a0fbe14899a3ce1c ]---

So its not SuSEs fault, and its the latest stable kernel from kernel.org ....

Hmmm ... can I do something to help you find the problem ? I can
reproduce it by creating some millon of hardlinks to files and then remove some
million hardlinks with one "rm -rf"

The Filesystem is 1 TB big.

Settings:
meta-data=/dev/sdd1              isize=256    agcount=32, agsize=7630937 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=244189984, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=65536  blocks=0, rtextents=0

[I originally had log version=1 but with the same problem. The problem occurs
 with barriers=on and with barriers=off ]

I have not tried to run the system with one CPU core yet, that maybe a thing
I can check tomorrow ...

   Thanks for your help
      Ralf


> On Fri, Jan 30, 2009 at 11:23:59PM +0100, Ralf Liebenow wrote:
> > Hello !
> > 
> > I heavily use XFS for an incremental backup server (by using rsync --link-dest option
> > to create hardlinks to unchanged files), and therefore have about 10 million files
> > on my TB Harddisk. To remove old versions nightly an "rm -rf" will remove a million
> > hardlinks/files every night.
> > 
> > After a while I had regular oopses and so I updated the system to make sure its
> > on a current version.
> > 
> > It is now a SuSE 11.1 64Bit with SuSE's Kernel 2.6.27.7-9-default
> 
> What kernel did you originally see this problem on?
> 
> > <4>Call Trace:
> > <4> [<ffffffff8023219a>] complete+0x38/0x4b
> > <4> [<ffffffffa00f5316>] xfs_iflush+0x73/0x2ab [xfs]
> > <4> [<ffffffffa010a7a2>] xfs_finish_reclaim+0x12a/0x168 [xfs]
> > <4> [<ffffffffa010a871>] xfs_finish_reclaim_all+0x91/0xcb [xfs]
> > <4> [<ffffffffa010925c>] xfs_syncsub+0x50/0x22b [xfs]
> > <4> [<ffffffffa0118a3a>] xfs_sync_worker+0x17/0x36 [xfs]
> > <4> [<ffffffffa01189d4>] xfssyncd+0x15d/0x1ac [xfs]
> > <4> [<ffffffff8025434d>] kthread+0x47/0x73
> > <4> [<ffffffff8020d7b9>] child_rip+0xa/0x11
> 
> That may be a use after free. I know lachlan fixed a few in this
> area, but I'm not sure what release those fixe?? ended up in....
> 
> > What do you recommend ? Has this bug already been addressed within the
> > hundrets of fixes I've seen on the mailing list ? Shall I try a stock 2.6.28
> > kernel ?
> 
> Try the lastest 2.6.28.x stable kernel (*not* the straight 2.6.28 release
> as there's a directory traversal bug that is fixed in 2.6.28.1) and
> see if the problem persists.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
theCode AG 
HRB 78053, Amtsgericht Charlottenbg
USt-IdNr.: DE204114808
Vorstand: Ralf Liebenow, Michael Oesterreich, Peter Witzel
Aufsichtsratsvorsitzender: Wolf von Jaduczynski
Oranienstr. 10-11, 10997 Berlin [×]
fon +49 30 617 897-0  fax -10
ralf@theCo.de http://www.theCo.de

From david@fromorbit.com Thu Feb  5 01:44:38 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n157ibpn202147
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 01:44:37 -0600
X-ASG-Debug-ID: 1233819837-6f8c01a30000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id A7024EC4D0
	for <xfs@oss.sgi.com>; Wed,  4 Feb 2009 23:43:57 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id QDT6duwLETYEphrB for <xfs@oss.sgi.com>; Wed, 04 Feb 2009 23:43:57 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAL8kikl5LClx/2dsb2JhbADQN4QWBg
X-IronPort-AV: E=Sophos;i="4.37,384,1231075800"; 
   d="scan'208";a="283345662"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 05 Feb 2009 18:13:54 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUytt-0006X0-Gq; Thu, 05 Feb 2009 18:43:53 +1100
Date: Thu, 5 Feb 2009 18:43:53 +1100
From: Dave Chinner <david@fromorbit.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
X-ASG-Orig-Subj: Re: spurious -ENOSPC on XFS
Subject: Re: spurious -ENOSPC on XFS
Message-ID: <20090205074353.GN24173@disturbed>
Mail-Followup-To: Mikulas Patocka <mpatocka@redhat.com>,
	Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com,
	linux-kernel@vger.kernel.org
References: <20090122224347.GA18751@infradead.org> <Pine.LNX.4.64.0901231509010.5179@hs20-bc2-1.build.redhat.com> <20090124071249.GF32390@disturbed> <Pine.LNX.4.64.0901291136050.19368@hs20-bc2-1.build.redhat.com> <20090131235725.GA24173@disturbed> <Pine.LNX.4.64.0902021214310.15622@hs20-bc2-1.build.redhat.com> <20090203032740.GG24173@disturbed> <Pine.LNX.4.64.0902031459350.28433@hs20-bc2-1.build.redhat.com> <20090204120852.GK24173@disturbed> <Pine.LNX.4.64.0902042310240.27204@hs20-bc2-1.build.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0902042310240.27204@hs20-bc2-1.build.redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233819838
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0272 1.0000 -1.8450
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.84
X-Barracuda-Spam-Status: No, SCORE=-1.84 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17055
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 11:31:25PM -0500, Mikulas Patocka wrote:
> > > ... and if you turn it into trylock, what are you going to do with the 
> > > inode that is just being written to? You should definitely flush it, but 
> > > trylock will skip it because it's already locked.
> > 
> > We've already flushed it directly. You disabled that code fearing
> > deadlocks. I've made it synchronous (i.e. not handed off to
> > xfssyncd) because the flush path requires us to hold the lock we are
> > already holding....
> 
> This is not "fearing deadlocks". This was getting a real deadlock:

<sigh>

Thank you for *finally* telling me exactly what the deadlock is that
you've been handwaving about for the last week. It's not a VFS
deadlock, nor is it an inode lock deadlock - its a page lock deadlock.

Perhaps next time you will post the stack trace instead of vaguely
describing a deadlock so you don't waste several hours of another
developer's time looking for deadlocks in all the wrong places?

> This one was obtained on a machine with 4k filesystem blocks, 8k pages and 
> dd bs=1 on a nearly full filesystem.

That's helpful, too. I can write a test case to exercise that.

So, now I understand why you were suggesting going all the way back up
to the top of the IO path and flushing from there - so we don't hold
a page lock.

Perhaps we should just cull the direct inode flush completely.
If that inode has any significant delayed allocation space on it,
then the only reason it gets to an ENOSPC is that is has converted
all the speculative preallocation that it already has reserved
and is trying to allocate new space. Hence flushing it will not
return any extra space.

Hmmmmm - given that we hold the iolock exclusively, the trylock I
added into xfs_sync_inodes_ag() will fail on the inode we currently
hold page locks on (tries to get iolock shared) so that should avoid
deadlock on the page we currently hold locked.  Can you remove the
direct inode flush and just run with the modified device flush to see
if that triggers the deadlock you've been seeing?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From michael.monnerie@is.it-management.at Thu Feb  5 02:23:01 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n158N01Q203881
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 02:23:01 -0600
X-ASG-Debug-ID: 1233822139-44c102840000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 069EB18CA525
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 00:22:19 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id iHePZGUocfz8cKLI for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 00:22:19 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id B78023D94
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 09:22:18 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id AB413400172
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 09:22:18 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Date: Thu, 5 Feb 2009 09:22:09 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
References: <498376CF.8020806@renderforce.de> <20090204153322.GC15454@theco.de> <200902041718.15836@zmi.at>
In-Reply-To: <200902041718.15836@zmi.at>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1521488.HW3kj7joOj";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200902050922.18307@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233822141
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17058
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--nextPart1521488.HW3kj7joOj
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Mittwoch 04 Februar 2009 Michael Monnerie wrote:
> > =A0 - if a RAID controller does not turn off the disks write cache,
> > the controller cannot know if previous writes have made it to the
> > disk.
>
> The controller could keep in-transfer blocks in it's cache, waiting
> for a confirm from the disk that the blocks are on the media, and
> only afterwards remove it from cache. I don't know if controllers do
> that actually. I'll ask Areca support on that.

I have an answer from Areca support:
*******************************************************
as soon as the hard drive firmware response command completed, the data=20
will be remove from controller cache. so controller will not known the=20
data had been trully write into disks or remain in hard drive cache=20
only.

by controller default setting, if controller have battery module=20
connected, it will automatically disable the hard drive cache for best=20
data protection. as you known, controller can't protect the data remain=20
in hard drive cache while power outage occured.

but this setting is configure-able, some customer may forece enable the=20
hard drive cacne for better performance. beucase hard drive without=20
cache enabled have quite poor performance.
*******************************************************
So I'd say they have a very sensible default:=20
If you use a BBM (battery backup module) then disk write caches will be=20
off, because you care about your data.=20
If you dont use a BBM anyway, they let disk write cache on because your=20
data is not save at all, so why care? 8-) And as most magazines will=20
test without a BBM, it improves speed up to the max, which is good for=20
benchmarks :-)

I'll put a section with RAID controllers into the wiki, if someone has=20
objections we can remove it again.

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4


--nextPart1521488.HW3kj7joOj
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkmKoboACgkQzhSR9xwSCbSDkACg6n3+h5z4YiSiD8lA9QW+Ubv2
RNYAniZgrCM2YXhc5LABsfaho7uBcn1r
=KnPh
-----END PGP SIGNATURE-----

--nextPart1521488.HW3kj7joOj--

From david@fromorbit.com Thu Feb  5 02:43:17 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n158hGwW204776
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 02:43:17 -0600
X-ASG-Debug-ID: 1233823356-6f8a03820000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 341F1EC506
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 00:42:37 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id CqDz3eOYBB1Sb7l0 for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 00:42:37 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAM8yikl5LClx/2dsb2JhbADQT4QWBg
X-IronPort-AV: E=Sophos;i="4.37,384,1231075800"; 
   d="scan'208";a="283366607"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 05 Feb 2009 19:07:02 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LUzjI-0007cb-7c; Thu, 05 Feb 2009 19:37:00 +1100
Date: Thu, 5 Feb 2009 19:37:00 +1100
From: Dave Chinner <david@fromorbit.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090205083700.GO24173@disturbed>
Mail-Followup-To: Michael Monnerie <michael.monnerie@is.it-management.at>,
	xfs@oss.sgi.com
References: <498376CF.8020806@renderforce.de> <200902040952.45440@zmi.at> <20090204122241.GL24173@disturbed> <200902041624.32354@zmi.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200902041624.32354@zmi.at>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233823358
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0042 1.0000 -1.9938
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.99
X-Barracuda-Spam-Status: No, SCORE=-1.99 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17058
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 04:24:27PM +0100, Michael Monnerie wrote:
> (compressing 2 answers here)
> 
> On Mittwoch 04 Februar 2009 Dave Chinner wrote:
> > > With a single hard disk and barriers turned on (on=default), a
> > > powerfail "only" looses data in the cache but at least does not
> > > destroy the filesystem.
> >
> > I'd drop this paragraph - powerfail can destroy filesystems even on
> > a single disk (e.g. root directory gets corrupted).
> 
> Isn't that what barriers are for? If I understand correctly, barriers 
> help against destroying the filesys, except root dir? But that should 
> "easily" be fixable with xfs_repair or so?

See, I didn't understand what you were trying to say. ;)

What I missed was the "barriers turned on" - I was referring
(context not quoted) to the fact that RAID5 is not unÑ–que in it's
ability to trash the filesystem on powerfail. You are right,
barriers on a single disk should prevent filesystem corruption
and will prevent loss of synchronously written data. only
asynchronously written data will get lost (just like all the
stuff sitting in RAM).

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From michael.monnerie@is.it-management.at Thu Feb  5 03:20:31 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n159KUdC206368
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 03:20:31 -0600
X-ASG-Debug-ID: 1233825565-05aa000b0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mailsrv1.zmi.at (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 3B46718CA81E
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 01:19:25 -0800 (PST)
Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id qw7vAj5fWSjELFth for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 01:19:25 -0800 (PST)
Received: from mailsrv2.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified))
	by mailsrv1.zmi.at (Postfix) with ESMTP id B08243D97
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 10:19:24 +0100 (CET)
Received: from saturn.localnet (saturn.i.zmi.at [10.0.0.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mailsrv2.i.zmi.at (Postfix) with ESMTPSA id AF508400172
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 10:19:24 +0100 (CET)
From: Michael Monnerie <michael.monnerie@is.it-management.at>
Organization: it-management http://it-management.at
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Wiki entry for disk write caches and RAID controllers
Subject: Wiki entry for disk write caches and RAID controllers
Date: Thu, 5 Feb 2009 10:19:24 +0100
User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200902051019.24403@zmi.at>
X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198]
X-Barracuda-Start-Time: 1233825566
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.92
X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17062
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.10 BSF_SC0_SA085          Custom Rule SA085
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

I updated the sections about "disk write cache" and "RAID controllers",=20
please review and comment.

http://xfs.org/index.php/XFS_FAQ

I merged my original paragraph about "disk write cache" with the "What=20
is the problem with the write cache on journaled filesystems?" text.

On Donnerstag 05 Februar 2009 Dave Chinner wrote:
> What I missed was the "barriers turned on" - I was referring
> (context not quoted) to the fact that RAID5 is not un=D1=96que in it's
> ability to trash the filesystem on powerfail. You are right,
> barriers on a single disk should prevent filesystem corruption
> and will prevent loss of synchronously written data. only
> asynchronously written data will get lost (just like all the
> stuff sitting in RAM).

So can we say that 1 disk can let write cache on with barriers enabled?

=46or the Xyratex case: If all write caches are off (or write through),=20
does it matter if you use [no]barrier? I guess no, just want to be sure.

mfg zmi
=2D-=20
// Michael Monnerie, Ing.BSc    -----      http://it-management.at
// Tel: 0660 / 415 65 31                      .network.your.ideas.
// PGP Key:         "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38  500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net                  Key-ID: 1C1209B4

From SRS0+c85f6bd184c1acadfeb0+1992+infradead.org+hch@bombadil.srs.infradead.org Thu Feb  5 05:24:10 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15BOAB4209980
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 05:24:10 -0600
X-ASG-Debug-ID: 1233833011-059402850000-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 DB87018CB4D0
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 03:23:31 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 8qj9E1EaxwzvSBxi for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 03:23:31 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LV2Jv-0004pj-IT; Thu, 05 Feb 2009 11:22:59 +0000
Date: Thu, 5 Feb 2009 06:22:59 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Felix Blyakher <felixb@sgi.com>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfsprogs 3.0.0 source tarball released
Subject: Re: xfsprogs 3.0.0 source tarball released
Message-ID: <20090205112259.GA11781@infradead.org>
References: <86FA5963-93E1-4BB6-ACC1-70D1628CB926@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86FA5963-93E1-4BB6-ACC1-70D1628CB926@sgi.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233833011
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Wed, Feb 04, 2009 at 06:19:51PM -0600, Felix Blyakher wrote:
> ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.0.0.tar.gz
>
> This version contains important bug fixes and improvements
> to xfsprogs 2.10.2:

It looks like the tag / final CHANGES update for this one weren't pushed
out to oss.sgi.com (unlike dmapi/xfsdump, which are there).

From SRS0+c85f6bd184c1acadfeb0+1992+infradead.org+hch@bombadil.srs.infradead.org Thu Feb  5 05:29:46 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15BTk0L210196
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 05:29:46 -0600
X-ASG-Debug-ID: 1233833347-71e903110000-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 D964EEA2F6; Thu,  5 Feb 2009 03:29:07 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Qk2EMCX1g7r637mZ; Thu, 05 Feb 2009 03:29:07 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LV2Pq-0003wc-RF; Thu, 05 Feb 2009 11:29:06 +0000
Date: Thu, 5 Feb 2009 06:29:06 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Mark Goodwin <markgw@sgi.com>
Cc: John Hesterberg <jh@sgi.com>, Eric Sandeen <sandeen@redhat.com>,
        SGI Engineering Interfaces to Red Hat <redhat-interface@sgi.com>,
        Marizol Martinez <martinez@redhat.com>, Tony Ernst <tee@sgi.com>,
        George Beshers <gbeshers@sgi.com>, xfs-oss <xfs@oss.sgi.com>,
        xfs-dev <xfs-dev@sgi.com>, Gary Hagensen <gwh@sgi.com>,
        Ric Wheeler <rwheeler@redhat.com>
X-ASG-Orig-Subj: Re: IMPORTANT: XFS Documentation
Subject: Re: IMPORTANT: XFS Documentation
Message-ID: <20090205112906.GB11781@infradead.org>
References: <1231946704.3929.36.camel@localhost.localdomain> <20090120160346.GJ17616@sgi.com> <1232480744.23291.101.camel@localhost.localdomain> <20090128202715.GR16689@sgi.com> <1233175168.25011.155.camel@localhost.localdomain> <20090204183603.GA26714@sgi.com> <4989F4C2.3030305@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4989F4C2.3030305@sgi.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233833347
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

> Sorry for the delay - the lawyers were pondering the GNU FDL Vrs the
> Creative Commons license (and settled on the latter). So now that's  
> resolved,
> I've updated the copyrights in the doc sources and put them in a git tree:
>
> 	git://oss.sgi.com/xfs/cmds/xfsdocs.git

Russell, can you add this to the list of repositories to be displayed on

	http://oss.sgi.com/cgi-bin/gitweb.cgi

?

Talking about that any chance you could convert your cvsimport
repositories to bare repos like all the others on oss?  And maybe
move the old xfs-cmds import under cattelan/ like the other cvsimport
ones?

From eflorac@intellique.com Thu Feb  5 06:06:31 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15C6UxM211560
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 06:06:31 -0600
X-ASG-Debug-ID: 1233835546-79fc038a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from smtp2-g21.free.fr (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id EF396EA532
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 04:05:50 -0800 (PST)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by cuda.sgi.com with ESMTP id eRRw8W9BXiiyDuEb for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 04:05:50 -0800 (PST)
Received: from smtp2-g21.free.fr (localhost [127.0.0.1])
	by smtp2-g21.free.fr (Postfix) with ESMTP id AAD3D4B004D;
	Thu,  5 Feb 2009 13:05:43 +0100 (CET)
Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72])
	by smtp2-g21.free.fr (Postfix) with ESMTP id A64174B011A;
	Thu,  5 Feb 2009 13:05:40 +0100 (CET)
Date: Thu, 5 Feb 2009 13:05:44 +0100
From: Emmanuel Florac <eflorac@intellique.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
Message-ID: <20090205130544.223a8fcd@harpe.intellique.com>
In-Reply-To: <200902050922.18307@zmi.at>
References: <498376CF.8020806@renderforce.de>
	<20090204153322.GC15454@theco.de>
	<200902041718.15836@zmi.at>
	<200902050922.18307@zmi.at>
Organization: Intellique
X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Barracuda-Connect: smtp2-g21.free.fr[212.27.42.2]
X-Barracuda-Start-Time: 1233835551
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17071
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Le Thu, 5 Feb 2009 09:22:09 +0100
Michael Monnerie <michael.monnerie@is.it-management.at> =E9crivait:

> I have an answer from Areca support:

Excellent. I'll ask 3Ware, Adaptec and Xyratex on this particular
point.

--=20
----------------------------------------
Emmanuel Florac     |   Intellique
----------------------------------------

From aditya@kqinfotech.com Thu Feb  5 06:58:03 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: ***
X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15Cw1ME214510
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 06:58:03 -0600
X-ASG-Debug-ID: 1233838642-1f3c035e0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from yw-out-1718.google.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id D6C02EC92B
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 04:57:22 -0800 (PST)
Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.156]) by cuda.sgi.com with ESMTP id NEHt1EDA2ALpgLTF for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 04:57:22 -0800 (PST)
Received: by yw-out-1718.google.com with SMTP id 5so67314ywm.32
        for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 04:57:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.147.9 with SMTP id u9mr494110ybd.242.1233837325463; Thu, 
	05 Feb 2009 04:35:25 -0800 (PST)
Date: Thu, 5 Feb 2009 18:05:25 +0530
Message-ID: <cdca4ea70902050435l60c70ee5i2ce1f8971a59cf26@mail.gmail.com>
X-ASG-Orig-Subj: xfs_db guide
Subject: xfs_db guide
From: Aditya Alate <aditya@kqinfotech.com>
To: xfs@oss.sgi.com
Content-Type: multipart/alternative; boundary=000e0cd51a3a7eb09a04622b239d
X-Barracuda-Connect: yw-out-1718.google.com[74.125.46.156]
X-Barracuda-Start-Time: 1233838642
X-Barracuda-Bayes: INNOCENT GLOBAL 0.3082 1.0000 -0.3137
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -0.31
X-Barracuda-Spam-Status: No, SCORE=-0.31 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17075
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.00 HTML_MESSAGE           BODY: HTML included in message
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--000e0cd51a3a7eb09a04622b239d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello there,
Is there any admin_guide kind of document for using xfs_db. I was searching
on web but couldn't find  any brief description. man page for xfs_db is not
just enough.

If somebody have user guide for xfs_db, pls do forward.

Thanks
Aditya Alate

--000e0cd51a3a7eb09a04622b239d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello there,<br>Is there any admin_guide kind of document for using xfs_db.=
 I was searching on web but couldn&#39;t find&nbsp; any brief description. =
man page for xfs_db is not just enough.<br><br>If somebody have user guide =
for xfs_db, pls do forward. <br>
<br>Thanks<br>Aditya Alate<br>

--000e0cd51a3a7eb09a04622b239d--

From ewan.chalmers@gmail.com Thu Feb  5 08:51:34 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: **
X-Spam-Status: No, score=2.4 required=5.0 tests=BAYES_00,HEADER_ESQ
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15EpWFP219871
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 08:51:34 -0600
X-ASG-Debug-ID: 1233845452-47db02210000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from fk-out-0910.google.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 792CBED0EE
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 06:50:52 -0800 (PST)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by cuda.sgi.com with ESMTP id BWxVC7Bs3XjF9n16 for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 06:50:52 -0800 (PST)
Received: by fk-out-0910.google.com with SMTP id e30so306350fke.4
        for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 06:50:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:content-type:content-transfer-encoding;
        bh=EUGWi7FqipT4ivbBtQBYgXMHOFf4YC1pxsB8WmdMjog=;
        b=mHbBY/MxdDj5JFyXSMRmYrnupCUI3g07Qdrmc/T6PlohOJKnb2wq7zo03Dfqxx6gW7
         4FEWAPQuogCJMi+BDAhzXy3p1IImg2IbI7vPWLIJ4tppYzA/UgvHGcvy3h7I3ytozpQq
         c+QUNoR+AN7DG8NWdyjkQV+1lqckEhBXV1ZaM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=YYQ2Q1blDZVulHPc3qK5kaq29UcVY1/NjP++/tOGDlhkG70Ars4KzKQ7G8ehYjLOed
         o5RzmF4m58bA/CwEPb3zWH0aQqIst3HockPXFSCpSurdpeA0hNunDdXDLfaswpEhBG/b
         zxpEcMpg8PFYcGRelVYcOEsqOfyVPK0VI8HV4=
MIME-Version: 1.0
Received: by 10.180.221.13 with SMTP id t13mr193869bkg.55.1233845009473; Thu, 
	05 Feb 2009 06:43:29 -0800 (PST)
Date: Thu, 5 Feb 2009 14:43:29 +0000
Message-ID: <884979c90902050643m78d2e0dbt85aa7f4369e243ef@mail.gmail.com>
X-ASG-Orig-Subj: Does XFS support the sync mount option?
Subject: Does XFS support the sync mount option?
From: Ewan Chalmers <ewan.chalmers@gmail.com>
To: xfs@oss.sgi.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: fk-out-0910.google.com[209.85.128.186]
X-Barracuda-Start-Time: 1233845453
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17082
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

I am interested to know whether XFS supports the sync mount option.

I am using XFS on an external USB disk and automounting using the
ubuntu/debian usbmount package
(http://packages.ubuntu.com/intrepid/usbmount). The disk is connected
to a headless server. I would like to be able to safely switch the
disk on/off on demand without first logging in to the box to
sync/unmount. I believe the sync option is essential to this use case.
Using usbmount, it appears to work correctly, but the output to syslog
makes me wonder.

The default configuration for usbmount includes

FILESYSTEMS="ext2 ext3"
MOUNTOPTIONS="sync,noexec,nodev,noatime"

I have added xfs to the FILESYSTEMS list.

On switching off the disk, I see the following output in syslog

kernel: [1034259.923629] usb 1-2: USB disconnect, address 26
kernel: [1034259.936251] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034259.936334] Filesystem "sdb1": I/O Error Detected.
Shutting down filesystem: sdb1
kernel: [1034259.936404] Please umount the filesystem, and rectify the
problem(s)
kernel: [1034259.949818] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034259.949851] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034259.949890] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034259.968157] Filesystem "sdb1": xfs_log_force: error 5 returned.
usbmount[16307]: executing command: umount -l /media/usb0
kernel: [1034260.050924] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.057086] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.061208] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
kernel: [1034260.069650] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.073675] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.077672] xfs_force_shutdown(sdb1,0x1) called from line
420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
address = 0xe0a9ddb4
usbmount[16307]: executing command: run-parts /etc/usbmount/umount.d
kernel: [1034260.084706] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084735] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084820] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084864] Filesystem "sdb1": xfs_log_force: error 5 returned.
kernel: [1034260.084891] Filesystem "sdb1": xfs_log_force: error 5 returned.

But the disk remounts cleanly when it is switched back on.

kernel: [1034394.920087] usb 1-2: new high speed USB device using
ehci_hcd and address 27
kernel: [1034395.064826] usb 1-2: configuration #1 chosen from 1 choice
kernel: [1034395.078845] scsi25 : SCSI emulation for USB Mass Storage devices
kernel: [1034395.085992] usb-storage: device found at 27
kernel: [1034395.086033] usb-storage: waiting for device to settle
before scanning
kernel: [1034400.084595] usb-storage: device scan complete
kernel: [1034400.087474] scsi 25:0:0:0: Direct-Access     WDC WD10
EADS-00L5B1      0041 PQ: 0 ANSI: 0
kernel: [1034400.091636] sd 25:0:0:0: [sdb] 1953525168 512-byte
hardware sectors (1000205 MB)
kernel: [1034400.094271] sd 25:0:0:0: [sdb] Write Protect is off
kernel: [1034400.094309] sd 25:0:0:0: [sdb] Mode Sense: 03 00 00 00
kernel: [1034400.094328] sd 25:0:0:0: [sdb] Assuming drive cache: write through
kernel: [1034400.104985] sd 25:0:0:0: [sdb] 1953525168 512-byte
hardware sectors (1000205 MB)
kernel: [1034400.113058] sd 25:0:0:0: [sdb] Write Protect is off
kernel: [1034400.113094] sd 25:0:0:0: [sdb] Mode Sense: 03 00 00 00
kernel: [1034400.113114] sd 25:0:0:0: [sdb] Assuming drive cache: write through
kernel: [1034400.120193]  sdb: sdb1
kernel: [1034400.137434] sd 25:0:0:0: [sdb] Attached SCSI disk
kernel: [1034400.137980] sd 25:0:0:0: Attached scsi generic sg1 type 0
usbmount[16483]: executing command: mount -txfs
-osync,noexec,nodev,noatime /dev/sdb1 /media/usb0
kernel: [1034401.228110] XFS mounting filesystem sdb1
kernel: [1034401.710070] Ending clean XFS mount for filesystem: sdb1
usbmount[16483]: executing command: run-parts /etc/usbmount/mount.d

I would be interested to know whether it is reasonable to use XFS in
the way I have outlined.

Thanks,
Ewan

From felixb@sgi.com Thu Feb  5 14:29:42 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15KTfKF231758
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 14:29:41 -0600
Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44])
	by relay3.corp.sgi.com (Postfix) with ESMTP id 40CBFAC029;
	Thu,  5 Feb 2009 12:29:00 -0800 (PST)
Received: by attica.americas.sgi.com (Postfix, from userid 29043)
	id BA0E11419BF8A; Thu,  5 Feb 2009 14:28:59 -0600 (CST)
From: Felix Blyakher <felixb@sgi.com>
To: xfs@sgi.com
Cc: Felix Blyakher <felixb@sgi.com>
Subject: [PATCH] xfs: Update maintainers
Date: Thu,  5 Feb 2009 14:28:59 -0600
Message-Id: <1233865739-21486-1-git-send-email-felixb@sgi.com>
X-Mailer: git-send-email 1.6.1
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

New maintainer contact info.

Signed-off-by: Felix Blyakher <felixb@sgi.com>
---
 MAINTAINERS |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 474ec0c..d23851b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4856,7 +4856,8 @@ S:	Supported
 
 XFS FILESYSTEM
 P:	Silicon Graphics Inc
-P:	Bill O'Donnell
+P:	Felix Blyakher
+M:	felixb@sgi.com
 M:	xfs-masters@oss.sgi.com
 L:	xfs@oss.sgi.com
 W:	http://oss.sgi.com/projects/xfs
-- 
1.6.1

From sandeen@sandeen.net Thu Feb  5 16:27:49 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n15MRnWG237167
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 16:27:49 -0600
X-ASG-Debug-ID: 1233872829-27e903e70000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP
	id F119DF04D8; Thu,  5 Feb 2009 14:27:09 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id sJQNBImZJw7GYdLP; Thu, 05 Feb 2009 14:27:09 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n15MR8Kk011383;
	Thu, 5 Feb 2009 17:27:08 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n15MR83E018925;
	Thu, 5 Feb 2009 17:27:08 -0500
Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n15MR6Jr024463;
	Thu, 5 Feb 2009 17:27:06 -0500
Message-ID: <498B67B9.3020505@sandeen.net>
Date: Thu, 05 Feb 2009 16:27:05 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: markgw@sgi.com
CC: John Hesterberg <jh@sgi.com>, Eric Sandeen <sandeen@redhat.com>,
        SGI Engineering Interfaces to Red Hat <redhat-interface@sgi.com>,
        Marizol Martinez <martinez@redhat.com>, Tony Ernst <tee@sgi.com>,
        George Beshers <gbeshers@sgi.com>, xfs-oss <xfs@oss.sgi.com>,
        xfs-dev <xfs-dev@sgi.com>, Gary Hagensen <gwh@sgi.com>,
        Ric Wheeler <rwheeler@redhat.com>
X-ASG-Orig-Subj: Re: IMPORTANT: XFS Documentation
Subject: Re: IMPORTANT: XFS Documentation
References: <1231946704.3929.36.camel@localhost.localdomain>	<20090120160346.GJ17616@sgi.com>	<1232480744.23291.101.camel@localhost.localdomain>	<20090128202715.GR16689@sgi.com>	<1233175168.25011.155.camel@localhost.localdomain>	<20090204183603.GA26714@sgi.com> <4989F4C2.3030305@sgi.com>
In-Reply-To: <4989F4C2.3030305@sgi.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233872830
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0338 1.0000 -1.8026
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.80
X-Barracuda-Spam-Status: No, SCORE=-1.80 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17103
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Mark Goodwin wrote:
> 
> 
> Sorry for the delay - the lawyers were pondering the GNU FDL Vrs the
> Creative Commons license (and settled on the latter). So now that's 
> resolved,
> I've updated the copyrights in the doc sources and put them in a git tree:
> 
> 	git://oss.sgi.com/xfs/cmds/xfsdocs.git
> 
> This repository is XFS group writable on oss.sgi.com. The directory 
> structure
> corresponds to (a subset of) the internal ptools tree below 
> xfs-cmds/xfsdocs.
> Since the files in this repository are binary, you'll need to co-ordinate
> check-out/check-in to avoid merge failures (git handles binaries but 
> can't merge
> them). I think Eric and/or others inside Redhat will have the first go 
> at it :)
> I also regenerated the PDFs and committed them too since they're also 
> present
> in the internal ptools tree.


Mark, John, & SGI - thanks for doing this, getting good docs out under a
license like this should allow them to continue to be relevant living
documents, and will add to the vitality of XFS in the future, I'm sure.
 Now of course I'll need to step up and contribute some updates.  :)

Thanks,

-Eric

From audio@pb-conferences.com Thu Feb  5 20:12:21 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n162CJ1U247587
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 20:12:20 -0600
X-ASG-Debug-ID: 1233886299-601802090000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from evempbp04.workforpbp.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 16651F1823
	for <xfs@oss.sgi.com>; Thu,  5 Feb 2009 18:11:39 -0800 (PST)
Received: from evempbp04.workforpbp.com (evempbp04.workforpbp.com [208.89.23.69]) by cuda.sgi.com with ESMTP id DaDWNjLjPU82SDmJ for <xfs@oss.sgi.com>; Thu, 05 Feb 2009 18:11:39 -0800 (PST)
Received: from PBP-04 (208.89.23.69) by evempbp04.workforpbp.com id hhee8o0ktasf for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 21:12:26 -0500 (envelope-from <audio@pb-conferences.com>)
Date: Thu, 05 Feb 2009 21:12:26 -0500
X-Mailer: PDSoft Smtp Control v4.0.390
X-Sender: audio@pb-conferences.com
To: xfs@oss.sgi.com
From: "audio@pb-conferences.com" <audio@pb-conferences.com>
X-ASG-Orig-Subj: Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference
Subject: Handling Difficult Conversations: Keys to Stopping Bad Behavior: 3/11 Audio Conference
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii"
X-Barracuda-Connect: evempbp04.workforpbp.com[208.89.23.69]
X-Barracuda-Start-Time: 1233886301
Message-Id: <20090206021139.16651F1823@cuda.sgi.com>
X-Barracuda-Bayes: INNOCENT GLOBAL 0.4992 1.0000 0.0000
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17115
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Dear David Chinner,

For those concerned about handling difficult conversations 
with employees, you are invited to join us for our 
leading 60-minute audio conference:

"Handling Difficult Conversations: Keys to Stopping Bad Behavior"
Wednesday, March 11, 2009 - 1:00-2:00 p.m. ET
http://www.pb-conferences.com/8K/0/2/p29X9Fc/p1V4TXABi/p0e

Managers do it all the time – avoid difficult conversations, hoping
the problem will go away. If left unaddressed, these problems fester –
causing bigger problems for you and your team. Join us for a 60-minute
audio conference where you and your team will discover how to:

  ** Deliver criticism without creating confrontation and conflict
  ** Eliminate the fear of confronting employees
  ** Handle employees with bad attitudes
  ** Prevent a worker's negative emotions from spreading to others


Back by popular demand, Larry Johnson is one of our highest rated
presenters. He is recognized as a leading expert in reducing
turnover, increasing productivity and boosting morale.

  ** Since 1986, Larry Johnson has been president of a successful
     international management development firm
  ** His clients include Harley-Davidson, the National Apartment
     Association, the Royal College of Nursing, Southwest Airlines,
     American Express, McDonald's Corporation, Federal Express, the 
     U.S. Bureau of Land Management, and the American Health Care
     Association.
  ** Larry has written more than 50 articles on the topics of
     leadership, people management, customer service, and changing
     corporate culture. He is the co-author of Absolute Honesty:
     Building A Corporate Culture That Values Straight Talk and
     Rewards Integrity

EARN HRCI Credit:

This program has been approved for 1 recertification credit hour 
toward PHR and SPHR recertification through the Human Resource 
Certification Institute (HRCI). For more information about  
certification or recertification, please visit the HRCI homepage at 
www.hrci.org

Hosted by Progressive Business Publications, the leader in fast-read 
actionable advice on workplace issues, the audio conference gives you
the opportunity to add immediate, impact to your marketing efforts in
a manner that is:

FAST - No wasted time here. Get right to the heart of the matter in a
1-hour block designed to easily fit into your busy schedule. 

CONVENIENT - No airlines. No travel. No time out of the office. 
Listen from the comfort and convenience of your desk. 

EASY - A telephone is all the equipment you need. Just dial in, punch
in your access code, and you're in. That's it. Follow along with the
audio conference handouts provided in advance.

ACTIONABLE - Our audio conferences provide money-saving tactics you
can start using right when you hang up the phone.

IDEAL FOR MULTIPLE LISTENERS - Use a speakerphone and as many people
as you want can listen in - at no extra cost to you. Many professionals
use these sessions as a cost-efficient, time-efficient means of
training supervisors, managers, and staff and reinforcing key
issues in a fresh new manner that they will remember and act on.
 
AFFORDABLE - Priced at $199, it is a fraction of the cost of travel
and attendance fees for other high-priced conferences or seminars. 

** "Handling Difficult Conversations: Keys to Stopping 
    Bad Behavior " **
** Live, 60-Minute Audio Conference **
** Wednesday, March 11, 2009 - 1:00-2:00 p.m. ET **

Register now for this exciting event by clicking the following link
or calling 800-964-6033.
http://www.pb-conferences.com/8K/0/2/p29X9Fc/p1V4TXABi/p0e

We hope you'll join us.

Sincerely,

Progressive Business Audio Conferences
384 Technology Drive
Malvern, PA 19355

P.S. As usual we offer a full refund if not satisfied from now until
7 days after the event.

If you do not wish to receive further notices about this conference,
or future conferences, please click here:
http://www.pb-conferences.com/8K/3T/2/p29X9Fc/p1V4TXABi/p0e

Please do not reply directly to this e-mail, as we are unable to
process it. We sent this using a "send only" address.

If registering by phone, please refer to your priority
code: 51349

ContactID#: -1861465238 


From felixb@sgi.com Thu Feb  5 23:22:03 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n165M2LN259632
	for <xfs@oss.sgi.com>; Thu, 5 Feb 2009 23:22:02 -0600
Received: from [IPv6:::1] (sshcf.sgi.com [198.149.20.12])
	by relay3.corp.sgi.com (Postfix) with ESMTP id 14598AC039;
	Thu,  5 Feb 2009 21:21:20 -0800 (PST)
In-Reply-To: <20090126073202.277472000@bombadil.infradead.org>
References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.277472000@bombadil.infradead.org>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F4717E19-7A7F-40CD-BAEB-7AE519E797D0@sgi.com>
Cc: xfs@oss.sgi.com
Content-Transfer-Encoding: 7bit
From: Felix Blyakher <felixb@sgi.com>
Subject: Re: [PATCH 09/17] xfs: cleanup xfs_find_handle
Date: Thu, 5 Feb 2009 23:20:22 -0600
To: Christoph Hellwig <hch@infradead.org>
X-Mailer: Apple Mail (2.753.1)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean


On Jan 26, 2009, at 1:31 AM, Christoph Hellwig wrote:

> Remove the superflous igrab by keeping a reference on the path/file  
> all the
> time and clean up various bits of surrounding code.
>
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Index: xfs/fs/xfs/linux-2.6/xfs_ioctl.c
> ===================================================================
> --- xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c	2009-01-21  
> 21:03:27.828295110 +0100
> +++ xfs/fs/xfs/linux-2.6/xfs_ioctl.c	2009-01-24 18:41:24.547427865  
> +0100
> @@ -78,92 +78,74 @@ xfs_find_handle(
>  	int			hsize;
>  	xfs_handle_t		handle;
>  	struct inode		*inode;
> +	struct file		*file = NULL;
> +	struct path		path;
> +	int			error;
> +	struct xfs_inode	*ip;
>
> -	memset((char *)&handle, 0, sizeof(handle));
> -
> -	switch (cmd) {
> -	case XFS_IOC_PATH_TO_FSHANDLE:
> -	case XFS_IOC_PATH_TO_HANDLE: {
> -		struct path path;
> -		int error = user_lpath((const char __user *)hreq->path, &path);
> +	if (cmd == XFS_IOC_FD_TO_HANDLE) {
> +		file = fget(hreq->fd);
> +		if (!file)
> +			return -EBADF;
> +		inode = file->f_path.dentry->d_inode;
> +	} else {

Do we want to verify here that cmd is either XFS_IOC_PATH_TO_FSHANDLE
or XFS_IOC_PATH_TO_HANDLE ...

> +		error = user_lpath((const char __user *)hreq->path, &path);
>  		if (error)
>  			return error;
> -
> -		ASSERT(path.dentry);
> -		ASSERT(path.dentry->d_inode);
> -		inode = igrab(path.dentry->d_inode);
> -		path_put(&path);
> -		break;
> +		inode = path.dentry->d_inode;
>  	}

... and fail with EINVAL if cmd is neither.

> +	ip = XFS_I(inode);
>
> -	case XFS_IOC_FD_TO_HANDLE: {
> -		struct file	*file;
> -
> -		file = fget(hreq->fd);
> -		if (!file)
> -		    return -EBADF;
> +	/*
> +	 * We can only generate handles for inodes residing on a XFS  
> filesystem,
> +	 * and only for regular files, directories or symbolic links.
> +	 */
> +	error = -EINVAL;
> +	if (inode->i_sb->s_magic != XFS_SB_MAGIC)
> +		goto out_put;
>
> -		ASSERT(file->f_path.dentry);
> -		ASSERT(file->f_path.dentry->d_inode);
> -		inode = igrab(file->f_path.dentry->d_inode);
> -		fput(file);
> -		break;
> -	}
> +	error = -EBADF;
> +	if (!S_ISREG(inode->i_mode) &&
> +	    !S_ISDIR(inode->i_mode) &&
> +	    !S_ISLNK(inode->i_mode))
> +		goto out_put;
>
> -	default:
> -		ASSERT(0);
> -		return -XFS_ERROR(EINVAL);
> -	}
>
> -	if (inode->i_sb->s_magic != XFS_SB_MAGIC) {
> -		/* we're not in XFS anymore, Toto */
> -		iput(inode);
> -		return -XFS_ERROR(EINVAL);
> -	}
> +	memcpy(&handle.ha_fsid, ip->i_mount->m_fixedfsid, sizeof 
> (xfs_fsid_t));
>
> -	switch (inode->i_mode & S_IFMT) {
> -	case S_IFREG:
> -	case S_IFDIR:
> -	case S_IFLNK:
> -		break;
> -	default:
> -		iput(inode);
> -		return -XFS_ERROR(EBADF);
> -	}
> -
> -	/* now we can grab the fsid */
> -	memcpy(&handle.ha_fsid, XFS_I(inode)->i_mount->m_fixedfsid,
> -			sizeof(xfs_fsid_t));
> -	hsize = sizeof(xfs_fsid_t);
> -
> -	if (cmd != XFS_IOC_PATH_TO_FSHANDLE) {
> -		xfs_inode_t	*ip = XFS_I(inode);
> +	if (cmd == XFS_IOC_PATH_TO_FSHANDLE) {
> +		/*
> +		 * This handle only contains an fsid, zero the rest.
> +		 */
> +		memset(&handle.ha_fid, 0, sizeof(handle.ha_fid));
> +		hsize = sizeof(xfs_fsid_t);
> +	} else {
>  		int		lock_mode;
>
> -		/* need to get access to the xfs_inode to read the generation */
>  		lock_mode = xfs_ilock_map_shared(ip);
> -
> -		/* fill in fid section of handle from inode */
>  		handle.ha_fid.fid_len = sizeof(xfs_fid_t) -
>  					sizeof(handle.ha_fid.fid_len);
>  		handle.ha_fid.fid_pad = 0;
>  		handle.ha_fid.fid_gen = ip->i_d.di_gen;
>  		handle.ha_fid.fid_ino = ip->i_ino;
> -
>  		xfs_iunlock_map_shared(ip, lock_mode);
>
>  		hsize = XFS_HSIZE(handle);
>  	}
>
> -	/* now copy our handle into the user buffer & write out the size */
> +	error = -EFAULT;
>  	if (copy_to_user(hreq->ohandle, &handle, hsize) ||
> -	    copy_to_user(hreq->ohandlen, &hsize, sizeof(__s32))) {
> -		iput(inode);
> -		return -XFS_ERROR(EFAULT);
> -	}
> +	    copy_to_user(hreq->ohandlen, &hsize, sizeof(__s32)))
> +		goto out_put;
>
> -	iput(inode);
> -	return 0;
> +	error = 0;
> +
> + out_put:
> +	if (cmd == XFS_IOC_FD_TO_HANDLE)
> +		fput(file);
> +	else
> +		path_put(&path);
> +	return error;
>  }
>
>  /*
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

From SRS0+9fde8a4895808fc49111+1993+infradead.org+hch@bombadil.srs.infradead.org Fri Feb  6 01:18:00 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n167Hvk6006515
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 01:18:00 -0600
X-ASG-Debug-ID: 1233904638-5cd8021b0000-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 5E0FB18D965E; Thu,  5 Feb 2009 23:17:18 -0800 (PST)
Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id pL0bZEC6aHMAyV0t; Thu, 05 Feb 2009 23:17:18 -0800 (PST)
X-ASG-Whitelist: Client
Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux))
	id 1LVKxi-00026B-0W; Fri, 06 Feb 2009 07:17:18 +0000
Date: Fri, 6 Feb 2009 02:17:17 -0500
From: Christoph Hellwig <hch@infradead.org>
To: Felix Blyakher <felixb@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: [PATCH 09/17] xfs: cleanup xfs_find_handle
Subject: Re: [PATCH 09/17] xfs: cleanup xfs_find_handle
Message-ID: <20090206071717.GA3295@infradead.org>
References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.277472000@bombadil.infradead.org> <F4717E19-7A7F-40CD-BAEB-7AE519E797D0@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F4717E19-7A7F-40CD-BAEB-7AE519E797D0@sgi.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> 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: 1233904639
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Thu, Feb 05, 2009 at 11:20:22PM -0600, Felix Blyakher wrote:
> Do we want to verify here that cmd is either XFS_IOC_PATH_TO_FSHANDLE
> or XFS_IOC_PATH_TO_HANDLE ...

It's called in a single place for just these three subcases, so having
another verification here doesn't seem juseful.

From lists@nabble.com Fri Feb  6 07:42:53 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,WHOIS_MYPRIVREG
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16DgqPb029697
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 07:42:53 -0600
X-ASG-Debug-ID: 1233927733-71bd01c40000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from kuber.nabble.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 6880B18DB155
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 05:42:13 -0800 (PST)
Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id DMtlJZglkc8OurCQ for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 05:42:13 -0800 (PST)
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1LVQxi-0003gN-9G
	for xfs@oss.sgi.com; Fri, 06 Feb 2009 05:41:42 -0800
Message-ID: <21872592.post@talk.nabble.com>
Date: Fri, 6 Feb 2009 05:41:42 -0800 (PST)
From: cyjoyp <cyjoyp@gmail.com>
To: xfs@oss.sgi.com
X-ASG-Orig-Subj: Inode Core Information
Subject: Inode Core Information
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: cyjoyp@gmail.com
X-Barracuda-Connect: kuber.nabble.com[216.139.236.158]
X-Barracuda-Start-Time: 1233927734
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17161
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean


Hello Everyone,
      Could any one help in extracting the modified time information from
xfs_dinode_core_t   structure (Inode Core)?
     Please help me.
-- 
View this message in context: http://www.nabble.com/Inode-Core-Information-tp21872592p21872592.html
Sent from the Xfs - General mailing list archive at Nabble.com.

From Steffen.Knauf@renderforce.de Fri Feb  6 09:59:05 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) 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-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16Fx4GW036748
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 09:59:05 -0600
X-ASG-Debug-ID: 1233935905-668501100000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mo-p05-ob.rzone.de (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 3BFF0F4B06
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 07:58:25 -0800 (PST)
Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.182]) by cuda.sgi.com with ESMTP id toH4lC5hEUznZ0Pk for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 07:58:25 -0800 (PST)
X-RZG-CLASS-ID: mo05
X-RZG-AUTH: :H3gBc0atdbFtJ1Tm6DmIAJ8B9/zEJuDw3kht7VZV0tCFY/5FKa7gzp+AtV8tv3RUbDrI9Q==
Received: from [10.1.1.65] ([213.39.240.61])
	by post.strato.de (klopstock mo56) (RZmta 18.15)
	with ESMTP id 5030e9l16EfijV ; Fri, 6 Feb 2009 16:58:22 +0100 (MET)
Message-ID: <498C5DE1.9070200@renderforce.de>
Date: Fri, 06 Feb 2009 16:57:21 +0100
From: Steffen Knauf <Steffen.Knauf@renderforce.de>
Reply-To: Steffen.Knauf@liga01.de
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Christoph Hellwig <hch@infradead.org>
CC: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: xfs_force_shutdown after Raid crash
Subject: Re: xfs_force_shutdown after Raid crash
References: <498376CF.8020806@renderforce.de> <20090131105712.GA30061@infradead.org>
In-Reply-To: <20090131105712.GA30061@infradead.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: mo-p05-ob.rzone.de[81.169.146.182]
X-Barracuda-Start-Time: 1233935906
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17171
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Hello,

sorry for the delay. I don't know whether it is interesting, but after a 
xfs_repair, the filesystem could completely rebuild.
Thanks Chritoph. I'm a little bit confused about "write back cache" and 
the "barrier" option.
On the RAID Controller "Write Cache" is enabled, "Write Cache Periodic 
Flush = 5 seconds" and "Write Cache Flush Ratio = 45 Percent".
My kernelversion is 2.6.16 (SLES10), so the default should be nobarrier. 
But i read in the official SGI xfs Training documentation that write 
Barrier are enabled by default on SLES10.
How can i check if barrier is on or off?. I don't find something in the log.

greets

Steffen

> On Fri, Jan 30, 2009 at 10:53:19PM +0100, Steffen Knauf wrote:
>   
>> Hello,
>>
>> after a raid crash (Raid Controller problem, 3 Disks of the Disk Group  
>> were kicked out oft the diskgroup), 2 of 3 partitions (XFS FS) were  
>> shutdown immediately.
>> Perhaps somebody has a idea, what's the best solution (xfs_repair?).
>>     
>
> This looks like you were running with a write back cache enabled on the
> controller / disks but without barriers.  xfs_repair should be able
> to repair the filesystem.  If you're lucky only the freespace-btrees
> are corrupted (as in the trace below) as xfs_repair can rebuild them
> from scratch. 
>
>
>   

From Ahmed.Ezzat@hp.com Fri Feb  6 11:12:56 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: **
X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_20,HTML_MESSAGE
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16HCuiG039757
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 11:12:56 -0600
X-ASG-Debug-ID: 1233940337-593e02910000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from g5t0007.atlanta.hp.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 7910318E21BC
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 09:12:17 -0800 (PST)
Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by cuda.sgi.com with ESMTP id 963zxk53NSqJdoEE for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 09:12:17 -0800 (PST)
X-ASG-Whitelist: Barracuda Reputation
Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 73340147B4
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 17:12:17 +0000 (UTC)
Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by
 G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS)
 id 8.1.336.0; Fri, 6 Feb 2009 17:11:06 +0000
Received: from GVW1097EXB.americas.hpqcorp.net ([16.234.97.242]) by
 G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Fri, 6 Feb 2009
 17:11:06 +0000
From: "Ezzat, Ahmed" <Ahmed.Ezzat@hp.com>
To: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Date: Fri, 6 Feb 2009 17:11:03 +0000
X-ASG-Orig-Subj: Question...
Subject: Question...
Thread-Topic: Question...
Thread-Index: AcmIfePCCqIupTWGSzKLMe9yvFE9UQ==
Message-ID: <3B7AE9BA67C72B4891EF21842246A21C412E8E055C@GVW1097EXB.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_3B7AE9BA67C72B4891EF21842246A21C412E8E055CGVW1097EXBame_"
MIME-Version: 1.0
X-Barracuda-Connect: g5t0007.atlanta.hp.com[15.192.0.44]
X-Barracuda-Start-Time: 1233940338
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

--_000_3B7AE9BA67C72B4891EF21842246A21C412E8E055CGVW1097EXBame_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello,

Does XFS comes up as part of Red Hat Linux Enterprise 5 from HP? How to fin=
d out (any specific commands that I can issue man page to see if a Linux in=
stance support XFS or not?

Where I can find documentation (user guide and administrative guide) for XF=
S?
Thanks,

Ahmed




--_000_3B7AE9BA67C72B4891EF21842246A21C412E8E055CGVW1097EXBame_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Times New Roman, serif" size=3D"3">
<div>&nbsp;</div>
<div>Hello,</div>
<div>&nbsp;</div>
<div>Does XFS comes up as part of Red Hat Linux Enterprise 5 from HP? How t=
o find out (any specific commands that I can issue man page to see if a Lin=
ux instance support XFS or not?</div>
<div>&nbsp;</div>
<div>Where I can find documentation (user guide and administrative guide) f=
or XFS?</div>
<div>Thanks,</div>
<div>&nbsp;</div>
<div>Ahmed</div>
<a name=3D"_MailAutoSig"></a>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_3B7AE9BA67C72B4891EF21842246A21C412E8E055CGVW1097EXBame_--

From sandeen@sandeen.net Fri Feb  6 12:04:59 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16I4weR042873
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 12:04:59 -0600
X-ASG-Debug-ID: 1233943459-668502df0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from mx2.redhat.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id BF8B3F4B8D
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 10:04:19 -0800 (PST)
Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id Ch9niILv1OWhzDhg for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 10:04:19 -0800 (PST)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n16I4HBP030594;
	Fri, 6 Feb 2009 13:04:17 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n16I4HJh012495;
	Fri, 6 Feb 2009 13:04:17 -0500
Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n16I4GKn000357;
	Fri, 6 Feb 2009 13:04:17 -0500
Message-ID: <498C7B9F.6010003@sandeen.net>
Date: Fri, 06 Feb 2009 12:04:15 -0600
From: Eric Sandeen <sandeen@sandeen.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: "Ezzat, Ahmed" <Ahmed.Ezzat@hp.com>
CC: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
X-ASG-Orig-Subj: Re: Question...
Subject: Re: Question...
References: <3B7AE9BA67C72B4891EF21842246A21C412E8E055C@GVW1097EXB.americas.hpqcorp.net>
In-Reply-To: <3B7AE9BA67C72B4891EF21842246A21C412E8E055C@GVW1097EXB.americas.hpqcorp.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26
X-Barracuda-Connect: mx2.redhat.com[66.187.237.31]
X-Barracuda-Start-Time: 1233943460
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0203
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17178
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

Ezzat, Ahmed wrote:
>  
> Hello,
>  
> Does XFS comes up as part of Red Hat Linux Enterprise 5 from HP? 

Not today, sorry.

> How to
> find out (any specific commands that I can issue man page to see if a
> Linux instance support XFS or not?
>  
> Where I can find documentation (user guide and administrative guide) for
> XFS?
> Thanks,

XFS tutorial - http://oss.sgi.com/projects/xfs/training/index.html is a
start.

-Eric

From nscott@aconex.com Fri Feb  6 14:27:47 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16KRjxm049577
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 14:27:47 -0600
X-ASG-Debug-ID: 1233952026-06d7016d0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from postoffice2.aconex.com (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 21C62F6266
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 12:27:06 -0800 (PST)
Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id lPRzDyUhGx0KoNaY for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 12:27:06 -0800 (PST)
Received: from postoffice.aconex.com (localhost [127.0.0.1])
	by postoffice2.aconex.com (Spam Firewall) with ESMTP
	id AE2DF6D47E0; Sat,  7 Feb 2009 06:15:43 +1100 (EST)
Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id PycJJP6dv5tAHyj0; Sat, 07 Feb 2009 06:15:43 +1100 (EST)
Received: from [192.168.0.100] (c220-239-214-222.fernt2.vic.optusnet.com.au [220.239.214.222])
	by postoffice.aconex.com (Postfix) with ESMTP id 7851192C0DA;
	Sat,  7 Feb 2009 06:15:43 +1100 (EST)
X-ASG-Orig-Subj: Re: Inode Core Information
Subject: Re: Inode Core Information
From: Nathan Scott <nscott@aconex.com>
To: cyjoyp <cyjoyp@gmail.com>
Cc: xfs@oss.sgi.com
In-Reply-To: <21872592.post@talk.nabble.com>
References: <21872592.post@talk.nabble.com>
Content-Type: text/plain
Date: Sat, 07 Feb 2009 06:12:26 +1100
Message-Id: <1233947546.4556.13.camel@verge.scott.net.au>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-Barracuda-Connect: mail.aconex.com[203.89.202.182]
X-Barracuda-Start-Time: 1233952028
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=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17188
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Fri, 2009-02-06 at 05:41 -0800, cyjoyp wrote:
> Hello Everyone,
>       Could any one help in extracting the modified time information from
> xfs_dinode_core_t   structure (Inode Core)?
>      Please help me.

$ man 2 stat

--
Nathan

From felixb@sgi.com Fri Feb  6 14:31:56 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16KVtki049927
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 14:31:56 -0600
Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10])
	by relay2.corp.sgi.com (Postfix) with ESMTP id 8C5B030418F
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 12:31:15 -0800 (PST)
Received: from eagdhcp-232-197.americas.sgi.com (eagdhcp-232-197.americas.sgi.com [128.162.232.197])
	by estes.americas.sgi.com (Postfix) with ESMTP id 32A8070001C8;
	Fri,  6 Feb 2009 14:31:15 -0600 (CST)
Cc: xfs@oss.sgi.com
Message-Id: <A62D78E5-78C5-4AD2-81E4-7C551DBD7452@sgi.com>
From: Felix Blyakher <felixb@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
In-Reply-To: <20090206071717.GA3295@infradead.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: [PATCH 09/17] xfs: cleanup xfs_find_handle
Date: Fri, 6 Feb 2009 14:31:14 -0600
References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.277472000@bombadil.infradead.org> <F4717E19-7A7F-40CD-BAEB-7AE519E797D0@sgi.com> <20090206071717.GA3295@infradead.org>
X-Mailer: Apple Mail (2.926)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean


On Feb 6, 2009, at 1:17 AM, Christoph Hellwig wrote:

> On Thu, Feb 05, 2009 at 11:20:22PM -0600, Felix Blyakher wrote:
>> Do we want to verify here that cmd is either XFS_IOC_PATH_TO_FSHANDLE
>> or XFS_IOC_PATH_TO_HANDLE ...
>
> It's called in a single place for just these three subcases, so having
> another verification here doesn't seem juseful.

Yes, I know it's called from xfs_file_ioctl() only, and only
with the those three commands, but I prefer the defensive code,
which would flag something unexpected rather then going the
wrong way.
Though, in this case, I'm not too much set on the "defensive"
side :)

Reviewed-by: Felix Blyakher <felixb@sgi.com>

From david@fromorbit.com Fri Feb  6 17:05:48 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n16N5lGi057836
	for <xfs@oss.sgi.com>; Fri, 6 Feb 2009 17:05:48 -0600
X-ASG-Debug-ID: 1233961506-35db00d90000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi
Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1])
	by cuda.sgi.com (Spam Firewall) with ESMTP id 4384818E58E5
	for <xfs@oss.sgi.com>; Fri,  6 Feb 2009 15:05:07 -0800 (PST)
Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id m0TPBhbfvZt8hSIB for <xfs@oss.sgi.com>; Fri, 06 Feb 2009 15:05:07 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEADdQjEl5LClx/2dsb2JhbADPCoQZBg
X-IronPort-AV: E=Sophos;i="4.37,394,1231075800"; 
   d="scan'208";a="284579380"
Received: from ppp121-44-41-113.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.41.113])
  by ipmail01.adl6.internode.on.net with ESMTP; 07 Feb 2009 09:35:04 +1030
Received: from dave by disturbed with local (Exim 4.69)
	(envelope-from <david@fromorbit.com>)
	id 1LVZks-0005Jw-JO; Sat, 07 Feb 2009 10:05:02 +1100
Date: Sat, 7 Feb 2009 10:05:02 +1100
From: Dave Chinner <david@fromorbit.com>
To: Ewan Chalmers <ewan.chalmers@gmail.com>
Cc: xfs@oss.sgi.com
X-ASG-Orig-Subj: Re: Does XFS support the sync mount option?
Subject: Re: Does XFS support the sync mount option?
Message-ID: <20090206230502.GQ24173@disturbed>
Mail-Followup-To: Ewan Chalmers <ewan.chalmers@gmail.com>,
	xfs@oss.sgi.com
References: <884979c90902050643m78d2e0dbt85aa7f4369e243ef@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <884979c90902050643m78d2e0dbt85aa7f4369e243ef@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146]
X-Barracuda-Start-Time: 1233961509
X-Barracuda-Bayes: INNOCENT GLOBAL 0.0082 1.0000 -1.9675
X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com
X-Barracuda-Spam-Score: -1.97
X-Barracuda-Spam-Status: No, SCORE=-1.97 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17197
	Rule breakdown below
	 pts rule name              description
	---- ---------------------- --------------------------------------------------
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com
X-Virus-Status: Clean

On Thu, Feb 05, 2009 at 02:43:29PM +0000, Ewan Chalmers wrote:
> I am interested to know whether XFS supports the sync mount option.

Yes.

> I am using XFS on an external USB disk and automounting using the
> ubuntu/debian usbmount package
> (http://packages.ubuntu.com/intrepid/usbmount). The disk is connected
> to a headless server. I would like to be able to safely switch the
> disk on/off on demand without first logging in to the box to
> sync/unmount. I believe the sync option is essential to this use case.
> Using usbmount, it appears to work correctly, but the output to syslog
> makes me wonder.

You've pulled the plug on the block device, and you wonder why the
filesystem detects an IO error and shutѕ down? XFS is designed to protect
itself when something goes wrong with the underlying device.
Every time you switch off the drive you'll get these errors.

And "sync" only works if you turn drive write caches off or have
barriers enabled. There are many people out there that  have systems
that are suseptible to fatal filesystem corruption that could be
triggered by doing this (because critical metadata is lost from
the volatile write cache on the drive when you power it off).

> The default configuration for usbmount includes
> 
> FILESYSTEMS="ext2 ext3"
> MOUNTOPTIONS="sync,noexec,nodev,noatime"

Oh, that might explain why kerneloops records so many crashes in
ext2/3 from people pulling the plug on USB drives...

> I have added xfs to the FILESYSTEMS list.

Please don't. I don't want to have to deal with all the shutdowns
and corrupted filesystem reports that this will result in.

> On switching off the disk, I see the following output in syslog
>
> kernel: [1034259.923629] usb 1-2: USB disconnect, address 26
> kernel: [1034259.936251] xfs_force_shutdown(sdb1,0x1) called from line
> 420 of file /build/buildd/linux-2.6.27/fs/xfs/xfs_rw.c.  Return
> address = 0xe0a9ddb4
> kernel: [1034259.936334] Filesystem "sdb1": I/O Error Detected.
> Shutting down filesystem: sdb1
....
> But the disk remounts cleanly when it is switched back on.

That doesn't mean it hasn't been corrupted. Only an offline
check/repair will tell you that.

> I would be interested to know whether it is reasonable to use XFS in
> the way I have outlined.

No, it's not really a reasonable way to use any filesystem.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

From brandon@ifup.org Sat Feb  7 03:11:34 2009
X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER
	autolearn=no version=3.3.0-rupdated
Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25])
	by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n179BXvs087669
	for <xfs@oss.sgi.com>; Sat, 7 Feb 2009 03:11:34 -0600
X-ASG-Debug-ID: 1233997854-3a32018a0000-NocioJ
X-Barracuda-URL: http://cuda.sgi.com:80/