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 ; 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 ; 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 ; 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 To: xfs@oss.sgi.com, Nick Piggin 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 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:[] 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] [] ? alloc_vmap_area+0x1b1/0x220 [ 3262.476024] [] ? vm_map_ram+0x382/0x3a0 [ 3262.476024] [] ? kmem_alloc+0x59/0xf0 [ 3262.476024] [] ? _xfs_buf_map_pages+0x89/0xc0 [ 3262.476024] [] ? xfs_buf_get_noaddr+0x137/0x170 [ 3262.476024] [] ? xlog_get_bp+0x4a/0x80 [ 3262.476024] [] ? xlog_write_log_records+0x4b/0x260 [ 3262.476024] [] ? _spin_unlock_irq+0x22/0x30 [ 3262.476024] [] ? xlog_clear_stale_blocks+0xa2/0x180 [ 3262.476024] [] ? xlog_find_tail+0x46c/0x4f0 [ 3262.476024] [] ? xlog_recover+0x14/0xa0 [ 3262.476024] [] ? xfs_log_mount+0xa0/0x180 [ 3262.476024] [] ? xfs_mountfs+0x348/0x6d0 [ 3262.476024] [] ? __debug_object_init+0x229/0x340 [ 3262.476024] [] ? debug_object_init+0x17/0x20 [ 3262.476024] [] ? init_timer+0x10/0x30 [ 3262.476024] [] ? xfs_mru_cache_create+0x114/0x150 [ 3262.476024] [] ? xfs_fs_fill_super+0x1cf/0x310 [ 3262.476024] [] ? get_sb_bdev+0x123/0x150 [ 3262.476024] [] ? alloc_vfsmnt+0x77/0x100 [ 3262.476024] [] ? kstrdup+0x31/0x60 [ 3262.476024] [] ? xfs_fs_get_sb+0x21/0x30 [ 3262.476024] [] ? xfs_fs_fill_super+0x0/0x310 [ 3262.476024] [] ? vfs_kern_mount+0x3a/0xa0 [ 3262.476024] [] ? do_kern_mount+0x39/0xe0 [ 3262.476024] [] ? do_mount+0x3ab/0x780 [ 3262.476024] [] ? _raw_spin_lock+0x41/0x120 [ 3262.476024] [] ? copy_mount_options+0x3c/0x130 [ 3262.476024] [] ? sys_mount+0x89/0xc0 [ 3262.476024] [] ? syscall_call+0x7/0xb [ 3262.476024] [] ? 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Arnd Bergmann CC: Andrew Morton , Ankit Jain , 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 ; 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 Sender: geert@linux-m68k.org To: Boaz Harrosh cc: Arnd Bergmann , Andrew Morton , Ankit Jain , 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: 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Arnd Bergmann , Andrew Morton , Ankit Jain , 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> In-Reply-To: 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 ; 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 Sender: geert@linux-m68k.org To: Boaz Harrosh cc: Arnd Bergmann , Andrew Morton , Ankit Jain , 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: 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> <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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Arnd Bergmann , Andrew Morton , Ankit Jain , 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> <49857BEB.30404@panasas.com> In-Reply-To: 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Boaz Harrosh CC: Geert Uytterhoeven , Arnd Bergmann , 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 , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <49857BEB.30404@panasas.com> <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 ; 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 ; 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 ; 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 To: xfs@oss.sgi.com, Nick Piggin 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 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Eric Sandeen CC: Geert Uytterhoeven , Arnd Bergmann , 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 , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <49857BEB.30404@panasas.com> <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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Boaz Harrosh CC: Geert Uytterhoeven , Arnd Bergmann , 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 , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <49857BEB.30404@panasas.com> <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 ; 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 To: Eric Sandeen Cc: Boaz Harrosh , Geert Uytterhoeven , Arnd Bergmann , 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 , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <49857BEB.30404@panasas.com> <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 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Christoph Hellwig CC: Eric Sandeen , Geert Uytterhoeven , Arnd Bergmann , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <49857BEB.30404@panasas.com> <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 ; 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 ; 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 ; Sun, 01 Feb 2009 13:27:31 -0800 (PST) Received: from arekm by carme.pld-linux.org with local (Exim 4.69) (envelope-from ) id 1LTjqk-000qqc-8f; Sun, 01 Feb 2009 22:27:30 +0100 From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= To: xfs@oss.sgi.com Cc: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= 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 --- 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =?UTF-8?B?QXJrYWRpdXN6IE1pxZtraWV3aWN6?= 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 > --- > 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 ; 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 To: Boaz Harrosh 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 , Eric Sandeen , Geert Uytterhoeven , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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 ; 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 ; 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 ; 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 ) id 1LTo1f-0001jW-0u; Mon, 02 Feb 2009 12:55:03 +1100 Date: Mon, 2 Feb 2009 12:55:02 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, Nick Piggin 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 , xfs@oss.sgi.com, Nick Piggin 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 --- 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Arnd Bergmann CC: Christoph Hellwig , Eric Sandeen , Geert Uytterhoeven , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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 ; 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 Sender: geert@linux-m68k.org To: Boaz Harrosh cc: Arnd Bergmann , Christoph Hellwig , Eric Sandeen , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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: 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 ; 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 ; 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 ; 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 ) 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 ) id 1LTumi-00007w-77; Mon, 02 Feb 2009 10:08:04 +0100 From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= To: xfs@oss.sgi.com Cc: root 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 Pass *FLAGS in some targets. Drop LIBHANDLE, LIBATTR and LIBACL from deps since there are in form "-llibrary". Signed-off-by: root --- 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 ; 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 ; 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 ; 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 ) 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 ) id 1LTuoC-00009a-TS; Mon, 02 Feb 2009 10:09:36 +0100 From: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= To: xfs@oss.sgi.com Cc: =?utf-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= 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 --- 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Arnd Bergmann , Christoph Hellwig , Eric Sandeen , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> In-Reply-To: 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 ; 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 ; 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 ; 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 X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner cc: Christoph Hellwig , 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: References: <20090113214949.GN8071@disturbed> <20090118173144.GA1999@infradead.org> <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <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 --- 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: =?UTF-8?B?QXJrYWRpdXN6IE1pxZtraWV3aWN6?= 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 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 ; 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 ) id 1LU5l0-0000F6-HP; Mon, 02 Feb 2009 20:51:02 +0000 Date: Mon, 2 Feb 2009 20:51:02 +0000 From: Jamie Lokier To: Boaz Harrosh Cc: Geert Uytterhoeven , Arnd Bergmann , Christoph Hellwig , Eric Sandeen , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <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 ; 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 ; 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 ; 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 ; 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 ; Tue, 3 Feb 2009 02:22:48 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 ) id 1LUBwq-0007yL-SQ; Tue, 03 Feb 2009 14:27:40 +1100 Date: Tue, 3 Feb 2009 14:27:40 +1100 From: Dave Chinner To: Mikulas Patocka Cc: Christoph Hellwig , 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 , Christoph Hellwig , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20090118173144.GA1999@infradead.org> <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <20090131235725.GA24173@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 ..... > @@ -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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Michael Monnerie 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 Reply-To: TANIGUCHI Takaki , 513821@bugs.debian.org To: Debian Bug Tracking System 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 (no description available) pn dvhtool (no description available) pn quota (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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 To: Nathan Scott 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 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 ; 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 User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Jamie Lokier CC: Geert Uytterhoeven , Arnd Bergmann , Christoph Hellwig , Eric Sandeen , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <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 ; 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 ; 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 ; 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 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 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 ; 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 ; 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 ; 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 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 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 3 Feb 2009 10:22:38 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 3 Feb 2009 10:24:53 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 To: Michael Monnerie 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 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 ; 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 ; 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 ; 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 To: Michael Monnerie 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 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 3 Feb 2009 11:40:08 +0100 (CET) From: Michael Monnerie 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 ; 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 ) id 1LUJKz-0003Mu-81; Tue, 03 Feb 2009 11:21:05 +0000 Date: Tue, 3 Feb 2009 11:21:05 +0000 From: Jamie Lokier To: Boaz Harrosh Cc: Geert Uytterhoeven , Arnd Bergmann , Christoph Hellwig , Eric Sandeen , mfasheh@suse.com, joel.becker@oracle.com, linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, Ankit Jain , linux-fsdevel@vger.kernel.org, Andrew Morton , 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> <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 ; 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 ; 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 ; 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 To: Michael Monnerie 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 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 ; 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 ; 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 ; 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 To: xfs@oss.sgi.com, Nick Piggin 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 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 ; 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 ; 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 ; 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 To: Nick Piggin Cc: Christoph Hellwig , 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 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 ; 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 ; 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 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 Tested-by: Eric Sesterhenn Reviewed-by: Christoph Hellwig Reviewed-by: Felix Blyakher Signed-off-by: Dave Chinner Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- 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 ; 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 ; 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 ; 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 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 Tested-by: Eric Sesterhenn Reviewed-by: Christoph Hellwig Reviewed-by: Felix Blyakher Signed-off-by: Dave Chinner Signed-off-by: Felix Blyakher ----------------------------------------------------------------------- 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 ; 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 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 Reviewed-by: Christoph Hellwig ----------------------------------------------------------------------- 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 ; 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 ; 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 ; 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 ; 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 To: Nick Piggin Cc: Christoph Hellwig , 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 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 ; 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 ; 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 ; 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 ; 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 X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner cc: Christoph Hellwig , 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: References: <20090118173144.GA1999@infradead.org> <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <20090131235725.GA24173@disturbed> <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 > ..... > > @@ -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 ; 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 ; 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 ; 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 To: Nick Piggin 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 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Dave Chinner , xfs mailing list 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] [] ? trace_hardirqs_on+0xb/0xd >>>> [ 235.251037] [] ? vm_map_ram+0x36e/0x38a >>>> [ 235.251037] [] ? _xfs_buf_map_pages+0x42/0x6d >>>> [ 235.251037] [] ? xfs_buf_get_noaddr+0xbc/0x11f >>>> [ 235.251037] [] ? xlog_get_bp+0x5a/0x5d >>>> [ 235.251037] [] ? xlog_find_verify_log_record+0x26/0x208 >>>> [ 235.251037] [] ? xlog_find_zeroed+0x1d6/0x214 >>>> [ 235.251037] [] ? 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 ; 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 ; 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 ; 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 ) id 1LUT2b-0005cX-Bx; Wed, 04 Feb 2009 08:42:45 +1100 Date: Wed, 4 Feb 2009 08:42:45 +1100 From: Dave Chinner To: Christoph Hellwig Cc: Nick Piggin , 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 , Nick Piggin , 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 ; 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 ; 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 ; 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 To: Christoph Hellwig , Nick Piggin , 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 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 ; 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 ; 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 ; 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 To: Christoph Hellwig , Nick Piggin , 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 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 ; 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 ; 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 ; 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 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] [] xfs_error_report+0x43/0x50 [xfs] [822153.422956] [] ? xfs_da_read_buf+0x2a/0x30 [xfs] [822153.422976] [] xfs_corruption_error+0x5d/0x80 [xfs] [822153.422995] [] xfs_da_do_buf+0x6a8/0x700 [xfs] [822153.423014] [] ? xfs_da_read_buf+0x2a/0x30 [xfs] [822153.423019] [] ? mntput_no_expire+0x36/0x160 [822153.423022] [] ? aa_permission+0x21/0xd0 [822153.423041] [] xfs_da_read_buf+0x2a/0x30 [xfs] [822153.423061] [] ? xfs_dir2_block_getdents+0x9a/ 0x210 [xfs] [822153.423080] [] xfs_dir2_block_getdents+0x9a/ 0x210 [xfs] [822153.423099] [] ? xfs_bmap_last_offset+0x13b/ 0x150 [xfs] [822153.423119] [] ? xfs_hack_filldir+0x0/0x60 [xfs] [822153.423138] [] ? xfs_hack_filldir+0x0/0x60 [xfs] [822153.423157] [] xfs_readdir+0x9b/0xf0 [xfs] [822153.423176] [] xfs_file_readdir+0xd6/0x1a0 [xfs] [822153.423180] [] ? filldir+0x0/0xe0 [822153.423183] [] ? aa_file_permission+0x21/0xf0 [822153.423185] [] ? filldir+0x0/0xe0 [822153.423188] [] ? filldir+0x0/0xe0 [822153.423191] [] vfs_readdir+0xbb/0xe0 [822153.423194] [] sys_getdents+0x88/0xe0 [822153.423199] [] 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: George Barnett 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] [] xfs_error_report+0x43/0x50 [xfs] > [822153.422956] [] ? xfs_da_read_buf+0x2a/0x30 [xfs] > [822153.422976] [] xfs_corruption_error+0x5d/0x80 > [xfs] > [822153.422995] [] xfs_da_do_buf+0x6a8/0x700 [xfs] > [822153.423014] [] ? xfs_da_read_buf+0x2a/0x30 [xfs] > [822153.423019] [] ? mntput_no_expire+0x36/0x160 > [822153.423022] [] ? aa_permission+0x21/0xd0 > [822153.423041] [] xfs_da_read_buf+0x2a/0x30 [xfs] > [822153.423061] [] ? xfs_dir2_block_getdents+0x9a/ > 0x210 [xfs] > [822153.423080] [] xfs_dir2_block_getdents+0x9a/ > 0x210 [xfs] > [822153.423099] [] ? xfs_bmap_last_offset+0x13b/ > 0x150 [xfs] > [822153.423119] [] ? xfs_hack_filldir+0x0/0x60 [xfs] > [822153.423138] [] ? xfs_hack_filldir+0x0/0x60 [xfs] > [822153.423157] [] xfs_readdir+0x9b/0xf0 [xfs] > [822153.423176] [] xfs_file_readdir+0xd6/0x1a0 [xfs] > [822153.423180] [] ? filldir+0x0/0xe0 > [822153.423183] [] ? aa_file_permission+0x21/0xf0 > [822153.423185] [] ? filldir+0x0/0xe0 > [822153.423188] [] ? filldir+0x0/0xe0 > [822153.423191] [] vfs_readdir+0xbb/0xe0 > [822153.423194] [] sys_getdents+0x88/0xe0 > [822153.423199] [] 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 ; 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 ; 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 ; 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 To: Eric Sandeen 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: George Barnett 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 ; 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 ; 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 ; 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 To: Eric Sandeen 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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: George Barnett 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 ; 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 ; 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 ; 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 To: Nick Piggin Cc: Christoph Hellwig , 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 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] [] ? printk+0x18/0x1a [ 4910.091954] [] warn_slowpath+0x73/0xd0 [ 4910.103164] [] ? __rmqueue_smallest+0xf0/0x170 [ 4910.124547] [] ? alloc_vmap_area+0x6a/0x240 [ 4910.139940] [] ? kvm_set_pte_at+0x45/0x50 [ 4910.161273] [] vmap_page_range+0x159/0x1b0 [ 4910.172548] [] vm_map_ram+0x2e1/0x3a0 [ 4910.193782] [] ? kmem_alloc+0x59/0xf0 [ 4910.204960] [] _xfs_buf_map_pages+0x89/0xc0 [ 4910.216249] [] xfs_buf_get_noaddr+0x137/0x170 [ 4910.237660] [] xlog_get_bp+0x2e/0xd0 [ 4910.248825] [] xlog_write_log_records+0x4b/0x260 [ 4910.270258] [] ? _spin_unlock_irq+0x22/0x30 [ 4910.282965] [] xlog_clear_stale_blocks+0xa2/0x180 [ 4910.304712] [] xlog_find_tail+0x46c/0x4f0 [ 4910.326012] [] xlog_recover+0x14/0xa0 [ 4910.341291] [] xfs_log_mount+0xa0/0x180 [ 4910.352791] [] xfs_mountfs+0x348/0x6d0 [ 4910.374052] [] ? __debug_object_init+0x229/0x340 [ 4910.385427] [] ? debug_object_init+0x17/0x20 [ 4910.406761] [] ? init_timer+0x10/0x30 [ 4910.422081] [] ? xfs_mru_cache_create+0x114/0x150 [ 4910.443597] [] xfs_fs_fill_super+0x1cf/0x310 [ 4910.464931] [] get_sb_bdev+0x123/0x150 [ 4910.476212] [] ? alloc_vfsmnt+0x77/0x100 [ 4910.487458] [] ? kstrdup+0x31/0x60 [ 4910.508628] [] xfs_fs_get_sb+0x21/0x30 [ 4910.520744] [] ? xfs_fs_fill_super+0x0/0x310 [ 4910.542092] [] vfs_kern_mount+0x3a/0xa0 [ 4910.553307] [] do_kern_mount+0x39/0xe0 [ 4910.564518] [] do_mount+0x3ab/0x780 [ 4910.585736] [] ? _raw_spin_lock+0x41/0x120 [ 4910.597002] [] ? copy_mount_options+0x3c/0x130 [ 4910.621489] [] sys_mount+0x89/0xc0 [ 4910.632621] [] syscall_call+0x7/0xb [ 4910.643772] [] ? 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 ; 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 ; 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 ; 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 To: Jan Engelhardt 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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 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 ; 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 ; 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 ; 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 To: Nick Piggin Cc: Christoph Hellwig , 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 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= 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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 09:52:45 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 Sender: jengelh@sovereign.computergmbh.de To: Christoph Hellwig 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: References: <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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 11:27:47 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 ) id 1LUgYm-0006tH-Kb; Wed, 04 Feb 2009 23:08:52 +1100 Date: Wed, 4 Feb 2009 23:08:52 +1100 From: Dave Chinner To: Mikulas Patocka Cc: Christoph Hellwig , 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 , Christoph Hellwig , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <20090131235725.GA24173@disturbed> <20090203032740.GG24173@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 . --- 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 ; 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 ; 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 ; 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 ) id 1LUgm9-0007GA-Ic; Wed, 04 Feb 2009 23:22:41 +1100 Date: Wed, 4 Feb 2009 23:22:41 +1100 From: Dave Chinner To: Michael Monnerie 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 , 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 ; 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 ; 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 ; 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 ) id 1LUgpl-0007Ko-Mc; Wed, 04 Feb 2009 23:26:25 +1100 Date: Wed, 4 Feb 2009 23:26:25 +1100 From: Dave Chinner To: Michael Monnerie 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 , 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 ; 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 ; 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 ; 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 To: Dave Chinner Cc: Michael Monnerie , 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 =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 wb|wt ; 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 ; 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 ; 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 To: Emmanuel Florac Cc: Dave Chinner , Michael Monnerie , 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 , Dave Chinner , Michael Monnerie , 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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 16:03:22 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 To: KELEMEN Peter Cc: Dave Chinner , Michael Monnerie , 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 =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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 16:24:32 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 16:25:42 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 To: Emmanuel Florac Cc: Dave Chinner , Michael Monnerie , 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 , Dave Chinner , Michael Monnerie , 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 ; 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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 17:01:04 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 To: KELEMEN Peter Cc: Dave Chinner , Michael Monnerie , 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 =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 ; 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 ; 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 ; 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 ; Wed, 4 Feb 2009 17:28:05 +0100 (CET) Message-Id: <4D4B8415-C82D-4A23-9A08-F06A67DC92BA@hal-9k.de> From: Julian Einwag 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: <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 ; 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 ; 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 ; 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 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 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 ; 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 ; 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 ; 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 To: Nick Piggin 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 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 ; 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 ; 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 ; 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 To: Jan Engelhardt Cc: Christoph Hellwig , 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: <20090204082816.GA9111@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 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 ; 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 Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Hesterberg CC: Marizol Martinez , Eric Sandeen , Ric Wheeler , SGI Engineering Interfaces to Red Hat , Gary Hagensen , George Beshers , Tony Ernst , xfs-dev , xfs-oss 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 > 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 ; 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 ; 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 ; Wed, 4 Feb 2009 18:19:51 -0600 (CST) Message-Id: <86FA5963-93E1-4BB6-ACC1-70D1628CB926@sgi.com> From: Felix Blyakher 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 ; 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 ; 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 ; Wed, 4 Feb 2009 18:21:05 -0600 (CST) Message-Id: <400220E1-CB3D-4CD3-B094-176629B246B5@sgi.com> From: Felix Blyakher 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 ; 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 ; 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 ; Wed, 4 Feb 2009 18:21:25 -0600 (CST) Message-Id: <4E94A3D9-F39D-4FB2-93B8-B31E403446F3@sgi.com> From: Felix Blyakher 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 ; 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 ; 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 ; 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 X-X-Sender: mpatocka@hs20-bc2-1.build.redhat.com To: Dave Chinner cc: Christoph Hellwig , 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: References: <20090120232422.GF10158@disturbed> <20090122205913.GA30859@infradead.org> <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <20090131235725.GA24173@disturbed> <20090203032740.GG24173@disturbed> <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 . > > --- > 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 ; 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 ; 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 ; 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 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:[] [] __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: [] complete+0x38/0x4c Feb 5 03:00:20 up kernel: [] xfs_iflush+0x7a/0x2b2 [xfs] Feb 5 03:00:20 up kernel: [] ? default_spin_lock_flags+0x17/0x1b Feb 5 03:00:20 up kernel: [] xfs_finish_reclaim+0x136/0x175 [xfs] Feb 5 03:00:20 up kernel: [] xfs_finish_reclaim_all+0x98/0xd4 [xfs] Feb 5 03:00:20 up kernel: [] xfs_syncsub+0x55/0x22f [xfs] Feb 5 03:00:20 up kernel: [] xfs_sync+0x42/0x47 [xfs] Feb 5 03:00:20 up kernel: [] xfs_sync_worker+0x1f/0x41 [xfs] Feb 5 03:00:20 up kernel: [] xfssyncd+0x15d/0x1ac [xfs] Feb 5 03:00:20 up kernel: [] ? xfssyncd+0x0/0x1ac [xfs] Feb 5 03:00:20 up kernel: [] kthread+0x49/0x76 Feb 5 03:00:20 up kernel: [] child_rip+0xa/0x11 Feb 5 03:00:20 up kernel: [] ? kthread+0x0/0x76 Feb 5 03:00:20 up kernel: [] ? 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 [] __wake_up_common+0x29/0x76 Feb 5 03:00:20 up kernel: RSP 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> [] complete+0x38/0x4b > > <4> [] xfs_iflush+0x73/0x2ab [xfs] > > <4> [] xfs_finish_reclaim+0x12a/0x168 [xfs] > > <4> [] xfs_finish_reclaim_all+0x91/0xcb [xfs] > > <4> [] xfs_syncsub+0x50/0x22b [xfs] > > <4> [] xfs_sync_worker+0x17/0x36 [xfs] > > <4> [] xfssyncd+0x15d/0x1ac [xfs] > > <4> [] kthread+0x47/0x73 > > <4> [] 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 ; 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 ; 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 ; 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 ) id 1LUytt-0006X0-Gq; Thu, 05 Feb 2009 18:43:53 +1100 Date: Thu, 5 Feb 2009 18:43:53 +1100 From: Dave Chinner To: Mikulas Patocka Cc: Christoph Hellwig , 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 , Christoph Hellwig , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20090122224347.GA18751@infradead.org> <20090124071249.GF32390@disturbed> <20090131235725.GA24173@disturbed> <20090203032740.GG24173@disturbed> <20090204120852.GK24173@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 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 ; 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 ; 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 ; 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 ; 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 ; Thu, 5 Feb 2009 09:22:18 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 ) id 1LUzjI-0007cb-7c; Thu, 05 Feb 2009 19:37:00 +1100 Date: Thu, 5 Feb 2009 19:37:00 +1100 From: Dave Chinner To: Michael Monnerie 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 , 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 ; 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 ; 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 ; 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 ; 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 ; Thu, 5 Feb 2009 10:19:24 +0100 (CET) From: Michael Monnerie 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 ; 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 ; 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 ; 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 To: Felix Blyakher 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 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 ; 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 To: Mark Goodwin Cc: John Hesterberg , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Tony Ernst , George Beshers , xfs-oss , xfs-dev , Gary Hagensen , Ric Wheeler 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 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 ; 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 ; 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 ; 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 To: Michael Monnerie 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 =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 ; 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 ; 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 ; Thu, 05 Feb 2009 04:57:22 -0800 (PST) Received: by yw-out-1718.google.com with SMTP id 5so67314ywm.32 for ; 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: X-ASG-Orig-Subj: xfs_db guide Subject: xfs_db guide From: Aditya Alate 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,
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-- 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 ; 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 ; 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 ; Thu, 05 Feb 2009 06:50:52 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id e30so306350fke.4 for ; 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 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 ; 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 To: xfs@sgi.com Cc: Felix Blyakher 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 --- 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: markgw@sgi.com CC: John Hesterberg , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Tony Ernst , George Beshers , xfs-oss , xfs-dev , Gary Hagensen , Ric Wheeler 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 ; 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 ; 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 ; Thu, 05 Feb 2009 18:11:39 -0800 (PST) Received: from PBP-04 (208.89.23.69) by evempbp04.workforpbp.com id hhee8o0ktasf for ; Thu, 5 Feb 2009 21:12:26 -0500 (envelope-from ) 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" 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 ; 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: Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: Felix Blyakher Subject: Re: [PATCH 09/17] xfs: cleanup xfs_find_handle Date: Thu, 5 Feb 2009 23:20:22 -0600 To: Christoph Hellwig 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 > > 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 ; 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 To: Felix Blyakher Cc: Christoph Hellwig , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 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 ; 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 ; 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 ; 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 ) 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 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 ; 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 ; 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 ; 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 Reply-To: Steffen.Knauf@liga01.de User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christoph Hellwig 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 ; 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 ; 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 ; 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 ; 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" To: "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
 
Hello,
 
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?
 
Where I can find documentation (user guide and administrative guide) f= or XFS?
Thanks,
 
Ahmed
 
 
 
 --_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 ; 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 ; 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 ; 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 User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Ezzat, Ahmed" CC: "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 ; 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 ; 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 ; 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 To: cyjoyp 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 ; 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 ; 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: From: Felix Blyakher To: Christoph Hellwig 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> <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 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 ; 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 ; 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 ; 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 ) id 1LVZks-0005Jw-JO; Sat, 07 Feb 2009 10:05:02 +1100 Date: Sat, 7 Feb 2009 10:05:02 +1100 From: Dave Chinner To: Ewan Chalmers 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 , 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 ; Sat, 7 Feb 2009 03:11:34 -0600 X-ASG-Debug-ID: 1233997854-3a32018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4BE91F7E6C for ; Sat, 7 Feb 2009 01:10:54 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by cuda.sgi.com with ESMTP id REOi3hlxjJlmGZrI for ; Sat, 07 Feb 2009 01:10:54 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so612863waf.4 for ; Sat, 07 Feb 2009 01:10:54 -0800 (PST) Received: by 10.114.137.2 with SMTP id k2mr1875704wad.130.1233997854335; Sat, 07 Feb 2009 01:10:54 -0800 (PST) Received: from localhost (c-76-105-255-252.hsd1.or.comcast.net [76.105.255.252]) by mx.google.com with ESMTPS id n20sm5500727pof.3.2009.02.07.01.10.53 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Feb 2009 01:10:53 -0800 (PST) Date: Sat, 7 Feb 2009 01:10:33 -0800 From: Brandon Philips To: Christoph Hellwig , Andreas =?iso-8859-1?Q?Gr=FCnbacher?= Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Message-ID: <20090207091033.GO29636@jenkins.ifup.org> References: <20090108021947.404730068@ifup.org> <20090108154453.GA5017@infradead.org> <20090108165820.GA3832@jenkins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090108165820.GA3832@jenkins> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.179] X-Barracuda-Start-Time: 1233997855 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0005 1.0000 -2.0178 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.17238 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 08:58 Thu 08 Jan 2009, Brandon Philips wrote: > On 10:44 Thu 08 Jan 2009, Christoph Hellwig wrote: > > On Wed, Jan 07, 2009 at 06:19:47PM -0800, brandon@ifup.org wrote: > > > NOTE: Timothy Shimmin's email (tes@sgi.com) seems to be gone. Who should > > > I send patches like this to in the future? > > > > That's not quite sorted out. For now send them to Andreas Gruenbacher > > and the xfs list. > > Ok, thanks. > > Andreas, please review these patches if you can: > http://oss.sgi.com/archives/xfs/2009-01/msg00136.html > http://oss.sgi.com/archives/xfs/2009-01/msg00146.html I noticed that Christoph put acl-dev.git and attr-dev.git on git.kernel.org. Great news! The process with CVS and TAKEs was a bit confusing. But, can I suggest that we merge the attr-dev and acl-dev tree into one git repo and share libmisc? I have done it over here: http://ifup.org/git/?p=acl-attr-dev.git;a=summary git clone git://ifup.org/philips/acl-attr-dev.git What do you think? Also, my test/ patchset hasn't gotten any feedback. I will merge them into either {acl,attr}-dev.git or my acl-attr-dev.git if they seem acceptable and send you a pull request. http://oss.sgi.com/pipermail/xfs/2009-January/039600.html http://oss.sgi.com/pipermail/xfs/2009-January/039610.html Cheers, Brandon From fbolm@bellnet.ca Sat Feb 7 04:40:18 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 (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n17AeGQS092319 for ; Sat, 7 Feb 2009 04:40:17 -0600 X-ASG-Debug-ID: 1234003178-4f5902870000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from simmts8-srv.bellnexxia.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69EBD18E883C for ; Sat, 7 Feb 2009 02:39:38 -0800 (PST) Received: from simmts8-srv.bellnexxia.net (simmts8-qfe0.srvr.bell.ca [206.47.199.166]) by cuda.sgi.com with ESMTP id IN3x0rS8A5l4Z9k6 for ; Sat, 07 Feb 2009 02:39:38 -0800 (PST) Received: from simip9-ac.srvr.bell.ca ([206.47.199.87]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20090207103714.BDOH1679.simmts7-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> for ; Sat, 7 Feb 2009 05:37:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUSAMPwjEnOL8eg/2dsb2JhbACBbokogX0ytGyPewY Received: from simfep5.srvr.bell.ca (HELO smtpacout.sympatico.ca) ([206.47.199.160]) by simip9-ac.srvr.bell.ca with SMTP; 07 Feb 2009 05:44:45 -0500 X-Mailer: Openwave WebEngine, version 2.8.10 (webedge20-101-191-20030113) X-Originating-IP: [201.17.6.199] From: Jason Miller Corporations Reply-To: jasonmcop@ymail.com To: X-ASG-Orig-Subj: Loan Application Subject: Loan Application Date: Sat, 7 Feb 2009 5:37:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20090207103714.BDOH1679.simmts7-srv.bellnexxia.net@simip9-ac.srvr.bell.ca> X-Barracuda-Connect: simmts8-qfe0.srvr.bell.ca[206.47.199.166] X-Barracuda-Start-Time: 1234003179 X-Barracuda-Bayes: INNOCENT GLOBAL 0.7578 1.0000 1.8400 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.17244 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 We give loan at 0.3%,Any interested person,Contact us now Viajasonmcop@ymail.com with details:Names:Address,Amount Required,Duration Of Loan. Regards, Jason Miller Corporations From alessandro.bono@gmail.com Sat Feb 7 07:07:07 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=BAYES_50,J_CHICKENPOX_13, J_CHICKENPOX_14,J_CHICKENPOX_33,J_CHICKENPOX_52,J_CHICKENPOX_53, J_CHICKENPOX_61,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 n17D76OK100394 for ; Sat, 7 Feb 2009 07:07:07 -0600 X-ASG-Debug-ID: 1234011983-71a9016c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f13.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2547FF7DE0 for ; Sat, 7 Feb 2009 05:06:23 -0800 (PST) Received: from mail-fx0-f13.google.com (mail-fx0-f13.google.com [209.85.220.13]) by cuda.sgi.com with ESMTP id ysiyiNzi0X8znB00 for ; Sat, 07 Feb 2009 05:06:23 -0800 (PST) Received: by fxm6 with SMTP id 6so10463fxm.20 for ; Sat, 07 Feb 2009 05:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=/KVEJ/luy9UlrER8DhocBGPPb3V+y/Gm+txDKc2wU1Q=; b=t+soRqSlrUP6WVjLcJTvVyKg43QbsSn5Kz3tvvphAEGm7wzQYQjgjEAhluDhEx6/mQ G/iT0MUvbIH+iIgf7nJPEE2sULZ2FcaBfizE0Fjn7lxWpZVOhT3iZ+LmJxdWwrN1Ucxv XudgtL/axIxkcxRdo2CmoCr2fWwRGiDOtl/SY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=STBI2wUPy3Sb5ziykbSSpd4msDz5sY4pMk3e5gk2RPXcqEbSzh7n9af0iBdgZeiJd0 T69w/B9QHGX2j0biTu1jiDGoVABNAJ/H0f1u7dOnH9ru10kBRRL6JczEpawU/mGPexGF PhghHrEPgr00MaW+MT6Fq4hdtVwes96wxth3s= Received: by 10.103.138.16 with SMTP id q16mr1223709mun.114.1234011982290; Sat, 07 Feb 2009 05:06:22 -0800 (PST) Received: from ?10.151.1.19? (host-62-10-44-87.cust-adsl.tiscali.it [62.10.44.87]) by mx.google.com with ESMTPS id j10sm1530885muh.31.2009.02.07.05.06.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 07 Feb 2009 05:06:20 -0800 (PST) X-ASG-Orig-Subj: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: linux-kernel , linux-xfs Content-Type: multipart/mixed; boundary="=-6a4h5iZZAGcv53WKxFWU" Date: Sat, 07 Feb 2009 14:06:13 +0100 Message-Id: <1234011974.7435.11.camel@champagne.cantina> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 X-Barracuda-Connect: mail-fx0-f13.google.com[209.85.220.13] X-Barracuda-Start-Time: 1234011985 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: -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.17254 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 --=-6a4h5iZZAGcv53WKxFWU Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi all This time I hit kernel bug without any particular operation, normal browsing, mail, news, etc tell me if you need info asap because I want to reformat this machine and switch back to ext3. xfs seems really unstable in this particular machine and after this crash I lose again configuration file of opened program at crash time Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut here ]------------ Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at fs/buffer.c:470! Feb 7 12:43:12 champagne kernel: [ 5828.167051] invalid opcode: 0000 [#1] SMP Feb 7 12:43:12 champagne kernel: [ 5828.167056] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map Feb 7 12:43:12 champagne kernel: [ 5828.167059] CPU 1 Feb 7 12:43:12 champagne kernel: [ 5828.167062] Modules linked in: af_packet binfmt_misc rfcomm bridge stp llc bnep sco l2cap acpi_cpufreq cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative sbs sbshc pci_slot ipt_LOG xt_limit ipt_addrtype xt_state xt_tcpudp xt_conntrack ip6table_filter ip6_tables ipv6 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables ext3 jbd mbcache hp_wmi coretemp sbp2 loop arc4 ecb iwlagn pcmcia iwlcore lis3lv02d snd_seq_dummy snd_hda_intel leds_hp_disk snd_seq_oss rfkill btusb snd_pcm_oss snd_mixer_oss sdhci_pci sdhci parport_pc parport snd_seq_midi mac80211 led_class mmc_core ricoh_mmc tpm_infineon tpm tpm_bios yenta_socket rsrc_nonstatic pcmcia_core video output container bluetooth cfg80211 wmi battery ac button pcspkr psmouse evdev serio_raw snd_pcm snd_page_alloc snd_hwdep iTCO_wdt iTCO_vendor_support snd_rawmidi snd_seq_midi_event snd_seq snd_timer Feb 7 12:43:12 champagne kernel: nd_seq_device snd soundcore dm_multipath xfs sr_mod cdrom sg sd_mod crc_t10dif ata_piix ahci libata scsi_mod ohci1394 ieee1394 uhci_hcd ehci_hcd usbcore e1000e dm_crypt dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processor fan thermal_sys hwmon fuse Feb 7 12:43:12 champagne kernel: [ 5828.167195] Pid: 2483, comm: xfsdatad/1 Not tainted 2.6.28.4 #1 Feb 7 12:43:12 champagne kernel: [ 5828.167199] RIP: 0010:[] [] end_buffer_async_write +0x8f/0x12c Feb 7 12:43:12 champagne kernel: [ 5828.167210] RSP: 0018:ffff880138b0be40 EFLAGS: 00010246 Feb 7 12:43:12 champagne kernel: [ 5828.167213] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 000000000000000b Feb 7 12:43:12 champagne kernel: [ 5828.167217] RDX: 0000000000000000 RSI: ffffe2000066dc44 RDI: 0000000000000040 Feb 7 12:43:12 champagne kernel: [ 5828.167220] RBP: ffff8800343e7930 R08: 1000000000000000 R09: ffff8800b6da6602 Feb 7 12:43:12 champagne kernel: [ 5828.167224] R10: ffff88008d0bbd60 R11: ffff880138b0bdd0 R12: ffff88013950cd88 Feb 7 12:43:12 champagne kernel: [ 5828.167227] R13: ffff88013b85fee0 R14: ffffe2000066dc44 R15: 0000000000000001 Feb 7 12:43:12 champagne kernel: [ 5828.167232] FS: 0000000000000000(0000) GS:ffff88013b803a00(0000) knlGS:0000000000000000 Feb 7 12:43:12 champagne kernel: [ 5828.167235] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Feb 7 12:43:12 champagne kernel: [ 5828.167239] CR2: 00007f19ff420000 CR3: 000000008d10b000 CR4: 00000000000006e0 Feb 7 12:43:12 champagne kernel: [ 5828.167243] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Feb 7 12:43:12 champagne kernel: [ 5828.167246] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Feb 7 12:43:12 champagne kernel: [ 5828.167250] Process xfsdatad/1 (pid: 2483, threadinfo ffff880138b0a000, task ffff880139ef5340) Feb 7 12:43:12 champagne kernel: [ 5828.167253] Stack: Feb 7 12:43:12 champagne kernel: [ 5828.167256] ffff880138b0be50 ffffffff8022806f 0000000000000286 ffffffff8030be35 Feb 7 12:43:12 champagne kernel: [ 5828.167261] ffff8800343e78c0 ffff8800b6da6660 ffff88013950cd88 ffff88013b85fee0 Feb 7 12:43:12 champagne kernel: [ 5828.167267] ffff88013b85ff00 ffffffffa01c2269 ffffffffa01c23db ffff88013950cd80 Feb 7 12:43:12 champagne kernel: [ 5828.167274] Call Trace: Feb 7 12:43:12 champagne kernel: [ 5828.167277] [] ? need_resched+0x1e/0x28 Feb 7 12:43:12 champagne kernel: [ 5828.167284] [] ? __up_write+0x12/0x45 Feb 7 12:43:12 champagne kernel: [ 5828.167293] [] ? xfs_destroy_ioend+0x23/0x71 [xfs] Feb 7 12:43:12 champagne kernel: [ 5828.167334] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] Feb 7 12:43:12 champagne kernel: [ 5828.167369] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] Feb 7 12:43:12 champagne kernel: [ 5828.167402] [] ? run_workqueue+0x79/0xfe Feb 7 12:43:12 champagne kernel: [ 5828.167408] [] ? worker_thread+0xf0/0x102 Feb 7 12:43:12 champagne kernel: [ 5828.167413] [] ? autoremove_wake_function+0x0/0x2e Feb 7 12:43:12 champagne kernel: [ 5828.167419] [] ? worker_thread+0x0/0x102 Feb 7 12:43:12 champagne kernel: [ 5828.167424] [] ? kthread+0x47/0x73 Feb 7 12:43:12 champagne kernel: [ 5828.167429] [] ? schedule_tail+0x27/0x60 Feb 7 12:43:12 champagne kernel: [ 5828.167435] [] ? child_rip+0xa/0x11 Feb 7 12:43:12 champagne kernel: [ 5828.167441] [] ? kthread+0x0/0x73 Feb 7 12:43:12 champagne kernel: [ 5828.167446] [] ? child_rip+0x0/0x11 Feb 7 12:43:12 champagne kernel: [ 5828.167450] Code: 8b 46 18 48 8d 50 62 f0 80 48 62 20 48 8d 45 01 f0 80 4d 01 08 f0 80 65 00 fe f0 41 80 0e 02 4c 89 f7e8 f4 e3 ff ff 85 c0 75 04 <0f> 0b eb fe 4d 8b 66 10 9c 41 5d fa eb 13 f3 90 4c 89 e6 bf 04 Feb 7 12:43:12 champagne kernel: [ 5828.167494] RIP [] end_buffer_async_write+0x8f/0x12c Feb 7 12:43:12 champagne kernel: [ 5828.167500] RSP Feb 7 12:43:12 champagne kernel: [ 5828.167503] ---[ end trace 36b1562a43dab003 ]--- -- --- Cordiali Saluti Alessandro Bono --=-6a4h5iZZAGcv53WKxFWU Content-Disposition: attachment; filename="config-2.6.28.4" Content-Type: text/plain; name="config-2.6.28.4"; charset="UTF-8" Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28.4 # Sat Feb 7 00:49:53 2009 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_MM_OWNER=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_CLASSIC_RCU=y CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_VSMP is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_CPU=y CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR_64=y # CONFIG_X86_DS is not set CONFIG_HPET_TIMER=y CONFIG_DMI=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set # CONFIG_AMD_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set # CONFIG_I8K is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_ARCH_PHYS_ADDR_T_64BIT=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y # # Memory hotplug is currently incompatible with Software Suspend # CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y CONFIG_MMU_NOTIFIER=y # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW_64K=y CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y # CONFIG_EFI is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_SCHED_HRTICK=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x200000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x200000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_PM_VERBOSE is not set CONFIG_CAN_PM_TRACE=y # CONFIG_PM_TRACE_RTC is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m CONFIG_ACPI_WMI=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_PCI_SLOT=m CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_P4_CLOCKMOD is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # # Memory power savings # # CONFIG_I7300_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_DMAR is not set # CONFIG_INTR_REMAP is not set CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_PCIEAER=y # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m CONFIG_PCCARD_NONSTATIC=m CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_ACPI=m # CONFIG_HOTPLUG_PCI_ACPI_IBM is not set # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=m CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=m CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=m CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m # CONFIG_IPV6_MIP6 is not set CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_MROUTE is not set CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m # CONFIG_NF_CONNTRACK_SANE is not set CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m # CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_IP_VS=m # CONFIG_IP_VS_IPV6 is not set # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_RAW=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m # CONFIG_IP_DCCP is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_STP=m CONFIG_GARP=m CONFIG_BRIDGE=m # CONFIG_NET_DSA is not set CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y # CONFIG_DECNET is not set CONFIG_LLC=m CONFIG_LLC2=m # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_MULTIQ is not set CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m # CONFIG_CLS_U32_PERF is not set CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_ACT_SKBEDIT=m CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m # CONFIG_AF_RXRPC is not set CONFIG_PHONET=m CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_CFG80211=m CONFIG_NL80211=y # CONFIG_WIRELESS_OLD_REGULATORY is not set CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_MAC80211=m # # Rate control algorithm selection # CONFIG_MAC80211_RC_PID=y # CONFIG_MAC80211_RC_MINSTREL is not set CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set CONFIG_MAC80211_RC_DEFAULT="pid" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set # CONFIG_IEEE80211 is not set CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=m # CONFIG_MTD is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=65536 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set CONFIG_ATA_OVER_ETH=m CONFIG_VIRTIO_BLK=m # CONFIG_BLK_DEV_HD is not set CONFIG_MISC_DEVICES=y # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set CONFIG_EEPROM_93CX6=m # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m # CONFIG_ACER_WMI is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_FUJITSU_LAPTOP is not set CONFIG_HP_WMI=m # CONFIG_ICS932S401 is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_INTEL_MENLOW is not set # CONFIG_EEEPC_LAPTOP is not set CONFIG_ENCLOSURE_SERVICES=m # CONFIG_SGI_XP is not set # CONFIG_HP_ILO is not set # CONFIG_SGI_GRU is not set # CONFIG_C2PORT is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m # CONFIG_SCSI_ENCLOSURE is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=m # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_MVSAS is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_SRP=m CONFIG_SCSI_LOWLEVEL_PCMCIA=y # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set # CONFIG_SCSI_DH is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_PMP is not set CONFIG_SATA_AHCI=m # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=m # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ACPI is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PCMCIA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_SCH is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # Enable only one of the two stacks, unless you know what you are doing # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_DV1394=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_VETH=m # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set # CONFIG_NET_ETHERNET is not set CONFIG_MII=m CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set CONFIG_E1000E=m # CONFIG_IP1000 is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set # CONFIG_JME is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_LIBERTAS is not set # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_ATMEL is not set # CONFIG_AIRO_CS is not set # CONFIG_PCMCIA_WL3501 is not set # CONFIG_PRISM54 is not set # CONFIG_USB_ZD1201 is not set # CONFIG_USB_NET_RNDIS_WLAN is not set # CONFIG_RTL8180 is not set # CONFIG_RTL8187 is not set # CONFIG_ADM8211 is not set CONFIG_MAC80211_HWSIM=m # CONFIG_P54_COMMON is not set # CONFIG_ATH5K is not set # CONFIG_ATH9K is not set CONFIG_IWLWIFI=m CONFIG_IWLCORE=m CONFIG_IWLWIFI_LEDS=y CONFIG_IWLWIFI_RFKILL=y # CONFIG_IWLWIFI_DEBUG is not set CONFIG_IWLAGN=m CONFIG_IWLAGN_SPECTRUM_MEASUREMENT=y CONFIG_IWLAGN_LEDS=y CONFIG_IWL4965=y # CONFIG_IWL5000 is not set # CONFIG_IWL3945 is not set # CONFIG_HOSTAP is not set # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_ZD1211RW is not set # CONFIG_RT2X00 is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m # CONFIG_USB_NET_SMSC95XX is not set CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y # CONFIG_USB_NET_ZAURUS is not set CONFIG_USB_HSO=m CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set # CONFIG_PCMCIA_PCNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_PCMCIA_AXNET is not set CONFIG_WAN=y # CONFIG_LANMEDIA is not set CONFIG_HDLC=m CONFIG_HDLC_RAW=m CONFIG_HDLC_RAW_ETH=m CONFIG_HDLC_CISCO=m CONFIG_HDLC_FR=m CONFIG_HDLC_PPP=m # # X.25/LAPB support is disabled # # CONFIG_PCI200SYN is not set # CONFIG_WANXL is not set # CONFIG_PC300TOO is not set # CONFIG_FARSYNC is not set # CONFIG_DSCC4 is not set CONFIG_DLCI=m CONFIG_DLCI_MAX=8 CONFIG_WAN_ROUTER_DRIVERS=m # CONFIG_CYCLADES_SYNC is not set # CONFIG_SBNI is not set CONFIG_ATM_DRIVERS=y CONFIG_ATM_DUMMY=m CONFIG_ATM_TCP=m # CONFIG_ATM_LANAI is not set # CONFIG_ATM_ENI is not set # CONFIG_ATM_FIRESTREAM is not set # CONFIG_ATM_ZATM is not set # CONFIG_ATM_IDT77252 is not set # CONFIG_ATM_AMBASSADOR is not set # CONFIG_ATM_HORIZON is not set # CONFIG_ATM_IA is not set # CONFIG_ATM_FORE200E is not set # CONFIG_ATM_HE is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_PPPOL2TP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_VIRTIO_NET=m # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m CONFIG_INPUT_EVBUG=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_SUNKBD=m CONFIG_KEYBOARD_LKKBD=m CONFIG_KEYBOARD_XTKBD=m CONFIG_KEYBOARD_NEWTON=m CONFIG_KEYBOARD_STOWAWAY=m CONFIG_KEYBOARD_GPIO=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m # CONFIG_MOUSE_BCM5974 is not set CONFIG_MOUSE_VSXXXAA=m CONFIG_MOUSE_GPIO=m # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_FUJITSU=m CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_MTOUCH=m # CONFIG_TOUCHSCREEN_INEXIO is not set CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_USB_COMPOSITE=m CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_APANEL is not set CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m # CONFIG_INPUT_CM109 is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_NONSTANDARD=y # CONFIG_COMPUTONE is not set # CONFIG_ROCKETPORT is not set # CONFIG_CYCLADES is not set # CONFIG_DIGIEPCA is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_ISI is not set # CONFIG_SYNCLINK is not set # CONFIG_SYNCLINKMP is not set # CONFIG_SYNCLINK_GT is not set CONFIG_N_HDLC=m # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALDRV is not set CONFIG_NOZOMI=m # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=48 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_VIRTIO_CONSOLE=m # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=m CONFIG_HW_RANDOM_INTEL=m # CONFIG_HW_RANDOM_AMD is not set CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=m # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # CONFIG_SYNCLINK_CS=m CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_IPWIRELESS=m # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=m CONFIG_I2C_ISCH=m # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_GPIO=m # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Graphics adapter I2C/DDC channel drivers # # CONFIG_I2C_VOODOO3 is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set CONFIG_I2C_STUB=m # # Miscellaneous I2C Chip support # CONFIG_DS1682=m CONFIG_AT24=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8591=m CONFIG_TPS65010=m CONFIG_SENSORS_MAX6875=m CONFIG_SENSORS_TSL2550=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y # # Memory mapped GPIO expanders: # # # I2C GPIO expanders: # CONFIG_GPIO_MAX732X=m CONFIG_GPIO_PCA953X=m CONFIG_GPIO_PCF857X=m # # PCI GPIO expanders: # # # SPI GPIO expanders: # CONFIG_W1=m CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2490=m CONFIG_W1_MASTER_DS2482=m CONFIG_W1_MASTER_GPIO=m # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2433=m # CONFIG_W1_SLAVE_DS2433_CRC is not set CONFIG_W1_SLAVE_DS2760=m # CONFIG_W1_SLAVE_BQ27000 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set CONFIG_PDA_POWER=m # CONFIG_BATTERY_DS2760 is not set # CONFIG_BATTERY_BQ27x00 is not set CONFIG_HWMON=m # CONFIG_HWMON_VID is not set # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set CONFIG_SENSORS_ADT7462=m # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7473 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set CONFIG_SENSORS_CORETEMP=m # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set CONFIG_SENSORS_LIS3LV02D=m # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=m CONFIG_THERMAL_HWMON=y CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y # CONFIG_IT8712F_WDT is not set # CONFIG_IT87_WDT is not set # CONFIG_HP_WATCHDOG is not set # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set # CONFIG_W83697UG_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_REGULATOR is not set # # Multimedia devices # # # Multimedia core support # CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m # CONFIG_VIDEO_ALLOW_V4L1 is not set CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m # # Multimedia drivers # CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m CONFIG_MEDIA_TUNER_CUSTOMIZE=y CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_TDA9875=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_M52790=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m CONFIG_VIDEO_VIVI=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_CX23885=m CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CAFE_CCIC=m # CONFIG_SOC_CAMERA is not set CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_GSPCA_CONEX=m CONFIG_USB_GSPCA_ETOMS=m CONFIG_USB_GSPCA_FINEPIX=m CONFIG_USB_GSPCA_MARS=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_PAC207=m CONFIG_USB_GSPCA_PAC7311=m CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_USBVISION=m CONFIG_USB_ET61X251=m CONFIG_USB_SN9C102=m CONFIG_USB_ZC0301=m CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_RADIO_ADAPTERS=y # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set CONFIG_USB_DSBR=m # CONFIG_USB_SI470X is not set CONFIG_USB_MR800=m CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # # CONFIG_TTPCI_EEPROM is not set # CONFIG_DVB_AV7110 is not set # CONFIG_DVB_BUDGET_CORE is not set # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_SIANO_SMS1XXX=m CONFIG_DVB_SIANO_SMS1XXX_SMS_IDS=y # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m # CONFIG_DVB_B2C2_FLEXCOP_PCI is not set CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported Pluto2 Adapters # CONFIG_DVB_PLUTO2=m # # Supported SDMC DM1105 Adapters # # CONFIG_DVB_DM1105 is not set # # Supported DVB Frontends # # # Customise DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_SI21XX=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_DRX397XD=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m # # SEC control devices for DVB-S # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m CONFIG_DVB_LGS8GL5=m # # Tools to develop new frontends # CONFIG_DVB_DUMMY_FE=m CONFIG_DVB_AF9013=m CONFIG_DAB=y CONFIG_USB_DABUSB=m # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y # CONFIG_AGP_INTEL is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_VIA is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=m CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=m CONFIG_FB_CFB_COPYAREA=m CONFIG_FB_CFB_IMAGEBLIT=m # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set CONFIG_FB_VGA16=m CONFIG_FB_UVESA=m # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set CONFIG_FB_VIRTUAL=m # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_LCD_ILI9320 is not set CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_CORGI=m CONFIG_BACKLIGHT_PROGEAR=m # CONFIG_BACKLIGHT_MBP_NVIDIA is not set # CONFIG_BACKLIGHT_SAHARA is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_MPU401_UART=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_PCI=y # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y # CONFIG_SND_HDA_CODEC_NVHDMI is not set CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_HIFIER is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # CONFIG_SND_USB_US122L is not set CONFIG_SND_PCMCIA=y # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set CONFIG_HIDRAW=y # # USB Input Devices # CONFIG_USB_HID=m CONFIG_HID_PID=y CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m # # Special HID drivers # # CONFIG_HID_COMPAT is not set CONFIG_HID_A4TECH=m CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_BRIGHT=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m CONFIG_HID_DELL=m CONFIG_HID_EZKEY=m CONFIG_HID_GYRATION=m CONFIG_HID_LOGITECH=m # CONFIG_LOGITECH_FF is not set # CONFIG_LOGIRUMBLEPAD2_FF is not set CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m CONFIG_HID_PANTHERLORD=m # CONFIG_PANTHERLORD_FF is not set CONFIG_HID_PETALYNX=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m # CONFIG_THRUSTMASTER_FF is not set # CONFIG_ZEROPLUS_FF is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_MON=y CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m # CONFIG_USB_WUSB_CBAF_DEBUG is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m CONFIG_USB_SL811_CS=m # CONFIG_USB_R8A66597_HCD is not set CONFIG_USB_WHCI_HCD=m CONFIG_USB_HWA_HCD=m # # Enable Host or Gadget support to see Inventra options # # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed; # # # see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_ONETOUCH=y CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set CONFIG_USB_LIBUSUAL=y # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # # USB port drivers # CONFIG_USB_USS720=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m # CONFIG_USB_SERIAL_IR is not set CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m # CONFIG_USB_SERIAL_KEYSPAN is not set CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m # CONFIG_USB_SERIAL_SAFE_PADDED is not set CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m # CONFIG_USB_SEVSEG is not set CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_BERRY_CHARGE=m CONFIG_USB_LED=m CONFIG_USB_CYPRESS_CY7C63=m CONFIG_USB_CYTHERM=m CONFIG_USB_PHIDGET=m CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETMOTORCONTROL=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m # CONFIG_USB_APPLEDISPLAY is not set CONFIG_USB_SISUSBVGA=m # CONFIG_USB_SISUSBVGA_CON is not set CONFIG_USB_LD=m CONFIG_USB_TRANCEVIBRATOR=m CONFIG_USB_IOWARRIOR=m # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_VST is not set CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # CONFIG_USB_GADGET is not set CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_WLP=m CONFIG_UWB_I1480U=m CONFIG_UWB_I1480U_WLP=m CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_MMC_RICOH_MMC=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_MMC_SDRICOH_CS=m # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m # # LED drivers # CONFIG_LEDS_PCA9532=m CONFIG_LEDS_GPIO=m CONFIG_LEDS_HP_DISK=m # CONFIG_LEDS_CLEVO_MAIL is not set CONFIG_LEDS_PCA955X=m # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_BACKLIGHT=m CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y CONFIG_RTC_DRV_S35390A=m CONFIG_RTC_DRV_FM3130=m CONFIG_RTC_DRV_RX8581=m # # SPI RTC drivers # # # Platform RTC drivers # # CONFIG_RTC_DRV_CMOS is not set CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_STK17TA8=m CONFIG_RTC_DRV_M48T86=m CONFIG_RTC_DRV_M48T35=m CONFIG_RTC_DRV_M48T59=m CONFIG_RTC_DRV_BQ4802=m CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # # DMA Devices # CONFIG_INTEL_IOATDMA=m CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y CONFIG_DMATEST=m CONFIG_DCA=m CONFIG_AUXDISPLAY=y CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=m CONFIG_CFAG12864B_RATE=20 CONFIG_UIO=m # CONFIG_UIO_CIF is not set CONFIG_UIO_PDRV=m CONFIG_UIO_PDRV_GENIRQ=m # CONFIG_UIO_SMX is not set # CONFIG_UIO_SERCOS3 is not set # CONFIG_STAGING is not set # # Firmware Drivers # CONFIG_EDD=m # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m # CONFIG_EXT4DEV_COMPAT is not set CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=m # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_FILE_LOCKING=y CONFIG_XFS_FS=m # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y # CONFIG_XFS_DEBUG is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_DLM=m CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m CONFIG_OCFS2_FS_STATS=y CONFIG_OCFS2_DEBUG_MASKLOG=y # CONFIG_OCFS2_DEBUG_FS is not set # CONFIG_OCFS2_COMPAT_JBD is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_ECRYPT_FS=m # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set CONFIG_MINIX_FS=m # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set CONFIG_ROMFS_FS=m # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_REGISTER_V4=y CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_UPCALL=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_EXPERIMENTAL=y CONFIG_CIFS_DFS_UPCALL=y # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=m CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set # CONFIG_DETECT_SOFTLOCKUP is not set # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_FRAME_POINTER is not set # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y # # Tracers # # CONFIG_FUNCTION_TRACER is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_SYSPROF_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_CONTEXT_SWITCH_TRACER is not set # CONFIG_BOOT_TRACER is not set # CONFIG_STACK_TRACER is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_DYNAMIC_PRINTK_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y # CONFIG_EARLY_PRINTK_DBGP is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_X86_PTDUMP is not set CONFIG_DEBUG_RODATA=y # CONFIG_DIRECT_GBPAGES is not set # CONFIG_DEBUG_RODATA_TEST is not set # CONFIG_DEBUG_NX_TEST is not set # CONFIG_IOMMU_DEBUG is not set # CONFIG_MMIOTRACE is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # # Security options # CONFIG_KEYS=y # CONFIG_KEYS_DEBUG_PROC_KEYS is not set # CONFIG_SECURITY is not set CONFIG_SECURITYFS=y # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_FIPS=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m # # Block modes # CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m # # Hash modes # CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_XCBC=m # # Digest # CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_LZO=m # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_HIFN_795X is not set CONFIG_HAVE_KVM=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m # CONFIG_KVM_AMD is not set CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y --=-6a4h5iZZAGcv53WKxFWU Content-Disposition: attachment; filename="dmesg-2.6.28.4" Content-Type: text/plain; name="dmesg-2.6.28.4"; charset="UTF-8" Content-Transfer-Encoding: 7bit [ 0.000000] BIOS EBDA/lowmem at: 0009fc00/0009fc00 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Linux version 2.6.28.4 (root@champagne) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) ) #1 SMP Sat Feb 7 01:05:07 CET 2009 [ 0.000000] Command line: root=/dev/mapper/vol00-root ro quiet splash [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bffb0000 (usable) [ 0.000000] BIOS-e820: 00000000bffb0000 - 00000000bffc5400 (reserved) [ 0.000000] BIOS-e820: 00000000bffc5400 - 00000000bffe7fb8 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bffe7fb8 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fed20000 - 00000000fed9a000 (reserved) [ 0.000000] BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved) [ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000013c000000 (usable) [ 0.000000] DMI 2.4 present. [ 0.000000] last_pfn = 0x13c000 max_arch_pfn = 0x3ffffffff [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] last_pfn = 0xbffb0 max_arch_pfn = 0x3ffffffff [ 0.000000] init_memory_mapping: 0000000000000000-00000000bffb0000 [ 0.000000] 0000000000 - 00bfe00000 page 2M [ 0.000000] 00bfe00000 - 00bffb0000 page 4k [ 0.000000] kernel direct mapping tables up to bffb0000 @ 8000-d000 [ 0.000000] last_map_addr: bffb0000 end: bffb0000 [ 0.000000] init_memory_mapping: 0000000100000000-000000013c000000 [ 0.000000] 0100000000 - 013c000000 page 2M [ 0.000000] kernel direct mapping tables up to 13c000000 @ b000-11000 [ 0.000000] last_map_addr: 13c000000 end: 13c000000 [ 0.000000] RAMDISK: 37a08000 - 37fef382 [ 0.000000] ACPI: RSDP 000F7D10, 0024 (r2 HP ) [ 0.000000] ACPI: XSDT BFFC81CC, 0084 (r1 HPQOEM SLIC-MPC 1 HP 1) [ 0.000000] ACPI: FACP BFFC8084, 00F4 (r4 HP 30C5 3 HP 1) [ 0.000000] ACPI: DSDT BFFC8544, 12EAD (r1 HP 8510x 10000 MSFT 3000001) [ 0.000000] ACPI: FACS BFFE7D80, 0040 [ 0.000000] ACPI: SLIC BFFC8250, 0176 (r1 HPQOEM SLIC-MPC 1 HP 1) [ 0.000000] ACPI: HPET BFFC83C8, 0038 (r1 HP 30C5 1 HP 1) [ 0.000000] ACPI: APIC BFFC8400, 0068 (r1 HP 30C5 1 HP 1) [ 0.000000] ACPI: MCFG BFFC8468, 003C (r1 HP 30C5 1 HP 1) [ 0.000000] ACPI: TCPA BFFC84A4, 0032 (r2 HP 30C5 1 HP 1) [ 0.000000] ACPI: ASF! BFFC84D8, 0069 (r16 HP CHIMAYU 1 HP 0) [ 0.000000] ACPI: SSDT BFFDB3F1, 0328 (r1 HP HPQSAT 1 MSFT 3000001) [ 0.000000] ACPI: SSDT BFFDB719, 017C (r1 HP HPQMRM 1 MSFT 3000001) [ 0.000000] ACPI: SSDT BFFDC29D, 025F (r1 HP Cpu0Tst 3000 INTL 20060317) [ 0.000000] ACPI: SSDT BFFDC4FC, 00A6 (r1 HP Cpu1Tst 3000 INTL 20060317) [ 0.000000] ACPI: SSDT BFFDC5A2, 04D7 (r1 HP CpuPm 3000 INTL 20060317) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] (7 early reservations) ==> bootmem [0000000000 - 013c000000] [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 0.000000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] [ 0.000000] #2 [0000200000 - 00005f42c8] TEXT DATA BSS ==> [0000200000 - 00005f42c8] [ 0.000000] #3 [0037a08000 - 0037fef382] RAMDISK ==> [0037a08000 - 0037fef382] [ 0.000000] #4 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000] [ 0.000000] #5 [0000008000 - 000000b000] PGTABLE ==> [0000008000 - 000000b000] [ 0.000000] #6 [000000b000 - 000000c000] PGTABLE ==> [000000b000 - 000000c000] [ 0.000000] [ffffe20000000000-ffffe200045fffff] PMD -> [ffff880028200000-ffff88002c7fffff] on node 0 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000000 -> 0x00001000 [ 0.000000] DMA32 0x00001000 -> 0x00100000 [ 0.000000] Normal 0x00100000 -> 0x0013c000 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[3] active PFN ranges [ 0.000000] 0: 0x00000000 -> 0x0000009f [ 0.000000] 0: 0x00000100 -> 0x000bffb0 [ 0.000000] 0: 0x00100000 -> 0x0013c000 [ 0.000000] On node 0 totalpages: 1032015 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 1115 pages reserved [ 0.000000] DMA zone: 2828 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 14280 pages used for memmap [ 0.000000] DMA32 zone: 767976 pages, LIFO batch:31 [ 0.000000] Normal zone: 3360 pages used for memmap [ 0.000000] Normal zone: 242400 pages, LIFO batch:31 [ 0.000000] Movable zone: 0 pages used for memmap [ 0.000000] ACPI: PM-Timer IO Port: 0x1008 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] PM: Registered nosave memory: 00000000bffb0000 - 00000000bffc5000 [ 0.000000] PM: Registered nosave memory: 00000000bffc5000 - 00000000bffc6000 [ 0.000000] PM: Registered nosave memory: 00000000bffc6000 - 00000000bffe7000 [ 0.000000] PM: Registered nosave memory: 00000000bffe7000 - 00000000bffe8000 [ 0.000000] PM: Registered nosave memory: 00000000bffe8000 - 00000000c0000000 [ 0.000000] PM: Registered nosave memory: 00000000c0000000 - 00000000fec00000 [ 0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000 [ 0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fed20000 [ 0.000000] PM: Registered nosave memory: 00000000fed20000 - 00000000fed9a000 [ 0.000000] PM: Registered nosave memory: 00000000fed9a000 - 00000000feda0000 [ 0.000000] PM: Registered nosave memory: 00000000feda0000 - 00000000fedc0000 [ 0.000000] PM: Registered nosave memory: 00000000fedc0000 - 00000000fee00000 [ 0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000 [ 0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ffb00000 [ 0.000000] PM: Registered nosave memory: 00000000ffb00000 - 00000000ffc00000 [ 0.000000] PM: Registered nosave memory: 00000000ffc00000 - 00000000fff00000 [ 0.000000] PM: Registered nosave memory: 00000000fff00000 - 0000000100000000 [ 0.000000] Allocating PCI resources starting at c4000000 (gap: c0000000:3ec00000) [ 0.000000] PERCPU: Allocating 53248 bytes of per cpu data [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 2, nr_node_ids 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1013204 [ 0.000000] Kernel command line: root=/dev/mapper/vol00-root ro quiet splash [ 0.000000] Initializing CPU#0 [ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) [ 0.000000] Extended CMOS year: 2000 [ 0.000000] Fast TSC calibration using PIT [ 0.000000] Detected 2394.092 MHz processor. [ 0.004000] Console: colour VGA+ 80x25 [ 0.004000] console [tty0] enabled [ 0.004000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.004000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.004000] allocated 52428800 bytes of page_cgroup [ 0.004000] please try cgroup_disable=memory option if you don't want [ 0.004000] Checking aperture... [ 0.004000] No AGP bridge found [ 0.004000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.004000] Placing software IO TLB between 0x20000000 - 0x24000000 [ 0.004000] Memory: 3921656k/5177344k available (2026k kernel code, 1049284k absent, 205412k reserved, 1029k data, 316k init) [ 0.004000] SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.004000] hpet clockevent registered [ 0.004000] HPET: 3 timers in total, 0 timers will be used for per-cpu timer [ 0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4788.18 BogoMIPS (lpj=9576368) [ 0.004000] Mount-cache hash table entries: 256 [ 0.004000] Initializing cgroup subsys ns [ 0.004000] Initializing cgroup subsys cpuacct [ 0.004000] Initializing cgroup subsys memory [ 0.004000] Initializing cgroup subsys devices [ 0.004000] Initializing cgroup subsys freezer [ 0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.004000] CPU: L2 cache: 4096K [ 0.004000] CPU: Physical Processor ID: 0 [ 0.004000] CPU: Processor Core ID: 0 [ 0.004000] CPU0: Thermal monitoring handled by SMI [ 0.004000] using mwait in idle threads. [ 0.004000] ACPI: Core revision 20080926 [ 0.024047] Setting APIC routing to flat [ 0.024423] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.066217] CPU0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping 0b [ 0.068001] Booting processor 1 APIC 0x1 ip 0x6000 [ 0.004000] Initializing CPU#1 [ 0.004000] Calibrating delay using timer specific routine.. 4787.96 BogoMIPS (lpj=9575928) [ 0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.004000] CPU: L2 cache: 4096K [ 0.004000] CPU: Physical Processor ID: 0 [ 0.004000] CPU: Processor Core ID: 1 [ 0.004000] CPU1: Thermal monitoring enabled (TM2) [ 0.004000] x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 [ 0.153245] CPU1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping 0b [ 0.153265] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 0.156020] Brought up 2 CPUs [ 0.156022] Total of 2 processors activated (9576.14 BogoMIPS). [ 0.156095] net_namespace: 1352 bytes [ 0.156136] NET: Registered protocol family 16 [ 0.156136] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 0.156136] ACPI: bus type pci registered [ 0.156136] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63 [ 0.156136] PCI: Not using MMCONFIG. [ 0.156136] PCI: Using configuration type 1 for base access [ 0.156790] ACPI: EC: Look up EC in DSDT [ 0.160019] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 0.217728] ACPI: Interpreter enabled [ 0.217731] ACPI: (supports S0 S3 S4 S5) [ 0.217744] ACPI: Using IOAPIC for interrupt routing [ 0.217805] PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63 [ 0.225836] PCI: MCFG area at f8000000 reserved in ACPI motherboard resources [ 0.228389] PCI: Using MMCONFIG at f8000000 - fbffffff [ 0.240289] ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62 [ 0.240289] ACPI: EC: driver started in interrupt mode [ 0.240289] ACPI: No dock devices found. [ 0.240289] ACPI: PCI Root Bridge [C003] (0000:00) [ 0.240289] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.240289] pci 0000:00:01.0: PME# disabled [ 0.240289] pci 0000:00:03.0: reg 10 64bit mmio: [0xe4500000-0xe450000f] [ 0.240289] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold [ 0.240289] pci 0000:00:03.0: PME# disabled [ 0.240289] pci 0000:00:03.2: reg 10 io port: [0x5000-0x5007] [ 0.240289] pci 0000:00:03.2: reg 14 io port: [0x5008-0x500b] [ 0.240289] pci 0000:00:03.2: reg 18 io port: [0x5010-0x5017] [ 0.240289] pci 0000:00:03.2: reg 1c io port: [0x5018-0x501b] [ 0.240289] pci 0000:00:03.2: reg 20 io port: [0x5020-0x502f] [ 0.240289] pci 0000:00:03.3: reg 10 io port: [0x5030-0x5037] [ 0.240289] pci 0000:00:03.3: reg 14 32bit mmio: [0xe4501000-0xe4501fff] [ 0.240303] pci 0000:00:19.0: reg 10 32bit mmio: [0xe4520000-0xe453ffff] [ 0.240310] pci 0000:00:19.0: reg 14 32bit mmio: [0xe4540000-0xe4540fff] [ 0.240317] pci 0000:00:19.0: reg 18 io port: [0x5040-0x505f] [ 0.240349] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 0.240354] pci 0000:00:19.0: PME# disabled [ 0.240403] pci 0000:00:1a.0: reg 20 io port: [0x5060-0x507f] [ 0.240461] pci 0000:00:1a.1: reg 20 io port: [0x5080-0x509f] [ 0.240526] pci 0000:00:1a.7: reg 10 32bit mmio: [0xe4541000-0xe45413ff] [ 0.240570] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 0.240575] pci 0000:00:1a.7: PME# disabled [ 0.240626] pci 0000:00:1b.0: reg 10 64bit mmio: [0xe4544000-0xe4547fff] [ 0.240664] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.240668] pci 0000:00:1b.0: PME# disabled [ 0.240731] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.240735] pci 0000:00:1c.0: PME# disabled [ 0.240800] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold [ 0.240804] pci 0000:00:1c.1: PME# disabled [ 0.244040] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 0.244044] pci 0000:00:1c.4: PME# disabled [ 0.244103] pci 0000:00:1d.0: reg 20 io port: [0x50a0-0x50bf] [ 0.244161] pci 0000:00:1d.1: reg 20 io port: [0x50c0-0x50df] [ 0.244219] pci 0000:00:1d.2: reg 20 io port: [0x50e0-0x50ff] [ 0.244282] pci 0000:00:1d.7: reg 10 32bit mmio: [0xe4548000-0xe45483ff] [ 0.244326] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 0.244331] pci 0000:00:1d.7: PME# disabled [ 0.244481] pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO [ 0.244485] pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO [ 0.244519] pci 0000:00:1f.1: reg 10 io port: [0x00-0x07] [ 0.244526] pci 0000:00:1f.1: reg 14 io port: [0x00-0x03] [ 0.244533] pci 0000:00:1f.1: reg 18 io port: [0x00-0x07] [ 0.244540] pci 0000:00:1f.1: reg 1c io port: [0x00-0x03] [ 0.244547] pci 0000:00:1f.1: reg 20 io port: [0x5100-0x510f] [ 0.244615] pci 0000:00:1f.2: reg 10 io port: [0x13f0-0x13f7] [ 0.244622] pci 0000:00:1f.2: reg 14 io port: [0x15f4-0x15f7] [ 0.244629] pci 0000:00:1f.2: reg 18 io port: [0x1370-0x1377] [ 0.244636] pci 0000:00:1f.2: reg 1c io port: [0x1574-0x1577] [ 0.244643] pci 0000:00:1f.2: reg 20 io port: [0x5140-0x515f] [ 0.244650] pci 0000:00:1f.2: reg 24 32bit mmio: [0xe4549000-0xe45497ff] [ 0.244669] pci 0000:00:1f.2: PME# supported from D3hot [ 0.244673] pci 0000:00:1f.2: PME# disabled [ 0.244724] pci 0000:01:00.0: reg 10 32bit mmio: [0xd0000000-0xdfffffff] [ 0.244731] pci 0000:01:00.0: reg 14 io port: [0x4000-0x40ff] [ 0.244739] pci 0000:01:00.0: reg 18 32bit mmio: [0xe4400000-0xe440ffff] [ 0.244762] pci 0000:01:00.0: reg 30 32bit mmio: [0x000000-0x01ffff] [ 0.244772] pci 0000:01:00.0: supports D1 D2 [ 0.244814] pci 0000:01:00.1: reg 10 32bit mmio: [0xe4410000-0xe4413fff] [ 0.244855] pci 0000:01:00.1: supports D1 D2 [ 0.244920] pci 0000:00:01.0: bridge io port: [0x4000-0x4fff] [ 0.244922] pci 0000:00:01.0: bridge 32bit mmio: [0xe4400000-0xe44fffff] [ 0.244926] pci 0000:00:01.0: bridge 64bit mmio pref: [0xd0000000-0xdfffffff] [ 0.245108] pci 0000:10:00.0: reg 10 64bit mmio: [0xe4000000-0xe4001fff] [ 0.245194] pci 0000:10:00.0: PME# supported from D0 D3hot D3cold [ 0.245206] pci 0000:10:00.0: PME# disabled [ 0.245290] pci 0000:00:1c.1: bridge 32bit mmio: [0xe4000000-0xe40fffff] [ 0.245352] pci 0000:00:1c.4: bridge io port: [0x2000-0x3fff] [ 0.245356] pci 0000:00:1c.4: bridge 32bit mmio: [0xe0000000-0xe3ffffff] [ 0.245414] pci 0000:02:06.0: reg 10 32bit mmio: [0xe4100000-0xe4100fff] [ 0.245425] pci 0000:02:06.0: supports D1 D2 [ 0.245426] pci 0000:02:06.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.245431] pci 0000:02:06.0: PME# disabled [ 0.245470] pci 0000:02:06.1: reg 10 32bit mmio: [0xe4101000-0xe4101fff] [ 0.245481] pci 0000:02:06.1: supports D1 D2 [ 0.245482] pci 0000:02:06.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.245487] pci 0000:02:06.1: PME# disabled [ 0.245527] pci 0000:02:06.2: reg 10 32bit mmio: [0xe4102000-0xe41027ff] [ 0.245572] pci 0000:02:06.2: supports D1 D2 [ 0.245573] pci 0000:02:06.2: PME# supported from D0 D1 D2 D3hot D3cold [ 0.245578] pci 0000:02:06.2: PME# disabled [ 0.245617] pci 0000:02:06.3: reg 10 32bit mmio: [0xe4103000-0xe41030ff] [ 0.245663] pci 0000:02:06.3: supports D1 D2 [ 0.245664] pci 0000:02:06.3: PME# supported from D0 D1 D2 D3hot D3cold [ 0.245669] pci 0000:02:06.3: PME# disabled [ 0.245710] pci 0000:02:06.4: reg 10 32bit mmio: [0xe4104000-0xe41040ff] [ 0.245756] pci 0000:02:06.4: supports D1 D2 [ 0.245757] pci 0000:02:06.4: PME# supported from D0 D1 D2 D3hot D3cold [ 0.245762] pci 0000:02:06.4: PME# disabled [ 0.245819] pci 0000:00:1e.0: transparent bridge [ 0.245826] pci 0000:00:1e.0: bridge 32bit mmio: [0xe4100000-0xe43fffff] [ 0.245894] bus 00 -> node 0 [ 0.245899] ACPI: PCI Interrupt Routing Table [\_SB_.C003._PRT] [ 0.246392] ACPI: PCI Interrupt Routing Table [\_SB_.C003.C096._PRT] [ 0.246516] ACPI: PCI Interrupt Routing Table [\_SB_.C003.C0B0._PRT] [ 0.246701] ACPI: PCI Interrupt Routing Table [\_SB_.C003.C11D._PRT] [ 0.246850] ACPI: PCI Interrupt Routing Table [\_SB_.C003.C131._PRT] [ 0.247000] ACPI: PCI Interrupt Routing Table [\_SB_.C003.C134._PRT] [ 0.296584] ACPI: PCI Interrupt Link [C12D] (IRQs *10 11) [ 0.296584] ACPI: PCI Interrupt Link [C12E] (IRQs *10 11) [ 0.296601] ACPI: PCI Interrupt Link [C12F] (IRQs 10 *11) [ 0.296826] ACPI: PCI Interrupt Link [C130] (IRQs 10 11) *5 [ 0.297052] ACPI: PCI Interrupt Link [C140] (IRQs *10 11) [ 0.297278] ACPI: PCI Interrupt Link [C141] (IRQs 10 11) *5 [ 0.297503] ACPI: PCI Interrupt Link [C142] (IRQs 10 *11) [ 0.297607] ACPI Exception (pci_link-0189): AE_NOT_FOUND, Evaluating _PRS [20080926] [ 0.297722] ACPI: Power Resource [C22B] (on) [ 0.297722] ACPI: Power Resource [C238] (on) [ 0.297722] ACPI: Power Resource [C254] (on) [ 0.297722] ACPI: Power Resource [C17C] (off) [ 0.297722] ACPI: Power Resource [C363] (off) [ 0.297722] ACPI: Power Resource [C366] (off) [ 0.297722] ACPI: Power Resource [C367] (off) [ 0.297722] ACPI: Power Resource [C368] (off) [ 0.297722] ACPI: Power Resource [C369] (off) [ 0.297722] ACPI: Power Resource [C36A] (off) [ 0.297722] ACPI: Power Resource [C383] (off) [ 0.300081] ACPI: Power Resource [C384] (off) [ 0.300182] ACPI: Power Resource [C385] (off) [ 0.300283] ACPI: Power Resource [C386] (off) [ 0.300384] ACPI: Power Resource [C387] (off) [ 0.300395] PCI: Using ACPI for IRQ routing [ 0.316028] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.316031] hpet0: 3 comparators, 64-bit 14.318180 MHz counter [ 0.332005] pnp: PnP ACPI init [ 0.332011] ACPI: bus type pnp registered [ 0.343556] pnp: PnP ACPI: found 16 devices [ 0.343558] ACPI: ACPI bus type pnp unregistered [ 0.343564] system 00:00: iomem range 0x0-0x9ffff could not be reserved [ 0.343566] system 00:00: iomem range 0xe0000-0xfffff could not be reserved [ 0.343569] system 00:00: iomem range 0x100000-0xbfffffff could not be reserved [ 0.343576] system 00:0c: ioport range 0x500-0x55f has been reserved [ 0.343578] system 00:0c: ioport range 0x800-0x80f has been reserved [ 0.343580] system 00:0c: iomem range 0xffb00000-0xffbfffff has been reserved [ 0.343583] system 00:0c: iomem range 0xfff00000-0xffffffff has been reserved [ 0.343587] system 00:0e: ioport range 0x4d0-0x4d1 has been reserved [ 0.343589] system 00:0e: ioport range 0x1000-0x107f has been reserved [ 0.343591] system 00:0e: ioport range 0x1100-0x113f has been reserved [ 0.343593] system 00:0e: ioport range 0x1200-0x121f has been reserved [ 0.343595] system 00:0e: iomem range 0xf8000000-0xfbffffff has been reserved [ 0.343597] system 00:0e: iomem range 0xfec00000-0xfec000ff has been reserved [ 0.343600] system 00:0e: iomem range 0xfed20000-0xfed3ffff has been reserved [ 0.343602] system 00:0e: iomem range 0xfed45000-0xfed8ffff has been reserved [ 0.343604] system 00:0e: iomem range 0xfed90000-0xfed99fff has been reserved [ 0.343608] system 00:0f: iomem range 0xcf400-0xcffff has been reserved [ 0.343610] system 00:0f: iomem range 0xfeda0000-0xfedbffff has been reserved [ 0.343612] system 00:0f: iomem range 0xfee00000-0xfee00fff has been reserved [ 0.348459] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01 [ 0.348462] pci 0000:00:01.0: IO window: 0x4000-0x4fff [ 0.348465] pci 0000:00:01.0: MEM window: 0xe4400000-0xe44fffff [ 0.348468] pci 0000:00:01.0: PREFETCH window: 0x000000d0000000-0x000000dfffffff [ 0.348472] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08 [ 0.348473] pci 0000:00:1c.0: IO window: disabled [ 0.348479] pci 0000:00:1c.0: MEM window: disabled [ 0.348483] pci 0000:00:1c.0: PREFETCH window: disabled [ 0.348490] pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10 [ 0.348491] pci 0000:00:1c.1: IO window: disabled [ 0.348497] pci 0000:00:1c.1: MEM window: 0xe4000000-0xe40fffff [ 0.348501] pci 0000:00:1c.1: PREFETCH window: disabled [ 0.348508] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:28 [ 0.348511] pci 0000:00:1c.4: IO window: 0x2000-0x3fff [ 0.348516] pci 0000:00:1c.4: MEM window: 0xe0000000-0xe3ffffff [ 0.348521] pci 0000:00:1c.4: PREFETCH window: disabled [ 0.348531] pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03 [ 0.348532] pci 0000:02:06.0: IO window: 0x006000-0x0060ff [ 0.348537] pci 0000:02:06.0: IO window: 0x006400-0x0064ff [ 0.348541] pci 0000:02:06.0: PREFETCH window: 0xc4000000-0xc7ffffff [ 0.348545] pci 0000:02:06.0: MEM window: 0xcc000000-0xcfffffff [ 0.348550] pci 0000:02:06.1: CardBus bridge, secondary bus 0000:04 [ 0.348551] pci 0000:02:06.1: IO window: 0x006800-0x0068ff [ 0.348556] pci 0000:02:06.1: IO window: 0x006c00-0x006cff [ 0.348560] pci 0000:02:06.1: PREFETCH window: 0xc8000000-0xcbffffff [ 0.348564] pci 0000:02:06.1: MEM window: 0xe8000000-0xebffffff [ 0.348569] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02 [ 0.348571] pci 0000:00:1e.0: IO window: 0x6000-0x6fff [ 0.348577] pci 0000:00:1e.0: MEM window: 0xe4100000-0xe43fffff [ 0.348582] pci 0000:00:1e.0: PREFETCH window: 0x000000c4000000-0x000000cbffffff [ 0.348594] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.348597] pci 0000:00:01.0: setting latency timer to 64 [ 0.348604] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.348609] pci 0000:00:1c.0: setting latency timer to 64 [ 0.348617] pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 0.348621] pci 0000:00:1c.1: setting latency timer to 64 [ 0.348629] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.348633] pci 0000:00:1c.4: setting latency timer to 64 [ 0.348641] pci 0000:00:1e.0: setting latency timer to 64 [ 0.348648] pci 0000:02:06.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.348658] pci 0000:02:06.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 0.348663] bus: 00 index 0 io port: [0x00-0xffff] [ 0.348665] bus: 00 index 1 mmio: [0x000000-0xffffffffffffffff] [ 0.348667] bus: 01 index 0 io port: [0x4000-0x4fff] [ 0.348668] bus: 01 index 1 mmio: [0xe4400000-0xe44fffff] [ 0.348670] bus: 01 index 2 mmio: [0xd0000000-0xdfffffff] [ 0.348671] bus: 01 index 3 mmio: [0x0-0x0] [ 0.348673] bus: 08 index 0 mmio: [0x0-0x0] [ 0.348674] bus: 08 index 1 mmio: [0x0-0x0] [ 0.348675] bus: 08 index 2 mmio: [0x0-0x0] [ 0.348677] bus: 08 index 3 mmio: [0x0-0x0] [ 0.348678] bus: 10 index 0 mmio: [0x0-0x0] [ 0.348679] bus: 10 index 1 mmio: [0xe4000000-0xe40fffff] [ 0.348681] bus: 10 index 2 mmio: [0x0-0x0] [ 0.348682] bus: 10 index 3 mmio: [0x0-0x0] [ 0.348684] bus: 28 index 0 io port: [0x2000-0x3fff] [ 0.348685] bus: 28 index 1 mmio: [0xe0000000-0xe3ffffff] [ 0.348687] bus: 28 index 2 mmio: [0x0-0x0] [ 0.348688] bus: 28 index 3 mmio: [0x0-0x0] [ 0.348690] bus: 02 index 0 io port: [0x6000-0x6fff] [ 0.348691] bus: 02 index 1 mmio: [0xe4100000-0xe43fffff] [ 0.348693] bus: 02 index 2 mmio: [0xc4000000-0xcbffffff] [ 0.348694] bus: 02 index 3 io port: [0x00-0xffff] [ 0.348696] bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff] [ 0.348697] bus: 03 index 0 io port: [0x6000-0x60ff] [ 0.348699] bus: 03 index 1 io port: [0x6400-0x64ff] [ 0.348700] bus: 03 index 2 mmio: [0xc4000000-0xc7ffffff] [ 0.348702] bus: 03 index 3 mmio: [0xcc000000-0xcfffffff] [ 0.348704] bus: 04 index 0 io port: [0x6800-0x68ff] [ 0.348705] bus: 04 index 1 io port: [0x6c00-0x6cff] [ 0.348707] bus: 04 index 2 mmio: [0xc8000000-0xcbffffff] [ 0.348708] bus: 04 index 3 mmio: [0xe8000000-0xebffffff] [ 0.348716] NET: Registered protocol family 2 [ 0.388034] IP route cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.388454] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) [ 0.390260] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 0.390889] TCP: Hash tables configured (established 262144 bind 65536) [ 0.390891] TCP reno registered [ 0.400085] NET: Registered protocol family 1 [ 0.400182] checking if image is initramfs...<7>Switched to high resolution mode on CPU 1 [ 0.503992] Switched to high resolution mode on CPU 0 [ 0.600861] it is [ 0.814370] Freeing initrd memory: 6044k freed [ 0.817524] alg: cipher: Test 1 failed on encryption for aes-asm [ 0.817591] 00000000: 00 01 02 03 04 05 06 07 08 08 08 08 08 08 08 08 [ 0.817757] audit: initializing netlink socket (disabled) [ 0.817774] type=2000 audit(1234007494.817:1): initialized [ 0.818121] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.819847] msgmni has been set to 7673 [ 0.820057] alg: No test for stdrng (krng) [ 0.820131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [ 0.820133] io scheduler noop registered [ 0.820176] io scheduler cfq registered (default) [ 0.820319] pci 0000:01:00.0: Boot video device [ 0.828177] pcieport-driver 0000:00:01.0: setting latency timer to 64 [ 0.828204] pcieport-driver 0000:00:01.0: found MSI capability [ 0.828224] pcieport-driver 0000:00:01.0: irq 511 for MSI/MSI-X [ 0.828232] pci_express 0000:00:01.0:pcie00: allocate port service [ 0.828262] pci_express 0000:00:01.0:pcie03: allocate port service [ 0.828322] pcieport-driver 0000:00:1c.0: setting latency timer to 64 [ 0.828367] pcieport-driver 0000:00:1c.0: found MSI capability [ 0.828397] pcieport-driver 0000:00:1c.0: irq 510 for MSI/MSI-X [ 0.828412] pci_express 0000:00:1c.0:pcie00: allocate port service [ 0.828438] pci_express 0000:00:1c.0:pcie03: allocate port service [ 0.828524] pcieport-driver 0000:00:1c.1: setting latency timer to 64 [ 0.828569] pcieport-driver 0000:00:1c.1: found MSI capability [ 0.828600] pcieport-driver 0000:00:1c.1: irq 509 for MSI/MSI-X [ 0.828614] pci_express 0000:00:1c.1:pcie00: allocate port service [ 0.828646] pci_express 0000:00:1c.1:pcie02: allocate port service [ 0.828676] pci_express 0000:00:1c.1:pcie03: allocate port service [ 0.828764] pcieport-driver 0000:00:1c.4: setting latency timer to 64 [ 0.828810] pcieport-driver 0000:00:1c.4: found MSI capability [ 0.828840] pcieport-driver 0000:00:1c.4: irq 508 for MSI/MSI-X [ 0.828855] pci_express 0000:00:1c.4:pcie00: allocate port service [ 0.828882] pci_express 0000:00:1c.4:pcie02: allocate port service [ 0.828908] pci_express 0000:00:1c.4:pcie03: allocate port service [ 0.847728] Linux agpgart interface v0.103 [ 0.847731] Serial: 8250/16550 driver4 ports, IRQ sharing enabled [ 0.847868] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.848670] 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.848877] serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 0.848980] 0000:00:03.3: ttyS1 at I/O 0x5030 (irq = 17) is a 16550A [ 0.850046] brd: module loaded [ 0.850120] PNP: PS/2 Controller [PNP0303:C251,PNP0f13:C252] at 0x60,0x64 irq 1,12 [ 0.851952] i8042.c: Detected active multiplexing controller, rev 1.1. [ 0.852705] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 0.852709] serio: i8042 AUX0 port at 0x60,0x64 irq 12 [ 0.852710] serio: i8042 AUX1 port at 0x60,0x64 irq 12 [ 0.852712] serio: i8042 AUX2 port at 0x60,0x64 irq 12 [ 0.852714] serio: i8042 AUX3 port at 0x60,0x64 irq 12 [ 0.852831] mice: PS/2 mouse device common for all mice [ 0.852874] cpuidle: using governor ladder [ 0.852876] cpuidle: using governor menu [ 0.853123] TCP cubic registered [ 0.853412] Freeing unused kernel memory: 316k freed [ 0.853541] Write protecting the kernel read-only data: 2772k [ 0.901791] input: AT Translated Set 2 keyboard as /class/input/input0 [ 0.935622] fuse init (API version 7.10) [ 0.940108] fan PNP0C0B:00: registered as cooling_device0 [ 0.940113] ACPI: Fan [C36B] (off) [ 0.940342] fan PNP0C0B:01: registered as cooling_device1 [ 0.940346] ACPI: Fan [C36C] (off) [ 0.940572] fan PNP0C0B:02: registered as cooling_device2 [ 0.940576] ACPI: Fan [C36D] (off) [ 0.940801] fan PNP0C0B:03: registered as cooling_device3 [ 0.940805] ACPI: Fan [C36E] (off) [ 0.941042] fan PNP0C0B:04: registered as cooling_device4 [ 0.941047] ACPI: Fan [C36F] (off) [ 0.941160] fan PNP0C0B:05: registered as cooling_device5 [ 0.941165] ACPI: Fan [C370] (off) [ 0.941393] fan PNP0C0B:06: registered as cooling_device6 [ 0.941398] ACPI: Fan [C388] (off) [ 0.941621] fan PNP0C0B:07: registered as cooling_device7 [ 0.941626] ACPI: Fan [C389] (off) [ 0.941851] fan PNP0C0B:08: registered as cooling_device8 [ 0.941855] ACPI: Fan [C38A] (off) [ 0.942082] fan PNP0C0B:09: registered as cooling_device9 [ 0.942087] ACPI: Fan [C38B] (off) [ 0.942313] fan PNP0C0B:0a: registered as cooling_device10 [ 0.942318] ACPI: Fan [C38C] (off) [ 0.946385] ACPI: SSDT BFFDB95D, 02C1 (r1 HP Cpu0Ist 3000 INTL 20060317) [ 0.946825] ACPI: SSDT BFFDBCA3, 05FA (r1 HP Cpu0Cst 3001 INTL 20060317) [ 0.949423] Monitor-Mwait will be used to enter C-1 state [ 0.949426] Monitor-Mwait will be used to enter C-2 state [ 0.949536] ACPI: CPU0 (power states: C1[C1] C2[C2]) [ 0.949568] processor ACPI_CPU:00: registered as cooling_device11 [ 0.949571] ACPI: Processor [CPU0] (supports 8 throttling states) [ 0.949896] ACPI: SSDT BFFDB895, 00C8 (r1 HP Cpu1Ist 3000 INTL 20060317) [ 0.950203] ACPI: SSDT BFFDBC1E, 0085 (r1 HP Cpu1Cst 3000 INTL 20060317) [ 0.951151] ACPI: CPU1 (power states: C1[C1] C2[C2]) [ 0.951180] processor ACPI_CPU:01: registered as cooling_device12 [ 0.951183] ACPI: Processor [CPU1] (supports 8 throttling states) [ 0.957151] thermal LNXTHERM:01: registered as thermal_zone0 [ 0.960074] Marking TSC unstable due to TSC halts in idle [ 0.974356] ACPI: Thermal Zone [TZ2] (66 C) [ 0.977577] thermal LNXTHERM:02: registered as thermal_zone1 [ 0.979241] ACPI: Thermal Zone [TZ3] (63 C) [ 0.986552] thermal LNXTHERM:03: registered as thermal_zone2 [ 0.998571] ACPI: Thermal Zone [TZ4] (34 C) [ 1.001362] thermal LNXTHERM:04: registered as thermal_zone3 [ 1.007323] ACPI: Thermal Zone [TZ5] (73 C) [ 1.025402] thermal LNXTHERM:05: registered as thermal_zone4 [ 1.045567] ACPI: Thermal Zone [TZ0] (85 C) [ 1.048604] thermal LNXTHERM:06: registered as thermal_zone5 [ 1.050422] ACPI: Thermal Zone [TZ1] (86 C) [ 1.056837] device-mapper: uevent: version 1.0.3 [ 1.056969] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com [ 1.450871] e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6 [ 1.450873] e1000e: Copyright (c) 1999-2008 Intel Corporation. [ 1.450916] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 1.450925] e1000e 0000:00:19.0: setting latency timer to 64 [ 1.451036] e1000e 0000:00:19.0: irq 507 for MSI/MSI-X [ 1.456099] usbcore: registered new interface driver usbfs [ 1.456127] usbcore: registered new interface driver hub [ 1.456152] usbcore: registered new device driver usb [ 1.457132] uhci_hcd: USB Universal Host Controller Interface driver [ 1.458419] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.458421] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after [ 1.487815] SCSI subsystem initialized [ 1.504779] ohci1394 0000:02:06.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 1.536073] libata version 3.00 loaded. [ 1.557517] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[e4102000-e41027ff] Max Packet=[2048] IR/IT contexts=[4/4] [ 1.662421] 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1a:4b:7a:9d:98 [ 1.662423] 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection [ 1.662451] 0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff [ 1.662688] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.662696] uhci_hcd 0000:00:1a.0: setting latency timer to 64 [ 1.662700] uhci_hcd 0000:00:1a.0: UHCI Host Controller [ 1.662729] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1 [ 1.662762] uhci_hcd 0000:00:1a.0: irq 16, io base 0x00005060 [ 1.662891] usb usb1: configuration #1 chosen from 1 choice [ 1.662913] hub 1-0:1.0: USB hub found [ 1.662918] hub 1-0:1.0: 2 ports detected [ 1.663028] ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 1.663073] ehci_hcd 0000:00:1a.7: setting latency timer to 64 [ 1.663076] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 1.663094] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 2 [ 1.667004] ehci_hcd 0000:00:1a.7: debug port 1 [ 1.667010] ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported [ 1.667015] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe4541000 [ 1.680055] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 [ 1.680120] usb usb2: configuration #1 chosen from 1 choice [ 1.680140] hub 2-0:1.0: USB hub found [ 1.680145] hub 2-0:1.0: 4 ports detected [ 1.680246] ata_piix 0000:00:1f.1: version 2.12 [ 1.680253] ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.680283] ata_piix 0000:00:1f.1: setting latency timer to 64 [ 1.680346] scsi0 : ata_piix [ 1.680411] scsi1 : ata_piix [ 1.680945] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x5100 irq 14 [ 1.680947] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x5108 irq 15 [ 1.848519] ata1.00: ATAPI: MATSHITADVD-RAM UJ-860H, 1.02, max MWDMA2 [ 1.860422] ata1.00: configured for MWDMA2 [ 1.860932] ata2: port disabled. ignoring. [ 1.863071] scsi 0:0:0:0: CD-ROM MATSHITA DVD-RAM UJ-860H 1.02 PQ: 0 ANSI: 5 [ 1.863167] ahci 0000:00:1f.2: version 3.0 [ 1.863179] ahci 0000:00:1f.2: PCI INT D -> GSI 21 (level, low) -> IRQ 21 [ 1.863221] ahci 0000:00:1f.2: irq 506 for MSI/MSI-X [ 1.863276] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x1 impl SATA mode [ 1.863278] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part [ 1.863283] ahci 0000:00:1f.2: setting latency timer to 64 [ 1.863380] scsi2 : ahci [ 1.863420] scsi3 : ahci [ 1.863457] scsi4 : ahci [ 1.863501] ata3: SATA max UDMA/133 abar m2048@0xe4549000 port 0xe4549100 irq 506 [ 1.863503] ata4: DUMMY [ 1.863504] ata5: DUMMY [ 1.867699] Driver 'sr' needs updating - please use bus_type methods [ 1.872325] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [ 1.872327] Uniform CD-ROM driver Revision: 3.20 [ 1.872391] sr 0:0:0:0: Attached scsi CD-ROM sr0 [ 1.875214] sr 0:0:0:0: Attached scsi generic sg0 type 5 [ 2.000085] Clocksource tsc unstable (delta = -388648499 ns) [ 2.104082] usb 2-2: new high speed USB device using ehci_hcd and address 3 [ 2.180095] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.182401] ata3.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out [ 2.182404] ata3.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out [ 2.182631] ata3.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded [ 2.182634] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out [ 2.183369] ata3.00: ATA-8: Hitachi HTS722012K9SA00, DCCOC60A, max UDMA/100 [ 2.183371] ata3.00: 234441648 sectors, multi 16: LBA48 [ 2.185869] ata3.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out [ 2.185871] ata3.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out [ 2.186907] ata3.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded [ 2.186909] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out [ 2.187654] ata3.00: configured for UDMA/100 [ 2.201788] ata3.00: configured for UDMA/100 [ 2.201790] ata3: EH complete [ 2.201858] scsi 2:0:0:0: Direct-Access ATA Hitachi HTS72201 DCCO PQ: 0 ANSI: 5 [ 2.201969] scsi 2:0:0:0: Attached scsi generic sg1 type 0 [ 2.202199] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 2.202208] uhci_hcd 0000:00:1a.1: setting latency timer to 64 [ 2.202212] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 2.202235] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3 [ 2.202271] uhci_hcd 0000:00:1a.1: irq 17, io base 0x00005080 [ 2.202346] usb usb3: configuration #1 chosen from 1 choice [ 2.202368] hub 3-0:1.0: USB hub found [ 2.202374] hub 3-0:1.0: 2 ports detected [ 2.202484] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [ 2.202511] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 2.202514] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 2.202532] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4 [ 2.206452] ehci_hcd 0000:00:1d.7: debug port 1 [ 2.206459] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported [ 2.206471] ehci_hcd 0000:00:1d.7: irq 20, io mem 0xe4548000 [ 2.209609] Driver 'sd' needs updating - please use bus_type methods [ 2.209678] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB) [ 2.209690] sd 2:0:0:0: [sda] Write Protect is off [ 2.209692] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.209710] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.209754] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB) [ 2.209765] sd 2:0:0:0: [sda] Write Protect is off [ 2.209766] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 2.209784] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.209787] sda: sda1 sda2 [ 2.227331] sd 2:0:0:0: [sda] Attached SCSI disk [ 2.228017] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 [ 2.228102] usb usb4: configuration #1 chosen from 1 choice [ 2.228124] hub 4-0:1.0: USB hub found [ 2.228130] hub 4-0:1.0: 6 ports detected [ 2.228470] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [ 2.228479] uhci_hcd 0000:00:1d.0: setting latency timer to 64 [ 2.228483] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 2.228504] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5 [ 2.228529] uhci_hcd 0000:00:1d.0: irq 20, io base 0x000050a0 [ 2.228602] usb usb5: configuration #1 chosen from 1 choice [ 2.228622] hub 5-0:1.0: USB hub found [ 2.228628] hub 5-0:1.0: 2 ports detected [ 2.228724] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22 [ 2.228730] uhci_hcd 0000:00:1d.1: setting latency timer to 64 [ 2.228733] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 2.228753] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6 [ 2.228787] uhci_hcd 0000:00:1d.1: irq 22, io base 0x000050c0 [ 2.228861] usb usb6: configuration #1 chosen from 1 choice [ 2.228882] hub 6-0:1.0: USB hub found [ 2.228887] hub 6-0:1.0: 2 ports detected [ 2.228984] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 2.228991] uhci_hcd 0000:00:1d.2: setting latency timer to 64 [ 2.228993] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 2.229010] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7 [ 2.229038] uhci_hcd 0000:00:1d.2: irq 18, io base 0x000050e0 [ 2.229107] usb usb7: configuration #1 chosen from 1 choice [ 2.229127] hub 7-0:1.0: USB hub found [ 2.229131] hub 7-0:1.0: 2 ports detected [ 2.237557] usb 2-2: configuration #1 chosen from 1 choice [ 2.237735] hub 2-2:1.0: USB hub found [ 2.237825] hub 2-2:1.0: 4 ports detected [ 2.349074] usb 2-4: new high speed USB device using ehci_hcd and address 4 [ 2.489969] usb 2-4: configuration #1 chosen from 1 choice [ 2.490202] hub 2-4:1.0: USB hub found [ 2.490326] hub 2-4:1.0: 4 ports detected [ 2.732062] usb 1-1: new full speed USB device using uhci_hcd and address 2 [ 2.828112] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00023f9929ed5e0e] [ 2.901892] usb 1-1: configuration #1 chosen from 1 choice [ 3.368051] usb 5-2: new full speed USB device using uhci_hcd and address 2 [ 3.529675] usb 5-2: configuration #1 chosen from 1 choice [ 7.944916] PM: Starting manual resume from disk [ 7.944918] PM: Resume from partition 254:1 [ 7.944920] PM: Checking hibernation image. [ 7.945153] PM: Resume from disk failed. [ 7.949770] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled [ 7.956297] Filesystem "dm-2": Disabling barriers, trial barrier write failed [ 7.960272] XFS mounting filesystem dm-2 [ 8.134642] Starting XFS recovery on filesystem: dm-2 (logdev: internal) [ 12.648093] Ending XFS recovery on filesystem: dm-2 (logdev: internal) [ 22.741925] udevd version 124 started [ 23.425470] ata3.00: configured for UDMA/100 [ 23.425473] ata3: EH complete [ 23.439110] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB) [ 23.449905] sd 2:0:0:0: [sda] Write Protect is off [ 23.449907] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 23.460714] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 24.017259] device-mapper: multipath: version 1.0.5 loaded [ 24.087433] iTCO_vendor_support: vendor-support=0 [ 24.132681] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.04 [ 24.132840] iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060) [ 24.132952] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 24.532110] cfg80211: Calling CRDA to update world regulatory domain [ 24.581608] input: PC Speaker as /class/input/input1 [ 24.697312] Bluetooth: Core ver 2.13 [ 24.697773] NET: Registered protocol family 31 [ 24.697774] Bluetooth: HCI device and connection manager initialized [ 24.697777] Bluetooth: HCI socket layer initialized [ 24.733401] yenta_cardbus 0000:02:06.0: CardBus bridge found [103c:30c5] [ 24.744768] input: Power Button (FF) as /class/input/input2 [ 24.747457] ACPI: AC Adapter [C1F2] (on-line) [ 24.777144] ACPI: Power Button (FF) [PWRF] [ 24.861851] yenta_cardbus 0000:02:06.0: ISA IRQ mask 0x0cb8, PCI irq 16 [ 24.861855] yenta_cardbus 0000:02:06.0: Socket status: 30000006 [ 24.861860] yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge I/O window: 0x6000 - 0x6fff [ 24.861862] yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0xe4100000 - 0xe43fffff [ 24.861865] yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0xc4000000 - 0xcbffffff [ 24.863537] ACPI: Battery Slot [C1F4] (battery present) [ 24.863605] input: Sleep Button (CM) as /class/input/input3 [ 24.888888] yenta_cardbus 0000:02:06.1: CardBus bridge found [103c:30c5] [ 24.893139] ACPI: Sleep Button (CM) [C274] [ 24.893212] ACPI: WMI: Mapper loaded [ 24.893458] ACPI: Battery Slot [C1F3] (battery absent) [ 24.893553] input: Lid Switch as /class/input/input4 [ 24.905164] ACPI: Lid Switch [C26E] [ 24.910927] acpi device:03: registered as cooling_device13 [ 24.911872] input: Video Bus as /class/input/input5 [ 24.924010] logips2pp: Detected unknown logitech mouse model 62 [ 24.937100] ACPI: Video Device [C14B] (multi-head: yes rom: no post: no) [ 25.007398] tpm_inf_pnp 00:04: Found C239 with ID IFX0102 [ 25.007447] tpm_inf_pnp 00:04: TPM found: config base 0x560, data base 0x570, chip version 0x000b, vendor id 0x15d1 (Infineon), product id 0x000b (SLB 9635 TT 1.2) [ 25.017857] yenta_cardbus 0000:02:06.1: ISA IRQ mask 0x0000, PCI irq 17 [ 25.017861] yenta_cardbus 0000:02:06.1: Socket status: 30000810 [ 25.017864] pci_bus 0000:02: Raising subordinate bus# of parent bus (#02) from #04 to #07 [ 25.017871] yenta_cardbus 0000:02:06.1: pcmcia: parent PCI bridge I/O window: 0x6000 - 0x6fff [ 25.017874] yenta_cardbus 0000:02:06.1: pcmcia: parent PCI bridge Memory window: 0xe4100000 - 0xe43fffff [ 25.017876] yenta_cardbus 0000:02:06.1: pcmcia: parent PCI bridge Memory window: 0xc4000000 - 0xcbffffff [ 25.027606] Registered led device: hp:red:hddprotection [ 25.027627] leds-hp-disk driver loaded. [ 25.052821] lis3lv02d driver loaded. [ 25.118421] sdhci: Secure Digital Host Controller Interface driver [ 25.118423] sdhci: Copyright(c) Pierre Ossman [ 25.128706] sdhci-pci 0000:02:06.3: SDHCI controller found [1180:0822] (rev 20) [ 25.128723] sdhci-pci 0000:02:06.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19 [ 25.130823] mmc0: SDHCI controller on PCI [0000:02:06.3] using PIO [ 25.288824] ricoh-mmc: Ricoh MMC Controller disabling driver [ 25.288826] ricoh-mmc: Copyright(c) Philip Langdale [ 25.288853] ricoh-mmc: Ricoh MMC controller found at 0000:02:06.4 [1180:0843] (rev 10) [ 25.288870] ricoh-mmc: Controller is now disabled. [ 25.322983] Bluetooth: Generic Bluetooth USB driver ver 0.3 [ 25.323074] usbcore: registered new interface driver btusb [ 25.365086] parport_pc 00:03: reported by Plug and Play ACPI [ 25.365163] parport0: PC-style at 0x378 (0x778), irq 7, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA] [ 25.467478] input: ImExPS/2 Logitech Explorer Mouse as /class/input/input6 [ 25.550689] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks [ 25.550692] iwlagn: Copyright(c) 2003-2008 Intel Corporation [ 25.550802] iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 25.550829] iwlagn 0000:10:00.0: setting latency timer to 64 [ 25.550925] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4 [ 25.600883] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels [ 25.601217] iwlagn 0000:10:00.0: PCI INT A disabled [ 25.601649] phy0: Selected rate control algorithm 'iwl-agn-rs' [ 25.664045] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 [ 25.680474] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0 [ 25.680483] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 25.680545] HDA Intel 0000:00:1b.0: setting latency timer to 64 [ 25.738607] cfg80211: Calling CRDA for country: IT [ 25.773840] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 25.773881] HDA Intel 0000:01:00.1: setting latency timer to 64 [ 25.904059] pcmcia_socket pcmcia_socket1: cs: memory probe 0xc4000000-0xcbffffff: excluding 0xc4000000-0xcbffffff [ 25.904076] pcmcia_socket pcmcia_socket1: cs: memory probe 0xe4100000-0xe43fffff: excluding 0xe4100000-0xe412ffff [ 25.909136] pcmcia 1.0: pcmcia: registering new device pcmcia1.0 [ 26.066601] loop: module loaded [ 26.177484] input: HP WMI hotkeys as /class/input/input7 [ 26.321347] Adding 8388600k swap on /dev/mapper/vol00-swap. Priority:-1 extents:1 across:8388600k [ 27.419998] kjournald starting. Commit interval 5 seconds [ 27.435908] EXT3 FS on sda1, internal journal [ 27.435912] EXT3-fs: mounted filesystem with ordered data mode. [ 28.314398] ip_tables: (C) 2000-2006 Netfilter Core Team [ 28.366461] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 28.366587] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [ 28.366589] nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or [ 28.366591] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. [ 28.506251] NET: Registered protocol family 10 [ 28.506608] lo: Disabled Privacy Extensions [ 28.529973] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 31.100349] warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) [ 45.466386] Bluetooth: L2CAP ver 2.11 [ 45.466392] Bluetooth: L2CAP socket layer initialized [ 45.482326] Bluetooth: SCO (Voice Link) ver 0.6 [ 45.482332] Bluetooth: SCO socket layer initialized [ 45.510091] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 45.510096] Bluetooth: BNEP filters: protocol multicast [ 45.604693] Bridge firewalling registered [ 45.770269] Bluetooth: RFCOMM socket layer initialized [ 45.770289] Bluetooth: RFCOMM TTY layer initialized [ 45.770293] Bluetooth: RFCOMM ver 1.10 [ 48.345342] pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 50.229400] e1000e 0000:00:19.0: irq 507 for MSI/MSI-X [ 50.285113] e1000e 0000:00:19.0: irq 507 for MSI/MSI-X [ 50.287628] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 50.293294] iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 50.293435] iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006) [ 50.293603] iwlagn 0000:10:00.0: irq 505 for MSI/MSI-X [ 50.293716] iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode [ 50.672582] Registered led device: iwl-phy0:radio [ 50.672633] Registered led device: iwl-phy0:assoc [ 50.672675] Registered led device: iwl-phy0:RX [ 50.672715] Registered led device: iwl-phy0:TX [ 50.719532] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 50.883031] NET: Registered protocol family 17 [ 53.321650] 0000:00:19.0: eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 53.324025] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 64.200057] eth0: no IPv6 routers present [ 96.641005] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43174 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 160.850430] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1745 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 161.070169] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1746 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 161.510215] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1747 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 162.390195] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1748 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 164.153112] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1749 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 167.670102] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1750 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 174.709996] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1751 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 179.855841] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0f:66:c7:99:59:08:00 SRC=10.151.1.253 DST=10.151.1.19 LEN=74 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=43358 LEN=54 [ 188.789791] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1752 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 214.399488] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43175 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 216.949491] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1753 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 273.268775] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1754 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 281.058556] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. [ 322.731076] CE: hpet increasing min_delta_ns to 15000 nsec [ 334.398018] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43176 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 385.907513] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1755 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 397.713478] usb 4-6: new high speed USB device using ehci_hcd and address 3 [ 397.845605] usb 4-6: configuration #1 chosen from 1 choice [ 397.942505] usbcore: registered new interface driver libusual [ 397.980025] Initializing USB Mass Storage driver... [ 397.983213] scsi5 : SCSI emulation for USB Mass Storage devices [ 397.983980] usbcore: registered new interface driver usb-storage [ 397.983987] USB Mass Storage support registered. [ 397.988213] usb-storage: device found at 3 [ 397.988218] usb-storage: waiting for device to settle before scanning [ 402.992484] usb-storage: device scan complete [ 402.993050] scsi 5:0:0:0: Direct-Access Maxtor OneTouch 0125 PQ: 0 ANSI: 4 [ 402.997591] sd 5:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB) [ 402.998221] sd 5:0:0:0: [sdb] Write Protect is off [ 402.998226] sd 5:0:0:0: [sdb] Mode Sense: 2d 08 00 00 [ 402.998231] sd 5:0:0:0: [sdb] Assuming drive cache: write through [ 402.998968] sd 5:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB) [ 402.999589] sd 5:0:0:0: [sdb] Write Protect is off [ 402.999594] sd 5:0:0:0: [sdb] Mode Sense: 2d 08 00 00 [ 402.999599] sd 5:0:0:0: [sdb] Assuming drive cache: write through [ 402.999606] sdb: sdb1 [ 403.023424] sd 5:0:0:0: [sdb] Attached SCSI disk [ 403.023689] sd 5:0:0:0: Attached scsi generic sg2 type 0 [ 403.986658] EXT4-fs: barriers enabled [ 404.004362] kjournald2 starting. Commit interval 5 seconds [ 404.004991] EXT4 FS on sdb1, internal journal on sdb1:8 [ 404.004994] EXT4-fs: delayed allocation enabled [ 404.004997] EXT4-fs: file extents enabled [ 404.006118] EXT4-fs: mballoc enabled [ 404.006122] EXT4-fs: mounted filesystem with ordered data mode. [ 454.396873] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43177 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 505.906321] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1756 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 574.395750] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43178 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 625.905228] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1757 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 694.394609] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43179 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 745.904079] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1758 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 814.393356] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=160 TOS=0x00 PREC=0x00 TTL=64 ID=43180 DF PROTO=TCP SPT=4001 DPT=46026 WINDOW=46 RES=0x00 ACK PSH URGP=0 [ 865.902829] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1759 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 985.901614] [UFW BLOCK INPUT]: IN=eth0 OUT= MAC=00:1a:4b:7a:9d:98:00:0e:a6:6e:a0:6d:08:00 SRC=10.151.1.3 DST=10.151.1.19 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=1760 DF PROTO=TCP SPT=139 DPT=45432 WINDOW=4106 RES=0x00 ACK PSH URGP=0 [ 1266.661123] CE: hpet increasing min_delta_ns to 22500 nsec [ 1372.084275] usb 2-2.1: new high speed USB device using ehci_hcd and address 5 [ 1372.177908] usb 2-2.1: configuration #1 chosen from 1 choice [ 1372.178581] scsi6 : SCSI emulation for USB Mass Storage devices [ 1372.182128] usb-storage: device found at 5 [ 1372.182133] usb-storage: waiting for device to settle before scanning [ 1377.180370] usb-storage: device scan complete [ 1377.180940] scsi 6:0:0:0: Direct-Access Maxtor 7Y250P0 YAR4 PQ: 0 ANSI: 2 [ 1377.185402] sd 6:0:0:0: [sdc] 490234752 512-byte hardware sectors: (251 GB/233 GiB) [ 1377.205719] sd 6:0:0:0: [sdc] Write Protect is off [ 1377.205727] sd 6:0:0:0: [sdc] Mode Sense: 53 00 00 08 [ 1377.205732] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 1377.207893] sd 6:0:0:0: [sdc] 490234752 512-byte hardware sectors: (251 GB/233 GiB) [ 1377.228773] sd 6:0:0:0: [sdc] Write Protect is off [ 1377.228781] sd 6:0:0:0: [sdc] Mode Sense: 53 00 00 08 [ 1377.228786] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 1377.228796] sdc: sdc1 [ 1377.258122] sd 6:0:0:0: [sdc] Attached SCSI disk [ 1377.258340] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 1386.162372] EXT4-fs: barriers enabled [ 1386.185313] kjournald2 starting. Commit interval 5 seconds [ 1386.186462] EXT4 FS on sdc1, internal journal on sdc1:8 [ 1386.186469] EXT4-fs: delayed allocation enabled [ 1386.186474] EXT4-fs: file extents enabled [ 1386.188032] EXT4-fs: mballoc enabled [ 1386.188044] EXT4-fs: mounted filesystem with ordered data mode. [ 1706.061104] CE: hpet increasing min_delta_ns to 33750 nsec [ 3393.941105] CE: hpet increasing min_delta_ns to 50624 nsec --=-6a4h5iZZAGcv53WKxFWU-- From cattelan@thebarn.com Sat Feb 7 07:40: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 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 n17DeHCw103055 for ; Sat, 7 Feb 2009 07:40:18 -0600 X-ASG-Debug-ID: 1234013978-117701810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from slurp.thebarn.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA541F8339; Sat, 7 Feb 2009 05:39:39 -0800 (PST) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by cuda.sgi.com with ESMTP id wzGF6VuGrZEZlEqi; Sat, 07 Feb 2009 05:39:39 -0800 (PST) Received: from funky.thebarn.com (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.3/8.14.0) with ESMTP id n17De92r095888; Sat, 7 Feb 2009 07:40:10 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <498D8F18.3080903@thebarn.com> Date: Sat, 07 Feb 2009 07:39:36 -0600 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: Mark Goodwin , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Gary Hagensen , George Beshers , John Hesterberg , xfs-oss , xfs-dev , Tony Ernst , Ric Wheeler 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> <20090205112906.GB11781@infradead.org> In-Reply-To: <20090205112906.GB11781@infradead.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/8835/Sun Jan 4 21:47:36 2009 on slurp.thebarn.com X-Virus-Status: Clean X-Barracuda-Connect: cattelan-host202.dsl.visi.com[208.42.117.202] X-Barracuda-Start-Time: 1234013979 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.17255 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Hellwig 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 > > Russell, can you add this to the list of repositories to be displayed on > > http://oss.sgi.com/cgi-bin/gitweb.cgi or maybe we should just update the existing xfs-website tree? http://oss.sgi.com/cgi-bin/gitweb.cgi?p=cattelan/xfs-website/.git;a=summary > > ? > > 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? > I moved cvsimported xfs-import dmapi-import and xfs-cmds under archive. > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJjY8YNRmM+OaGhBgRAk6+AJsGq0ADiAlx72Cty2k6oyGBjdhxLgCfdXEc CJwYfoMTGJxycuLpCvACU4c= =81ro -----END PGP SIGNATURE----- From kevin.dual@gmail.com Sat Feb 7 14:46: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.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_56 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 n17KkgaM126711 for ; Sat, 7 Feb 2009 14:46:43 -0600 X-ASG-Debug-ID: 1234039563-5036039c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wombat.diezmil.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B3E9518E9E80 for ; Sat, 7 Feb 2009 12:46:03 -0800 (PST) Received: from wombat.diezmil.com (aa.81.b6.static.xlhost.com [207.182.129.170]) by cuda.sgi.com with ESMTP id cSRzZn9ACLWJQE1y for ; Sat, 07 Feb 2009 12:46:03 -0800 (PST) Received: from wombat.diezmil.com (wombat.diezmil.com [127.0.0.1]) by wombat.diezmil.com (8.14.2/8.14.2) with ESMTP id n17Kk1dk011752 for ; Sat, 7 Feb 2009 15:46:01 -0500 Date: Sat, 7 Feb 2009 15:46:01 -0500 From: kevin.dual@gmail.com Reply-To: kevin.dual@gmail.com To: xfs@oss.sgi.com Message-ID: <22271900.11234039561556.JavaMail.root@wombat.diezmil.com> In-Reply-To: X-ASG-Orig-Subj: Re: Power loss causes bad magic number?? Subject: Re: Power loss causes bad magic number?? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: aa.81.b6.static.xlhost.com[207.182.129.170] X-Barracuda-Start-Time: 1234039564 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.62 X-Barracuda-Spam-Status: No, SCORE=-1.62 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085b, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17283 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.40 BSF_SC0_SA085b Custom Rule SA085b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I'm having a very similar problem... My 1TB RAID-5 array formatted with XFS assembles, but refuses to mount: -------------------------------------------------- $ dmesg ... [19827.704838] XFS: bad magic number [19827.704847] XFS: SB validate failed -------------------------------------------------- $ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdd1[2] sdc1[1] sdb1[0] 976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] unused devices: -------------------------------------------------- $ sudo parted -l Model: ATA ST3500641AS (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 480GB 480GB primary ext3 boot 2 480GB 500GB 20.3GB extended 5 480GB 500GB 20.3GB logical linux-swap Model: ATA ST3500641AS (scsi) Disk /dev/sdb: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 500GB 500GB primary raid Model: ATA ST3500641AS (scsi) Disk /dev/sdc: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 500GB 500GB primary raid Model: ATA ST3500641AS (scsi) Disk /dev/sdd: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 500GB 500GB primary raid Error: /dev/md0: unrecognised disk label -------------------------------------------------- $ sudo xfs_check /dev/md0 xfs_check: unexpected XFS SB magic number 0x110812af cache_node_purge: refcount was 1, not zero (node=0x1300220) xfs_check: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x1300440) xfs_check: cannot read realtime bitmap inode (22) Segmentation fault $ sudo xfs_check /dev/sdb1 xfs_check: unexpected XFS SB magic number 0x110812af cache_node_purge: refcount was 1, not zero (node=0x2213220) xfs_check: cannot read root inode (22) bad superblock magic number 110812af, giving up $ sudo xfs_check /dev/sdc1 cache_node_purge: refcount was 1, not zero (node=0x2377220) xfs_check: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x2377440) xfs_check: cannot read realtime bitmap inode (22) Segmentation fault $ sudo xfs_check /dev/sdd1 xfs_check: unexpected XFS SB magic number 0x494e41ed xfs_check: size check failed xfs_check: read failed: Invalid argument xfs_check: data size check failed cache_node_purge: refcount was 1, not zero (node=0x24f1c20) xfs_check: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x24f1d70) xfs_check: cannot read realtime bitmap inode (22) Segmentation fault -------------------------------------------------- $ sudo xfs_repair -n /dev/md0 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...etc...etc...fail fail fail $ sudo xfs_repair -n /dev/sdb1 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...etc...etc...fail fail fail $ sudo xfs_repair -n /dev/sdc1 Phase 1 - find and verify superblock... error reading superblock 17 -- seek to offset 531361234944 failed couldn't verify primary superblock - bad magic number !!! attempting to find secondary superblock... ...found candidate secondary superblock... error reading superblock 17 -- seek to offset 531361234944 failed unable to verify superblock, continuing... ...etc...etc...fail fail fail you know the routine... -------------------------------------------------- $ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep XFSB 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s $ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep XFSB 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00 |XFSB............| 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s $ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep XFSB 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s Looks like /dev/sdc is the only one with any recognizable superblock data on it. -------------------------------------------------- Now what should I do with all this information? The array assembles fine, but the XFS volume seems to be screwed up somehow. Is there any way the array could have put itself together wrong then re-synced and corrupted all my data? -- This message was sent on behalf of kevin.dual@gmail.com at openSubscriber.com http://www.opensubscriber.com/message/xfs@oss.sgi.com/9638260.html From sandeen@sandeen.net Sat Feb 7 15:17: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,J_CHICKENPOX_56 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 n17LHCrB128871 for ; Sat, 7 Feb 2009 15:17:12 -0600 X-ASG-Debug-ID: 1234041393-7f7500f10000-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 0C479F9689 for ; Sat, 7 Feb 2009 13:16:33 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id G26s1jhob1GeFuHe for ; Sat, 07 Feb 2009 13:16: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 n17LA73U019950; Sat, 7 Feb 2009 16:10:07 -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 n17LA722029105; Sat, 7 Feb 2009 16:10:07 -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 n17LA6o1021977; Sat, 7 Feb 2009 16:10:07 -0500 Message-ID: <498DF8AD.3020903@sandeen.net> Date: Sat, 07 Feb 2009 15:10:05 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: kevin.dual@gmail.com CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Power loss causes bad magic number?? Subject: Re: Power loss causes bad magic number?? References: <22271900.11234039561556.JavaMail.root@wombat.diezmil.com> In-Reply-To: <22271900.11234039561556.JavaMail.root@wombat.diezmil.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: 1234041395 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.17285 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 kevin.dual@gmail.com wrote: > I'm having a very similar problem... My 1TB RAID-5 array formatted with XFS assembles, but refuses to mount: ... > $ cat /proc/mdstat > Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] > md0 : active raid5 sdd1[2] sdc1[1] sdb1[0] > 976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] > > unused devices: ... > -------------------------------------------------- > $ sudo xfs_check /dev/md0 > xfs_check: unexpected XFS SB magic number 0x110812af > cache_node_purge: refcount was 1, not zero (node=0x1300220) > xfs_check: cannot read root inode (22) > cache_node_purge: refcount was 1, not zero (node=0x1300440) > xfs_check: cannot read realtime bitmap inode (22) > Segmentation fault hm, ok... but below you don't expect each component drive to be a consistent xfs fs do you? It's not a mirror :) > $ sudo xfs_check /dev/sdb1 > xfs_check: unexpected XFS SB magic number 0x110812af > cache_node_purge: refcount was 1, not zero (node=0x2213220) > xfs_check: cannot read root inode (22) > bad superblock magic number 110812af, giving up > > $ sudo xfs_check /dev/sdc1 > cache_node_purge: refcount was 1, not zero (node=0x2377220) > xfs_check: cannot read root inode (22) > cache_node_purge: refcount was 1, not zero (node=0x2377440) > xfs_check: cannot read realtime bitmap inode (22) > Segmentation fault > > $ sudo xfs_check /dev/sdd1 > xfs_check: unexpected XFS SB magic number 0x494e41ed > xfs_check: size check failed > xfs_check: read failed: Invalid argument > xfs_check: data size check failed > cache_node_purge: refcount was 1, not zero (node=0x24f1c20) > xfs_check: cannot read root inode (22) > cache_node_purge: refcount was 1, not zero (node=0x24f1d70) > xfs_check: cannot read realtime bitmap inode (22) > Segmentation fault > none of the above surprises me > -------------------------------------------------- > $ sudo xfs_repair -n /dev/md0 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > > attempting to find secondary superblock... > ...etc...etc...fail fail fail Ok so above is the real problem. again below is not expected to work! > $ sudo xfs_repair -n /dev/sdb1 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > > attempting to find secondary superblock... > ...etc...etc...fail fail fail > > $ sudo xfs_repair -n /dev/sdc1 > Phase 1 - find and verify superblock... > error reading superblock 17 -- seek to offset 531361234944 failed > couldn't verify primary superblock - bad magic number !!! > > attempting to find secondary superblock... > ...found candidate secondary superblock... > error reading superblock 17 -- seek to offset 531361234944 failed > unable to verify superblock, continuing... > ...etc...etc...fail fail fail > > you know the routine... > > > -------------------------------------------------- > $ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep XFSB > 128+0 records in > 128+0 records out > 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s > > $ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep XFSB > 128+0 records in > 128+0 records out > 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s > > $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB > 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00 |XFSB............| ibase=16 7E00 32256, or 63x512 and sdc was: > Model: ATA ST3500641AS (scsi) > Disk /dev/sdc: 500GB > Sector size (logical/physical): 512B/512B > Partition Table: msdos > > Number Start End Size Type File system Flags > 1 32.3kB 500GB 500GB primary raid IOW the normal msdos 63 sectors. > 128+0 records in > 128+0 records out > 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s > > $ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep XFSB > 128+0 records in > 128+0 records out > 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s > > Looks like /dev/sdc is the only one with any recognizable superblock data on it. > -------------------------------------------------- > > Now what should I do with all this information? The array assembles fine, but the XFS volume seems to be screwed up somehow. Is there any way the array could have put itself together wrong then re-synced and corrupted all my data? It seems like maybe it assembled out of order, as if sdc1 should be the first drive, since it has the magic at the right place. Dunno how much damage could have been done, or if you can just try to fix the assembly perhaps...? -Eric From sandeen@sandeen.net Sat Feb 7 16:47: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.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 n17MlBA7133771 for ; Sat, 7 Feb 2009 16:47:12 -0600 X-ASG-Debug-ID: 1234046793-5230002d0000-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 72410F9B6A for ; Sat, 7 Feb 2009 14:46:33 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id SVwinbbRBsOdIW9V for ; Sat, 07 Feb 2009 14:46: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 n17LsD22026046; Sat, 7 Feb 2009 16:54:13 -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 n17LsDEr001276; Sat, 7 Feb 2009 16:54: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 n17LsCNm029172; Sat, 7 Feb 2009 16:54:12 -0500 Message-ID: <498E0303.5000204@sandeen.net> Date: Sat, 07 Feb 2009 15:54:11 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: kevin.dual@gmail.com CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Power loss causes bad magic number?? Subject: Re: Power loss causes bad magic number?? References: <22271900.11234039561556.JavaMail.root@wombat.diezmil.com> <498DF8AD.3020903@sandeen.net> In-Reply-To: <498DF8AD.3020903@sandeen.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: 1234046794 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.17291 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: > Dunno how much damage could have been done, or if you can just try to > fix the assembly perhaps...? > > -Eric FWIW on a 3-disk raid5: [root@inode tmp]# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 loop3[2] loop2[1] loop1[0] 262016 blocks level 5, 4k chunk, algorithm 2 [3/3] [UUU] unused devices: it's the 0th device which should have the superblock: [root@inode tmp]# file -s /dev/loop[123] /dev/loop1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) /dev/loop2: data /dev/loop3: data whereas yours was the 1st (not 0th) (I wasn't sure how mdstat showed the order so double checked...) -Eric From felixb@sgi.com Sat Feb 7 18:37:40 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 n180bd4R140062 for ; Sat, 7 Feb 2009 18:37:40 -0600 Received: from [IPv6:::1] (sshcf.sgi.com [198.149.20.12]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6874EAC003; Sat, 7 Feb 2009 16:36:59 -0800 (PST) In-Reply-To: <20090126073203.169959000@bombadil.infradead.org> References: <20090126073136.384490000@bombadil.infradead.org> <20090126073203.169959000@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: Cc: xfs@oss.sgi.com Content-Transfer-Encoding: 7bit From: Felix Blyakher Subject: Re: [PATCH 14/17] xfs: remove the unused XFS_QMOPT_DQLOCK flag Date: Sat, 7 Feb 2009 18:35:57 -0600 To: Christoph Hellwig 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: > The XFS_QMOPT_DQLOCK flag introduces major complexity in the quota > subsystem > but isn't actually used anywhere. So remove it and all the hazzles it > introduces. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher From kevin.dual@gmail.com Sun Feb 8 00:11:02 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, J_CHICKENPOX_53,J_CHICKENPOX_56 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 n186B1oT156480 for ; Sun, 8 Feb 2009 00:11:02 -0600 X-ASG-Debug-ID: 1234073422-071a01240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-gx0-f21.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB30E18E7AEC for ; Sat, 7 Feb 2009 22:10:22 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by cuda.sgi.com with ESMTP id xICnLHxAwUACVX0F for ; Sat, 07 Feb 2009 22:10:22 -0800 (PST) Received: by gxk14 with SMTP id 14so1378520gxk.20 for ; Sat, 07 Feb 2009 22:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7Jf91MEA1FjgiX9x/t2gDcbL1vvoXazPL0D+9Oi57DU=; b=UQDO8t1ZL99j4gBxvY0iISkA2jxERvbqrHDeuvOwKdhFFZWuelpcslRuTBGdVJ9Bun py1S764k9plajzWulxp4F22E0e+ucJtH1EGBBzZkDDHuAvtWK79p5/uwT0+dT3YKRbMy IUglrDQQw1CMIq5rjL6eRwznXJDb2SiCetVSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rjbu1offdj7pBlJ79c+dlCwSZbCi7grrmzV3wmycyfgUJalhZweg7gspAcq/zl1r3z Ila34Uf0m2yyj2SnF46l5C4vQuCfkq+bI9xaQpwZrxEgQS53S3+euzVjzAVJ4TKJWEx3 uNQEW8fLjya3uA/1B07E3jaKvjr/v3nO2bUaY= MIME-Version: 1.0 Received: by 10.150.149.19 with SMTP id w19mr2021014ybd.18.1234073422199; Sat, 07 Feb 2009 22:10:22 -0800 (PST) In-Reply-To: <498DF8AD.3020903@sandeen.net> References: <22271900.11234039561556.JavaMail.root@wombat.diezmil.com> <498DF8AD.3020903@sandeen.net> Date: Sun, 8 Feb 2009 00:10:22 -0600 Message-ID: <68685c7a0902072210w5d96bfa2h81b89ee238a09d15@mail.gmail.com> X-ASG-Orig-Subj: Re: Power loss causes bad magic number?? Subject: Re: Power loss causes bad magic number?? From: Kevin Dual To: Eric Sandeen Cc: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=000e0cd487baf4fdad0462621b11 X-Barracuda-Connect: mail-gx0-f21.google.com[209.85.217.21] X-Barracuda-Start-Time: 1234073423 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=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17318 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 --000e0cd487baf4fdad0462621b11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 7, 2009 at 3:10 PM, Eric Sandeen wrote: > kevin.dual@gmail.com wrote: > > I'm having a very similar problem... My 1TB RAID-5 array formatted with > XFS assembles, but refuses to mount: > > ... > > > $ cat /proc/mdstat > > Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] > [raid4] [raid10] > > md0 : active raid5 sdd1[2] sdc1[1] sdb1[0] > > 976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] > > > > unused devices: > > ... > > > > -------------------------------------------------- > > $ sudo xfs_check /dev/md0 > > xfs_check: unexpected XFS SB magic number 0x110812af > > cache_node_purge: refcount was 1, not zero (node=0x1300220) > > xfs_check: cannot read root inode (22) > > cache_node_purge: refcount was 1, not zero (node=0x1300440) > > xfs_check: cannot read realtime bitmap inode (22) > > Segmentation fault > > hm, ok... > > but below you don't expect each component drive to be a consistent xfs > fs do you? It's not a mirror :) Actually, I did not expect each component drive to be a consistent xfs file system, I was just trying to gather as much information as possible. I'm glad I did because it was running "sudo dd if=/dev/sd* bs=512 count=128 iflag=direct | hexdump -C | grep XFSB" on all my drives that showed which drive had the xfs info on it and allowed you to suggest that I try creating the array with that drive first: $ sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 --assume-clean /dev/sdc1 /dev/sdd1 /dev/sdb1 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009 Continue creating array? y mdadm: array /dev/md0 started. $ sudo mount -t xfs /dev/md0 test $ cd test /test$ ls ALL MY DATA! So it seems that creating a RAID-5 array in the wrong order and allowing it to sync does not destroy the data, which is very to know ;P Thank you very much for your help! > > > $ sudo xfs_check /dev/sdb1 > > xfs_check: unexpected XFS SB magic number 0x110812af > > cache_node_purge: refcount was 1, not zero (node=0x2213220) > > xfs_check: cannot read root inode (22) > > bad superblock magic number 110812af, giving up > > > > $ sudo xfs_check /dev/sdc1 > > cache_node_purge: refcount was 1, not zero (node=0x2377220) > > xfs_check: cannot read root inode (22) > > cache_node_purge: refcount was 1, not zero (node=0x2377440) > > xfs_check: cannot read realtime bitmap inode (22) > > Segmentation fault > > > > $ sudo xfs_check /dev/sdd1 > > xfs_check: unexpected XFS SB magic number 0x494e41ed > > xfs_check: size check failed > > xfs_check: read failed: Invalid argument > > xfs_check: data size check failed > > cache_node_purge: refcount was 1, not zero (node=0x24f1c20) > > xfs_check: cannot read root inode (22) > > cache_node_purge: refcount was 1, not zero (node=0x24f1d70) > > xfs_check: cannot read realtime bitmap inode (22) > > Segmentation fault > > > > none of the above surprises me > > > -------------------------------------------------- > > $ sudo xfs_repair -n /dev/md0 > > Phase 1 - find and verify superblock... > > bad primary superblock - bad magic number !!! > > > > attempting to find secondary superblock... > > ...etc...etc...fail fail fail > > Ok so above is the real problem. > > again below is not expected to work! > > > $ sudo xfs_repair -n /dev/sdb1 > > Phase 1 - find and verify superblock... > > bad primary superblock - bad magic number !!! > > > > attempting to find secondary superblock... > > ...etc...etc...fail fail fail > > > > $ sudo xfs_repair -n /dev/sdc1 > > Phase 1 - find and verify superblock... > > error reading superblock 17 -- seek to offset 531361234944 failed > > couldn't verify primary superblock - bad magic number !!! > > > > attempting to find secondary superblock... > > ...found candidate secondary superblock... > > error reading superblock 17 -- seek to offset 531361234944 failed > > unable to verify superblock, continuing... > > ...etc...etc...fail fail fail > > > > you know the routine... > > > > > > -------------------------------------------------- > > $ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep > XFSB > > 128+0 records in > > 128+0 records out > > 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s > > > > $ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep > XFSB > > 128+0 records in > > 128+0 records out > > 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s > > > > $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep > XFSB > > 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00 > |XFSB............| > > ibase=16 > 7E00 > 32256, or 63x512 > > and sdc was: > > > Model: ATA ST3500641AS (scsi) > > Disk /dev/sdc: 500GB > > Sector size (logical/physical): 512B/512B > > Partition Table: msdos > > > > Number Start End Size Type File system Flags > > 1 32.3kB 500GB 500GB primary raid > > IOW the normal msdos 63 sectors. > > > 128+0 records in > > 128+0 records out > > 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s > > > > $ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep > XFSB > > 128+0 records in > > 128+0 records out > > 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s > > > > Looks like /dev/sdc is the only one with any recognizable superblock data > on it. > > -------------------------------------------------- > > > > Now what should I do with all this information? The array assembles > fine, but the XFS volume seems to be screwed up somehow. Is there any way > the array could have put itself together wrong then re-synced and corrupted > all my data? > > It seems like maybe it assembled out of order, as if sdc1 should be the > first drive, since it has the magic at the right place. > > Dunno how much damage could have been done, or if you can just try to > fix the assembly perhaps...? > > -Eric > > --000e0cd487baf4fdad0462621b11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 7, 2009 at 3:10 PM, Eric San= deen <sandeen@s= andeen.net> wrote:
kevin.dual@gmail.com wrote:
> I'm having a very similar problem... My 1TB RAID-5 array formatted= with XFS assembles, but refuses to mount:

...

> $ cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [= raid4] [raid10]
> md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
>       976767872 blocks level 5, 64k chunk, algorithm 2 = [3/3] [UUU]
>
> unused devices: <none>

...


> --------------------------------------------------
> $ sudo xfs_check /dev/md0
> xfs_check: unexpected XFS SB magic number 0x110812af
> cache_node_purge: refcount was 1, not zero (node=3D0x1300220)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=3D0x1300440)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault

hm, ok...

but below you don't expect each component drive to be a consistent xfs<= br> fs do you?  It's not a mirror :)


Actually= , I did not expect each component drive to be a consistent xfs file system,= I was just trying to gather as much information as possible.  I'm= glad I did because it was running "sudo dd if=3D/dev/sd* bs=3D512 cou= nt=3D128 iflag=3Ddirect | hexdump -C | grep XFSB" on all my drives tha= t showed which drive had the xfs info on it and allowed you to suggest that= I try creating the array with that drive first:

$ sudo mdadm --create /dev/md0 --level=3D5 --raid-devices=3D3 --assume-= clean /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part = of a raid array:
    level=3Draid5 devices=3D3 ctime=3DFr= i Feb  6 18:01:59 2009
mdadm: /dev/sdd1 appears to be part of a raid array:
    = level=3Draid5 devices=3D3 ctime=3DFri Feb  6 18:01:59 2009
mdadm: /= dev/sdb1 appears to be part of a raid array:
    level=3D= raid5 devices=3D3 ctime=3DFri Feb  6 18:01:59 2009
Continue creating array? y
mdadm: array /dev/md0 started.

$ sudo = mount -t xfs /dev/md0 test
$ cd test
/test$ ls
ALL MY DATA!
So it seems that creating a RAID-5 array in the wrong order and allowing it to sync does not destroy the data, which is very to know  ;P

Thank you very much for your help!



> $ sudo xfs_check /dev/sdb1
> xfs_check: unexpected XFS SB magic number 0x110812af
> cache_node_purge: refcount was 1, not zero (node=3D0x2213220)
> xfs_check: cannot read root inode (22)
> bad superblock magic number 110812af, giving up
>
> $ sudo xfs_check /dev/sdc1
> cache_node_purge: refcount was 1, not zero (node=3D0x2377220)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=3D0x2377440)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault
>
> $ sudo xfs_check /dev/sdd1
> xfs_check: unexpected XFS SB magic number 0x494e41ed
> xfs_check: size check failed
> xfs_check: read failed: Invalid argument
> xfs_check: data size check failed
> cache_node_purge: refcount was 1, not zero (node=3D0x24f1c20)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=3D0x24f1d70)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault
>

none of the above surprises me

> --------------------------------------------------
> $ sudo xfs_repair -n /dev/md0
> Phase 1 - find and verify superblock...
> bad primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...etc...etc...fail fail fail

Ok so above is the real problem.

again below is not expected to work!

> $ sudo xfs_repair -n /dev/sdb1
> Phase 1 - find and verify superblock...
> bad primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...etc...etc...fail fail fail
>
> $ sudo xfs_repair -n /dev/sdc1
> Phase 1 - find and verify superblock...
> error reading superblock 17 -- seek to offset 531361234944 failed
> couldn't verify primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...found candidate secondary superblock...
> error reading superblock 17 -- seek to offset 531361234944 failed
> unable to verify superblock, continuing...
> ...etc...etc...fail fail fail
>
> you know the routine...
>
>
> --------------------------------------------------
> $ sudo dd if=3D/dev/md0 bs=3D512 count=3D128 iflag=3Ddirect | hexdump = -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s
>
> $ sudo dd if=3D/dev/sdb bs=3D512 count=3D128 iflag=3Ddirect | hexdump = -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s
>
> $ sudo dd if=3D/dev/sdc bs=3D512 count=3D128 iflag=3Ddirect | hexdump = -C | grep XFSB
> 00007e00  58 46 53 42 00 00 10 00  00 00 00 00 0e 8e 12 00 &= nbsp;|XFSB............|

ibase=3D16
7E00
32256, or 63x512

and sdc was:

> Model: ATA ST3500641AS (scsi)
> Disk /dev/sdc: 500GB
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
>
> Number  Start   End    Size   Type   &nb= sp; File system  Flags
>  1      32.3kB  500GB  500GB  prima= ry               raid

IOW the normal msdos 63 sectors.

> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s
>
> $ sudo dd if=3D/dev/sdd bs=3D512 count=3D128 iflag=3Ddirect | hexdump = -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s
>
> Looks like /dev/sdc is the only one with any recognizable superblock d= ata on it.
> --------------------------------------------------
>
> Now what should I do with all this information?  The array assemb= les fine, but the XFS volume seems to be screwed up somehow.  Is there= any way the array could have put itself together wrong then re-synced and = corrupted all my data?

It seems like maybe it assembled out of order, as if sdc1 should be the
first drive, since it has the magic at the right place.

Dunno how much damage could have been done, or if you can just try to
fix the assembly perhaps...?

-Eric


--000e0cd487baf4fdad0462621b11-- From SRS0+781a8d79da882f730615+1995+infradead.org+hch@bombadil.srs.infradead.org Sun Feb 8 15:12: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 (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n18LCjt1194955 for ; Sun, 8 Feb 2009 15:12:45 -0600 X-ASG-Debug-ID: 1234127528-0d34033c0000-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 4B1BA18F0376 for ; Sun, 8 Feb 2009 13:12:08 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LteXos0ZLDBD1UQE for ; Sun, 08 Feb 2009 13:12:08 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWGwh-00063D-Vy for xfs@oss.sgi.com; Sun, 08 Feb 2009 21:12:07 +0000 Date: Sun, 8 Feb 2009 16:12:07 -0500 From: Christoph Hellwig 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: <20090208211207.GA22118@infradead.org> References: <20090126073136.384490000@bombadil.infradead.org> <20090204193706.GA22805@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090204193706.GA22805@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234127528 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 02:37:06PM -0500, Christoph Hellwig wrote: > 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 I've added the two recently reviewed patch to that repoistory now. From SRS0+781a8d79da882f730615+1995+infradead.org+hch@bombadil.srs.infradead.org Sun Feb 8 15:15:54 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 n18LFrJt195151 for ; Sun, 8 Feb 2009 15:15:53 -0600 X-ASG-Debug-ID: 1234127716-1cde027e0000-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 C0EBDFB6C1 for ; Sun, 8 Feb 2009 13:15:16 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id oiHBvhlE7vGgPGkL for ; Sun, 08 Feb 2009 13:15:16 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWGzj-0003wZ-UB for xfs@oss.sgi.com; Sun, 08 Feb 2009 21:15:15 +0000 Date: Sun, 8 Feb 2009 16:15:15 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_db: fix wrong sibling pointers offset for the bmbt attr block Subject: xfs_db: fix wrong sibling pointers offset for the bmbt attr block Message-ID: <20090208211515.GB22118@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 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: 1234127716 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 attr bmbt should use long, not short pointers. Signed-off-by: Christoph Hellwig Index: xfsprogs-dev/db/btblock.c =================================================================== --- xfsprogs-dev.orig/db/btblock.c 2009-02-08 22:13:05.225944103 +0100 +++ xfsprogs-dev/db/btblock.c 2009-02-08 22:13:14.143944165 +0100 @@ -227,8 +227,8 @@ const field_t bmapbtd_flds[] = { { "magic", FLDT_UINT32X, OI(OFF(magic)), C1, 0, TYP_NONE }, { "level", FLDT_UINT16D, OI(OFF(level)), C1, 0, TYP_NONE }, { "numrecs", FLDT_UINT16D, OI(OFF(numrecs)), C1, 0, TYP_NONE }, - { "leftsib", FLDT_DFSBNO, OI(OFF(u.s.bb_leftsib)), C1, 0, TYP_BMAPBTD }, - { "rightsib", FLDT_DFSBNO, OI(OFF(u.s.bb_rightsib)), C1, 0, TYP_BMAPBTD }, + { "leftsib", FLDT_DFSBNO, OI(OFF(u.l.bb_leftsib)), C1, 0, TYP_BMAPBTD }, + { "rightsib", FLDT_DFSBNO, OI(OFF(u.l.bb_rightsib)), C1, 0, TYP_BMAPBTD }, { "recs", FLDT_BMAPBTDREC, btblock_rec_offset, btblock_rec_count, FLD_ARRAY|FLD_ABASE1|FLD_COUNT|FLD_OFFSET, TYP_NONE }, { "keys", FLDT_BMAPBTDKEY, btblock_key_offset, btblock_key_count, From david@fromorbit.com Sun Feb 8 16:17: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n18MH8Sl197943 for ; Sun, 8 Feb 2009 16:17:08 -0600 X-ASG-Debug-ID: 1234131389-215500430000-w1Z2WR 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 4AE1DFBE2F for ; Sun, 8 Feb 2009 14:16:29 -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 c9TegDPZdDRuOji3 for ; Sun, 08 Feb 2009 14:16:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAObojkl5LClx/2dsb2JhbADMVYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="285836570" 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; 09 Feb 2009 08:46:27 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWHwv-0005a2-TP; Mon, 09 Feb 2009 09:16:25 +1100 Date: Mon, 9 Feb 2009 09:16:25 +1100 From: Dave Chinner To: Alessandro Bono Cc: linux-kernel , linux-xfs X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Message-ID: <20090208221625.GB8830@disturbed> Mail-Followup-To: Alessandro Bono , linux-kernel , linux-xfs References: <1234011974.7435.11.camel@champagne.cantina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234011974.7435.11.camel@champagne.cantina> 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: 1234131391 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.17368 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 Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > Hi all > > This time I hit kernel bug without any particular operation, normal > browsing, mail, news, etc > tell me if you need info asap because I want to reformat this machine > and switch back to ext3. > > xfs seems really unstable in this particular > machine and after this crash I lose again configuration file of opened > program at crash time That's not XFS's fault - that's a broken application that does not safely overwrite files and hence you lose data on crash. > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > here ]------------ > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > fs/buffer.c:470! I can't remember seeing that problem before. > Call Trace: > [] ? need_resched+0x1e/0x28 > [] ? __up_write+0x12/0x45 > [] ? xfs_destroy_ioend+0x23/0x71 [xfs] > [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > [] ? run_workqueue+0x79/0xfe > [] ? worker_thread+0xf0/0x102 > [] ? autoremove_wake_function+0x0/0x2e > [] ? worker_thread+0x0/0x102 > [] ? kthread+0x47/0x73 > [] ? schedule_tail+0x27/0x60 > [] ? child_rip+0xa/0x11 > [] ? kthread+0x0/0x73 > [] ? child_rip+0x0/0x11 Standard delayed allocation IO completion trace. No idea what could have caused it. Perhaps a memory error? Can you send the output of xfs_info on that filesystem, and perhaps run an xfs_repair -n on it to see if there are any undetected errors on disk? Also, I note that you are using ext4 on some disks. Does this problem show up if you don't use ext4 at all? (We have had problems in the past with one filesystem not leaving bufferheads in the correct state and the system crashing when a different type of filesystem got them reallocated). Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+781a8d79da882f730615+1995+infradead.org+hch@bombadil.srs.infradead.org Sun Feb 8 16:29: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.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 n18MTbJU198489 for ; Sun, 8 Feb 2009 16:29:38 -0600 X-ASG-Debug-ID: 1234132140-2e1500d70000-w1Z2WR 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 3327918F0505 for ; Sun, 8 Feb 2009 14:29:00 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id VPHHU6Wdk4XL9CIL for ; Sun, 08 Feb 2009 14:29:00 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWI95-0001NT-IL; Sun, 08 Feb 2009 22:28:59 +0000 Date: Sun, 8 Feb 2009 17:28:59 -0500 From: Christoph Hellwig To: Alessandro Bono Cc: linux-kernel , linux-xfs X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Message-ID: <20090208222859.GA2532@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234011974.7435.11.camel@champagne.cantina> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234132141 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 Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > here ]------------ > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > fs/buffer.c:470! Per http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=blob;f=fs/buffer.c;h=665d446b25bc034241ef54c3c6b1d239c0ccf0f9;hb=d5b562330ec766292a3ac54ae5e0673610bd5b3d line 470 in fs/buffer.c of 2.6.28.4 has a comment and no actual code. What additional patches do you have applied? From alessandro.bono@gmail.com Sun Feb 8 16:39:54 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=AWL,BAYES_00,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 n18Mdrxb198988 for ; Sun, 8 Feb 2009 16:39:54 -0600 X-ASG-Debug-ID: 1234132755-145902bb0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 95B0F18F065F for ; Sun, 8 Feb 2009 14:39:16 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id LLfH69jl34MusO3n for ; Sun, 08 Feb 2009 14:39:16 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e21so1002145fga.8 for ; Sun, 08 Feb 2009 14:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=uMhgfqdE7TKy9wMzIAbze1UIf1XXCYcUyjBQwjBYCx0=; b=H2+z+EOenbHpjxEaVFozoSm9FchunQbAZeah2s6bBPS0CXrXUdE6anjC/D+JEZ/4fW /HGAwO3qUDVczrNxJfsEtgIHkSwA6b9S5CnCBiIeneeUl4sLMtJreh5abS+KjsAz6CW5 dDWh7alpkypPcUQwKzl6mVLLJSpBInFkVCYTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=U+fQ6wc9oN/vH80I6jkG7jGAhSQxdv6dgtjEf2wQ3vxnvLJM8UXTSnwIQRPJHbViLB 6cVQenQiJMh2M6bxJbUgD1YoqzWqFcuHHo2TJluesONhHnC4308G04QiE7WQSBW/483R jB+9NmBe/CohflFv4bwlwaa+D3bS1Td2ZgSlk= Received: by 10.102.218.5 with SMTP id q5mr66113mug.99.1234132755270; Sun, 08 Feb 2009 14:39:15 -0800 (PST) Received: from ?10.151.1.19? (host-62-10-44-87.cust-adsl.tiscali.it [62.10.44.87]) by mx.google.com with ESMTPS id 12sm1447964muq.35.2009.02.08.14.39.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 14:39:14 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Christoph Hellwig Cc: linux-kernel , linux-xfs In-Reply-To: <20090208222859.GA2532@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> Content-Type: text/plain Date: Sun, 08 Feb 2009 23:39:12 +0100 Message-Id: <1234132752.12370.0.camel@champagne.cantina> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1234132756 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.17369 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, 2009-02-08 at 17:28 -0500, Christoph Hellwig wrote: > On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > > here ]------------ > > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > > fs/buffer.c:470! > > Per > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=blob;f=fs/buffer.c;h=665d446b25bc034241ef54c3c6b1d239c0ccf0f9;hb=d5b562330ec766292a3ac54ae5e0673610bd5b3d > > line 470 in fs/buffer.c of 2.6.28.4 has a comment and no actual code. > > What additional patches do you have applied? > vanilla kernel no additional patches at all -- --- Cordiali Saluti Alessandro Bono From SRS0+781a8d79da882f730615+1995+infradead.org+hch@bombadil.srs.infradead.org Sun Feb 8 16:43: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n18MhReY199252 for ; Sun, 8 Feb 2009 16:43:27 -0600 X-ASG-Debug-ID: 1234132970-2155015b0000-w1Z2WR 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 B7F6AFBA60 for ; Sun, 8 Feb 2009 14:42:50 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Oiuh3CmZiR1BgJVT for ; Sun, 08 Feb 2009 14:42:50 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWIMT-000379-Ug; Sun, 08 Feb 2009 22:42:49 +0000 Date: Sun, 8 Feb 2009 17:42:49 -0500 From: Christoph Hellwig To: Alessandro Bono Cc: Christoph Hellwig , linux-kernel , linux-xfs X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Message-ID: <20090208224249.GA11931@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234132752.12370.0.camel@champagne.cantina> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234132970 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 08, 2009 at 11:39:12PM +0100, Alessandro Bono wrote: > On Sun, 2009-02-08 at 17:28 -0500, Christoph Hellwig wrote: > > On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > > > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > > > here ]------------ > > > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > > > fs/buffer.c:470! > > > > Per > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=blob;f=fs/buffer.c;h=665d446b25bc034241ef54c3c6b1d239c0ccf0f9;hb=d5b562330ec766292a3ac54ae5e0673610bd5b3d > > > > line 470 in fs/buffer.c of 2.6.28.4 has a comment and no actual code. > > > > What additional patches do you have applied? > > > > vanilla kernel > no additional patches at all Well, the 2.6.28.4 clearly doesn't have a bug there. Can you attach the fs/buffer.c you built the kernel from? From alessandro.bono@gmail.com Sun Feb 8 16:46:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_34,J_CHICKENPOX_45,J_CHICKENPOX_56,J_CHICKENPOX_62, J_CHICKENPOX_66,J_CHICKENPOX_84,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 n18MkArt199626 for ; Sun, 8 Feb 2009 16:46:10 -0600 X-ASG-Debug-ID: 1234133129-215301670000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f168.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ED261FBA82 for ; Sun, 8 Feb 2009 14:45:29 -0800 (PST) Received: from mail-bw0-f168.google.com (mail-bw0-f168.google.com [209.85.218.168]) by cuda.sgi.com with ESMTP id 5jyvGcyN5VidME4f for ; Sun, 08 Feb 2009 14:45:29 -0800 (PST) Received: by bwz12 with SMTP id 12so846274bwz.20 for ; Sun, 08 Feb 2009 14:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=ISrqa8FkPF9Pw2SJFFaEB4ExAW3vATJ2HoFoEWpBbyA=; b=itPrGu2rc75JQPC9gC9o+1Vm1mhULz6WCQ6anImwn3wfbvuvyfB3JMB9uFqJQydMOh i0WXzCmU4HqSmW5mPywY6Y4x9MEvK016k6qlM42iLdB4cM3hNuLlYLSpG1siB6nfRrn3 NHQK9z7yvvWsG7RZcpzjmZveI5Hj+gfJB6dhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=cROjgtYyUNpMs4mMyAmsBJpqJijFtM33gxLv8JSGeqlBZqEljD5Pu9rQqPBg+kuZXk WXLz0yaTRG4yx/7j5SBUUrK3zxMzuWOIufx9/lzMQNre9jL3UcqhONCsfV8o+xFJqW6r JRcOkiehy1RFuiAqLcwgBkLHVs6xJMlR+9aT4= Received: by 10.103.214.13 with SMTP id r13mr1820477muq.37.1234133128105; Sun, 08 Feb 2009 14:45:28 -0800 (PST) Received: from ?10.151.1.19? (host-62-10-44-87.cust-adsl.tiscali.it [62.10.44.87]) by mx.google.com with ESMTPS id j6sm434390mue.4.2009.02.08.14.45.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 14:45:26 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Christoph Hellwig Cc: linux-kernel , linux-xfs In-Reply-To: <20090208224249.GA11931@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> Content-Type: multipart/mixed; boundary="=-UIf3LxEbYx4KmvZuWDGh" Date: Sun, 08 Feb 2009 23:45:20 +0100 Message-Id: <1234133120.12370.7.camel@champagne.cantina> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 X-Barracuda-Connect: mail-bw0-f168.google.com[209.85.218.168] X-Barracuda-Start-Time: 1234133130 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.17369 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 --=-UIf3LxEbYx4KmvZuWDGh Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2009-02-08 at 17:42 -0500, Christoph Hellwig wrote: > On Sun, Feb 08, 2009 at 11:39:12PM +0100, Alessandro Bono wrote: > > On Sun, 2009-02-08 at 17:28 -0500, Christoph Hellwig wrote: > > > On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > > > > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > > > > here ]------------ > > > > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > > > > fs/buffer.c:470! > > > > > > Per > > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=blob;f=fs/buffer.c;h=665d446b25bc034241ef54c3c6b1d239c0ccf0f9;hb=d5b562330ec766292a3ac54ae5e0673610bd5b3d > > > > > > line 470 in fs/buffer.c of 2.6.28.4 has a comment and no actual code. > > > > > > What additional patches do you have applied? > > > > > > > vanilla kernel > > no additional patches at all > > Well, the 2.6.28.4 clearly doesn't have a bug there. Can you > attach the fs/buffer.c you built the kernel from? > sure, attached -- --- Cordiali Saluti Alessandro Bono --=-UIf3LxEbYx4KmvZuWDGh Content-Disposition: attachment; filename="buffer.c" Content-Type: text/x-csrc; name="buffer.c"; charset="UTF-8" Content-Transfer-Encoding: 7bit /* * linux/fs/buffer.c * * Copyright (C) 1991, 1992, 2002 Linus Torvalds */ /* * Start bdflush() with kernel_thread not syscall - Paul Gortmaker, 12/95 * * Removed a lot of unnecessary code and simplified things now that * the buffer cache isn't our primary cache - Andrew Tridgell 12/96 * * Speed up hash, lru, and free list operations. Use gfp() for allocating * hash table, use SLAB cache for buffer heads. SMP threading. -DaveM * * Added 32k buffer block sizes - these are required older ARM systems. - RMK * * async buffer flushing, 1999 Andrea Arcangeli */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static int fsync_buffers_list(spinlock_t *lock, struct list_head *list); #define BH_ENTRY(list) list_entry((list), struct buffer_head, b_assoc_buffers) inline void init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private) { bh->b_end_io = handler; bh->b_private = private; } static int sync_buffer(void *word) { struct block_device *bd; struct buffer_head *bh = container_of(word, struct buffer_head, b_state); smp_mb(); bd = bh->b_bdev; if (bd) blk_run_address_space(bd->bd_inode->i_mapping); io_schedule(); return 0; } void __lock_buffer(struct buffer_head *bh) { wait_on_bit_lock(&bh->b_state, BH_Lock, sync_buffer, TASK_UNINTERRUPTIBLE); } EXPORT_SYMBOL(__lock_buffer); void unlock_buffer(struct buffer_head *bh) { clear_bit_unlock(BH_Lock, &bh->b_state); smp_mb__after_clear_bit(); wake_up_bit(&bh->b_state, BH_Lock); } /* * Block until a buffer comes unlocked. This doesn't stop it * from becoming locked again - you have to lock it yourself * if you want to preserve its state. */ void __wait_on_buffer(struct buffer_head * bh) { wait_on_bit(&bh->b_state, BH_Lock, sync_buffer, TASK_UNINTERRUPTIBLE); } static void __clear_page_buffers(struct page *page) { ClearPagePrivate(page); set_page_private(page, 0); page_cache_release(page); } static void buffer_io_error(struct buffer_head *bh) { char b[BDEVNAME_SIZE]; printk(KERN_ERR "Buffer I/O error on device %s, logical block %Lu\n", bdevname(bh->b_bdev, b), (unsigned long long)bh->b_blocknr); } /* * End-of-IO handler helper function which does not touch the bh after * unlocking it. * Note: unlock_buffer() sort-of does touch the bh after unlocking it, but * a race there is benign: unlock_buffer() only use the bh's address for * hashing after unlocking the buffer, so it doesn't actually touch the bh * itself. */ static void __end_buffer_read_notouch(struct buffer_head *bh, int uptodate) { if (uptodate) { set_buffer_uptodate(bh); } else { /* This happens, due to failed READA attempts. */ clear_buffer_uptodate(bh); } unlock_buffer(bh); } /* * Default synchronous end-of-IO handler.. Just mark it up-to-date and * unlock the buffer. This is what ll_rw_block uses too. */ void end_buffer_read_sync(struct buffer_head *bh, int uptodate) { __end_buffer_read_notouch(bh, uptodate); put_bh(bh); } void end_buffer_write_sync(struct buffer_head *bh, int uptodate) { char b[BDEVNAME_SIZE]; if (uptodate) { set_buffer_uptodate(bh); } else { if (!buffer_eopnotsupp(bh) && printk_ratelimit()) { buffer_io_error(bh); printk(KERN_WARNING "lost page write due to " "I/O error on %s\n", bdevname(bh->b_bdev, b)); } set_buffer_write_io_error(bh); clear_buffer_uptodate(bh); } unlock_buffer(bh); put_bh(bh); } /* * Write out and wait upon all the dirty data associated with a block * device via its mapping. Does not take the superblock lock. */ int sync_blockdev(struct block_device *bdev) { int ret = 0; if (bdev) ret = filemap_write_and_wait(bdev->bd_inode->i_mapping); return ret; } EXPORT_SYMBOL(sync_blockdev); /* * Write out and wait upon all dirty data associated with this * device. Filesystem data as well as the underlying block * device. Takes the superblock lock. */ int fsync_bdev(struct block_device *bdev) { struct super_block *sb = get_super(bdev); if (sb) { int res = fsync_super(sb); drop_super(sb); return res; } return sync_blockdev(bdev); } /** * freeze_bdev -- lock a filesystem and force it into a consistent state * @bdev: blockdevice to lock * * This takes the block device bd_mount_sem to make sure no new mounts * happen on bdev until thaw_bdev() is called. * If a superblock is found on this device, we take the s_umount semaphore * on it to make sure nobody unmounts until the snapshot creation is done. */ struct super_block *freeze_bdev(struct block_device *bdev) { struct super_block *sb; down(&bdev->bd_mount_sem); sb = get_super(bdev); if (sb && !(sb->s_flags & MS_RDONLY)) { sb->s_frozen = SB_FREEZE_WRITE; smp_wmb(); __fsync_super(sb); sb->s_frozen = SB_FREEZE_TRANS; smp_wmb(); sync_blockdev(sb->s_bdev); if (sb->s_op->write_super_lockfs) sb->s_op->write_super_lockfs(sb); } sync_blockdev(bdev); return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ } EXPORT_SYMBOL(freeze_bdev); /** * thaw_bdev -- unlock filesystem * @bdev: blockdevice to unlock * @sb: associated superblock * * Unlocks the filesystem and marks it writeable again after freeze_bdev(). */ void thaw_bdev(struct block_device *bdev, struct super_block *sb) { if (sb) { BUG_ON(sb->s_bdev != bdev); if (sb->s_op->unlockfs) sb->s_op->unlockfs(sb); sb->s_frozen = SB_UNFROZEN; smp_wmb(); wake_up(&sb->s_wait_unfrozen); drop_super(sb); } up(&bdev->bd_mount_sem); } EXPORT_SYMBOL(thaw_bdev); /* * Various filesystems appear to want __find_get_block to be non-blocking. * But it's the page lock which protects the buffers. To get around this, * we get exclusion from try_to_free_buffers with the blockdev mapping's * private_lock. * * Hack idea: for the blockdev mapping, i_bufferlist_lock contention * may be quite high. This code could TryLock the page, and if that * succeeds, there is no need to take private_lock. (But if * private_lock is contended then so is mapping->tree_lock). */ static struct buffer_head * __find_get_block_slow(struct block_device *bdev, sector_t block) { struct inode *bd_inode = bdev->bd_inode; struct address_space *bd_mapping = bd_inode->i_mapping; struct buffer_head *ret = NULL; pgoff_t index; struct buffer_head *bh; struct buffer_head *head; struct page *page; int all_mapped = 1; index = block >> (PAGE_CACHE_SHIFT - bd_inode->i_blkbits); page = find_get_page(bd_mapping, index); if (!page) goto out; spin_lock(&bd_mapping->private_lock); if (!page_has_buffers(page)) goto out_unlock; head = page_buffers(page); bh = head; do { if (bh->b_blocknr == block) { ret = bh; get_bh(bh); goto out_unlock; } if (!buffer_mapped(bh)) all_mapped = 0; bh = bh->b_this_page; } while (bh != head); /* we might be here because some of the buffers on this page are * not mapped. This is due to various races between * file io on the block device and getblk. It gets dealt with * elsewhere, don't buffer_error if we had some unmapped buffers */ if (all_mapped) { printk("__find_get_block_slow() failed. " "block=%llu, b_blocknr=%llu\n", (unsigned long long)block, (unsigned long long)bh->b_blocknr); printk("b_state=0x%08lx, b_size=%zu\n", bh->b_state, bh->b_size); printk("device blocksize: %d\n", 1 << bd_inode->i_blkbits); } out_unlock: spin_unlock(&bd_mapping->private_lock); page_cache_release(page); out: return ret; } /* If invalidate_buffers() will trash dirty buffers, it means some kind of fs corruption is going on. Trashing dirty data always imply losing information that was supposed to be just stored on the physical layer by the user. Thus invalidate_buffers in general usage is not allwowed to trash dirty buffers. For example ioctl(FLSBLKBUF) expects dirty data to be preserved. These buffers are simply skipped. We also skip buffers which are still in use. For example this can happen if a userspace program is reading the block device. NOTE: In the case where the user removed a removable-media-disk even if there's still dirty data not synced on disk (due a bug in the device driver or due an error of the user), by not destroying the dirty buffers we could generate corruption also on the next media inserted, thus a parameter is necessary to handle this case in the most safe way possible (trying to not corrupt also the new disk inserted with the data belonging to the old now corrupted disk). Also for the ramdisk the natural thing to do in order to release the ramdisk memory is to destroy dirty buffers. These are two special cases. Normal usage imply the device driver to issue a sync on the device (without waiting I/O completion) and then an invalidate_buffers call that doesn't trash dirty buffers. For handling cache coherency with the blkdev pagecache the 'update' case is been introduced. It is needed to re-read from disk any pinned buffer. NOTE: re-reading from disk is destructive so we can do it only when we assume nobody is changing the buffercache under our I/O and when we think the disk contains more recent information than the buffercache. The update == 1 pass marks the buffers we need to update, the update == 2 pass does the actual I/O. */ void invalidate_bdev(struct block_device *bdev) { struct address_space *mapping = bdev->bd_inode->i_mapping; if (mapping->nrpages == 0) return; invalidate_bh_lrus(); invalidate_mapping_pages(mapping, 0, -1); } /* * Kick pdflush then try to free up some ZONE_NORMAL memory. */ static void free_more_memory(void) { struct zone *zone; int nid; wakeup_pdflush(1024); yield(); for_each_online_node(nid) { (void)first_zones_zonelist(node_zonelist(nid, GFP_NOFS), gfp_zone(GFP_NOFS), NULL, &zone); if (zone) try_to_free_pages(node_zonelist(nid, GFP_NOFS), 0, GFP_NOFS); } } /* * I/O completion handler for block_read_full_page() - pages * which come unlocked at the end of I/O. */ static void end_buffer_async_read(struct buffer_head *bh, int uptodate) { unsigned long flags; struct buffer_head *first; struct buffer_head *tmp; struct page *page; int page_uptodate = 1; BUG_ON(!buffer_async_read(bh)); page = bh->b_page; if (uptodate) { set_buffer_uptodate(bh); } else { clear_buffer_uptodate(bh); if (printk_ratelimit()) buffer_io_error(bh); SetPageError(page); } /* * Be _very_ careful from here on. Bad things can happen if * two buffer heads end IO at almost the same time and both * decide that the page is now completely done. */ first = page_buffers(page); local_irq_save(flags); bit_spin_lock(BH_Uptodate_Lock, &first->b_state); clear_buffer_async_read(bh); unlock_buffer(bh); tmp = bh; do { if (!buffer_uptodate(tmp)) page_uptodate = 0; if (buffer_async_read(tmp)) { BUG_ON(!buffer_locked(tmp)); goto still_busy; } tmp = tmp->b_this_page; } while (tmp != bh); bit_spin_unlock(BH_Uptodate_Lock, &first->b_state); local_irq_restore(flags); /* * If none of the buffers had errors and they are all * uptodate then we can set the page uptodate. */ if (page_uptodate && !PageError(page)) SetPageUptodate(page); unlock_page(page); return; still_busy: bit_spin_unlock(BH_Uptodate_Lock, &first->b_state); local_irq_restore(flags); return; } /* * Completion handler for block_write_full_page() - pages which are unlocked * during I/O, and which have PageWriteback cleared upon I/O completion. */ static void end_buffer_async_write(struct buffer_head *bh, int uptodate) { char b[BDEVNAME_SIZE]; unsigned long flags; struct buffer_head *first; struct buffer_head *tmp; struct page *page; BUG_ON(!buffer_async_write(bh)); page = bh->b_page; if (uptodate) { set_buffer_uptodate(bh); } else { if (printk_ratelimit()) { buffer_io_error(bh); printk(KERN_WARNING "lost page write due to " "I/O error on %s\n", bdevname(bh->b_bdev, b)); } set_bit(AS_EIO, &page->mapping->flags); set_buffer_write_io_error(bh); clear_buffer_uptodate(bh); SetPageError(page); } first = page_buffers(page); local_irq_save(flags); bit_spin_lock(BH_Uptodate_Lock, &first->b_state); clear_buffer_async_write(bh); unlock_buffer(bh); tmp = bh->b_this_page; while (tmp != bh) { if (buffer_async_write(tmp)) { BUG_ON(!buffer_locked(tmp)); goto still_busy; } tmp = tmp->b_this_page; } bit_spin_unlock(BH_Uptodate_Lock, &first->b_state); local_irq_restore(flags); end_page_writeback(page); return; still_busy: bit_spin_unlock(BH_Uptodate_Lock, &first->b_state); local_irq_restore(flags); return; } /* * If a page's buffers are under async readin (end_buffer_async_read * completion) then there is a possibility that another thread of * control could lock one of the buffers after it has completed * but while some of the other buffers have not completed. This * locked buffer would confuse end_buffer_async_read() into not unlocking * the page. So the absence of BH_Async_Read tells end_buffer_async_read() * that this buffer is not under async I/O. * * The page comes unlocked when it has no locked buffer_async buffers * left. * * PageLocked prevents anyone starting new async I/O reads any of * the buffers. * * PageWriteback is used to prevent simultaneous writeout of the same * page. * * PageLocked prevents anyone from starting writeback of a page which is * under read I/O (PageWriteback is only ever set against a locked page). */ static void mark_buffer_async_read(struct buffer_head *bh) { bh->b_end_io = end_buffer_async_read; set_buffer_async_read(bh); } void mark_buffer_async_write(struct buffer_head *bh) { bh->b_end_io = end_buffer_async_write; set_buffer_async_write(bh); } EXPORT_SYMBOL(mark_buffer_async_write); /* * fs/buffer.c contains helper functions for buffer-backed address space's * fsync functions. A common requirement for buffer-based filesystems is * that certain data from the backing blockdev needs to be written out for * a successful fsync(). For example, ext2 indirect blocks need to be * written back and waited upon before fsync() returns. * * The functions mark_buffer_inode_dirty(), fsync_inode_buffers(), * inode_has_buffers() and invalidate_inode_buffers() are provided for the * management of a list of dependent buffers at ->i_mapping->private_list. * * Locking is a little subtle: try_to_free_buffers() will remove buffers * from their controlling inode's queue when they are being freed. But * try_to_free_buffers() will be operating against the *blockdev* mapping * at the time, not against the S_ISREG file which depends on those buffers. * So the locking for private_list is via the private_lock in the address_space * which backs the buffers. Which is different from the address_space * against which the buffers are listed. So for a particular address_space, * mapping->private_lock does *not* protect mapping->private_list! In fact, * mapping->private_list will always be protected by the backing blockdev's * ->private_lock. * * Which introduces a requirement: all buffers on an address_space's * ->private_list must be from the same address_space: the blockdev's. * * address_spaces which do not place buffers at ->private_list via these * utility functions are free to use private_lock and private_list for * whatever they want. The only requirement is that list_empty(private_list) * be true at clear_inode() time. * * FIXME: clear_inode should not call invalidate_inode_buffers(). The * filesystems should do that. invalidate_inode_buffers() should just go * BUG_ON(!list_empty). * * FIXME: mark_buffer_dirty_inode() is a data-plane operation. It should * take an address_space, not an inode. And it should be called * mark_buffer_dirty_fsync() to clearly define why those buffers are being * queued up. * * FIXME: mark_buffer_dirty_inode() doesn't need to add the buffer to the * list if it is already on a list. Because if the buffer is on a list, * it *must* already be on the right one. If not, the filesystem is being * silly. This will save a ton of locking. But first we have to ensure * that buffers are taken *off* the old inode's list when they are freed * (presumably in truncate). That requires careful auditing of all * filesystems (do it inside bforget()). It could also be done by bringing * b_inode back. */ /* * The buffer's backing address_space's private_lock must be held */ static void __remove_assoc_queue(struct buffer_head *bh) { list_del_init(&bh->b_assoc_buffers); WARN_ON(!bh->b_assoc_map); if (buffer_write_io_error(bh)) set_bit(AS_EIO, &bh->b_assoc_map->flags); bh->b_assoc_map = NULL; } int inode_has_buffers(struct inode *inode) { return !list_empty(&inode->i_data.private_list); } /* * osync is designed to support O_SYNC io. It waits synchronously for * all already-submitted IO to complete, but does not queue any new * writes to the disk. * * To do O_SYNC writes, just queue the buffer writes with ll_rw_block as * you dirty the buffers, and then use osync_inode_buffers to wait for * completion. Any other dirty buffers which are not yet queued for * write will not be flushed to disk by the osync. */ static int osync_buffers_list(spinlock_t *lock, struct list_head *list) { struct buffer_head *bh; struct list_head *p; int err = 0; spin_lock(lock); repeat: list_for_each_prev(p, list) { bh = BH_ENTRY(p); if (buffer_locked(bh)) { get_bh(bh); spin_unlock(lock); wait_on_buffer(bh); if (!buffer_uptodate(bh)) err = -EIO; brelse(bh); spin_lock(lock); goto repeat; } } spin_unlock(lock); return err; } /** * sync_mapping_buffers - write out & wait upon a mapping's "associated" buffers * @mapping: the mapping which wants those buffers written * * Starts I/O against the buffers at mapping->private_list, and waits upon * that I/O. * * Basically, this is a convenience function for fsync(). * @mapping is a file or directory which needs those buffers to be written for * a successful fsync(). */ int sync_mapping_buffers(struct address_space *mapping) { struct address_space *buffer_mapping = mapping->assoc_mapping; if (buffer_mapping == NULL || list_empty(&mapping->private_list)) return 0; return fsync_buffers_list(&buffer_mapping->private_lock, &mapping->private_list); } EXPORT_SYMBOL(sync_mapping_buffers); /* * Called when we've recently written block `bblock', and it is known that * `bblock' was for a buffer_boundary() buffer. This means that the block at * `bblock + 1' is probably a dirty indirect block. Hunt it down and, if it's * dirty, schedule it for IO. So that indirects merge nicely with their data. */ void write_boundary_block(struct block_device *bdev, sector_t bblock, unsigned blocksize) { struct buffer_head *bh = __find_get_block(bdev, bblock + 1, blocksize); if (bh) { if (buffer_dirty(bh)) ll_rw_block(WRITE, 1, &bh); put_bh(bh); } } void mark_buffer_dirty_inode(struct buffer_head *bh, struct inode *inode) { struct address_space *mapping = inode->i_mapping; struct address_space *buffer_mapping = bh->b_page->mapping; mark_buffer_dirty(bh); if (!mapping->assoc_mapping) { mapping->assoc_mapping = buffer_mapping; } else { BUG_ON(mapping->assoc_mapping != buffer_mapping); } if (!bh->b_assoc_map) { spin_lock(&buffer_mapping->private_lock); list_move_tail(&bh->b_assoc_buffers, &mapping->private_list); bh->b_assoc_map = mapping; spin_unlock(&buffer_mapping->private_lock); } } EXPORT_SYMBOL(mark_buffer_dirty_inode); /* * Mark the page dirty, and set it dirty in the radix tree, and mark the inode * dirty. * * If warn is true, then emit a warning if the page is not uptodate and has * not been truncated. */ static int __set_page_dirty(struct page *page, struct address_space *mapping, int warn) { if (unlikely(!mapping)) return !TestSetPageDirty(page); if (TestSetPageDirty(page)) return 0; spin_lock_irq(&mapping->tree_lock); if (page->mapping) { /* Race with truncate? */ WARN_ON_ONCE(warn && !PageUptodate(page)); if (mapping_cap_account_dirty(mapping)) { __inc_zone_page_state(page, NR_FILE_DIRTY); __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); task_io_account_write(PAGE_CACHE_SIZE); } radix_tree_tag_set(&mapping->page_tree, page_index(page), PAGECACHE_TAG_DIRTY); } spin_unlock_irq(&mapping->tree_lock); __mark_inode_dirty(mapping->host, I_DIRTY_PAGES); return 1; } /* * Add a page to the dirty page list. * * It is a sad fact of life that this function is called from several places * deeply under spinlocking. It may not sleep. * * If the page has buffers, the uptodate buffers are set dirty, to preserve * dirty-state coherency between the page and the buffers. It the page does * not have buffers then when they are later attached they will all be set * dirty. * * The buffers are dirtied before the page is dirtied. There's a small race * window in which a writepage caller may see the page cleanness but not the * buffer dirtiness. That's fine. If this code were to set the page dirty * before the buffers, a concurrent writepage caller could clear the page dirty * bit, see a bunch of clean buffers and we'd end up with dirty buffers/clean * page on the dirty page list. * * We use private_lock to lock against try_to_free_buffers while using the * page's buffer list. Also use this to protect against clean buffers being * added to the page after it was set dirty. * * FIXME: may need to call ->reservepage here as well. That's rather up to the * address_space though. */ int __set_page_dirty_buffers(struct page *page) { struct address_space *mapping = page_mapping(page); if (unlikely(!mapping)) return !TestSetPageDirty(page); spin_lock(&mapping->private_lock); if (page_has_buffers(page)) { struct buffer_head *head = page_buffers(page); struct buffer_head *bh = head; do { set_buffer_dirty(bh); bh = bh->b_this_page; } while (bh != head); } spin_unlock(&mapping->private_lock); return __set_page_dirty(page, mapping, 1); } EXPORT_SYMBOL(__set_page_dirty_buffers); /* * Write out and wait upon a list of buffers. * * We have conflicting pressures: we want to make sure that all * initially dirty buffers get waited on, but that any subsequently * dirtied buffers don't. After all, we don't want fsync to last * forever if somebody is actively writing to the file. * * Do this in two main stages: first we copy dirty buffers to a * temporary inode list, queueing the writes as we go. Then we clean * up, waiting for those writes to complete. * * During this second stage, any subsequent updates to the file may end * up refiling the buffer on the original inode's dirty list again, so * there is a chance we will end up with a buffer queued for write but * not yet completed on that list. So, as a final cleanup we go through * the osync code to catch these locked, dirty buffers without requeuing * any newly dirty buffers for write. */ static int fsync_buffers_list(spinlock_t *lock, struct list_head *list) { struct buffer_head *bh; struct list_head tmp; struct address_space *mapping; int err = 0, err2; INIT_LIST_HEAD(&tmp); spin_lock(lock); while (!list_empty(list)) { bh = BH_ENTRY(list->next); mapping = bh->b_assoc_map; __remove_assoc_queue(bh); /* Avoid race with mark_buffer_dirty_inode() which does * a lockless check and we rely on seeing the dirty bit */ smp_mb(); if (buffer_dirty(bh) || buffer_locked(bh)) { list_add(&bh->b_assoc_buffers, &tmp); bh->b_assoc_map = mapping; if (buffer_dirty(bh)) { get_bh(bh); spin_unlock(lock); /* * Ensure any pending I/O completes so that * ll_rw_block() actually writes the current * contents - it is a noop if I/O is still in * flight on potentially older contents. */ ll_rw_block(SWRITE_SYNC, 1, &bh); brelse(bh); spin_lock(lock); } } } while (!list_empty(&tmp)) { bh = BH_ENTRY(tmp.prev); get_bh(bh); mapping = bh->b_assoc_map; __remove_assoc_queue(bh); /* Avoid race with mark_buffer_dirty_inode() which does * a lockless check and we rely on seeing the dirty bit */ smp_mb(); if (buffer_dirty(bh)) { list_add(&bh->b_assoc_buffers, &mapping->private_list); bh->b_assoc_map = mapping; } spin_unlock(lock); wait_on_buffer(bh); if (!buffer_uptodate(bh)) err = -EIO; brelse(bh); spin_lock(lock); } spin_unlock(lock); err2 = osync_buffers_list(lock, list); if (err) return err; else return err2; } /* * Invalidate any and all dirty buffers on a given inode. We are * probably unmounting the fs, but that doesn't mean we have already * done a sync(). Just drop the buffers from the inode list. * * NOTE: we take the inode's blockdev's mapping's private_lock. Which * assumes that all the buffers are against the blockdev. Not true * for reiserfs. */ void invalidate_inode_buffers(struct inode *inode) { if (inode_has_buffers(inode)) { struct address_space *mapping = &inode->i_data; struct list_head *list = &mapping->private_list; struct address_space *buffer_mapping = mapping->assoc_mapping; spin_lock(&buffer_mapping->private_lock); while (!list_empty(list)) __remove_assoc_queue(BH_ENTRY(list->next)); spin_unlock(&buffer_mapping->private_lock); } } EXPORT_SYMBOL(invalidate_inode_buffers); /* * Remove any clean buffers from the inode's buffer list. This is called * when we're trying to free the inode itself. Those buffers can pin it. * * Returns true if all buffers were removed. */ int remove_inode_buffers(struct inode *inode) { int ret = 1; if (inode_has_buffers(inode)) { struct address_space *mapping = &inode->i_data; struct list_head *list = &mapping->private_list; struct address_space *buffer_mapping = mapping->assoc_mapping; spin_lock(&buffer_mapping->private_lock); while (!list_empty(list)) { struct buffer_head *bh = BH_ENTRY(list->next); if (buffer_dirty(bh)) { ret = 0; break; } __remove_assoc_queue(bh); } spin_unlock(&buffer_mapping->private_lock); } return ret; } /* * Create the appropriate buffers when given a page for data area and * the size of each buffer.. Use the bh->b_this_page linked list to * follow the buffers created. Return NULL if unable to create more * buffers. * * The retry flag is used to differentiate async IO (paging, swapping) * which may not fail from ordinary buffer allocations. */ struct buffer_head *alloc_page_buffers(struct page *page, unsigned long size, int retry) { struct buffer_head *bh, *head; long offset; try_again: head = NULL; offset = PAGE_SIZE; while ((offset -= size) >= 0) { bh = alloc_buffer_head(GFP_NOFS); if (!bh) goto no_grow; bh->b_bdev = NULL; bh->b_this_page = head; bh->b_blocknr = -1; head = bh; bh->b_state = 0; atomic_set(&bh->b_count, 0); bh->b_private = NULL; bh->b_size = size; /* Link the buffer to its page */ set_bh_page(bh, page, offset); init_buffer(bh, NULL, NULL); } return head; /* * In case anything failed, we just free everything we got. */ no_grow: if (head) { do { bh = head; head = head->b_this_page; free_buffer_head(bh); } while (head); } /* * Return failure for non-async IO requests. Async IO requests * are not allowed to fail, so we have to wait until buffer heads * become available. But we don't want tasks sleeping with * partially complete buffers, so all were released above. */ if (!retry) return NULL; /* We're _really_ low on memory. Now we just * wait for old buffer heads to become free due to * finishing IO. Since this is an async request and * the reserve list is empty, we're sure there are * async buffer heads in use. */ free_more_memory(); goto try_again; } EXPORT_SYMBOL_GPL(alloc_page_buffers); static inline void link_dev_buffers(struct page *page, struct buffer_head *head) { struct buffer_head *bh, *tail; bh = head; do { tail = bh; bh = bh->b_this_page; } while (bh); tail->b_this_page = head; attach_page_buffers(page, head); } /* * Initialise the state of a blockdev page's buffers. */ static void init_page_buffers(struct page *page, struct block_device *bdev, sector_t block, int size) { struct buffer_head *head = page_buffers(page); struct buffer_head *bh = head; int uptodate = PageUptodate(page); do { if (!buffer_mapped(bh)) { init_buffer(bh, NULL, NULL); bh->b_bdev = bdev; bh->b_blocknr = block; if (uptodate) set_buffer_uptodate(bh); set_buffer_mapped(bh); } block++; bh = bh->b_this_page; } while (bh != head); } /* * Create the page-cache page that contains the requested block. * * This is user purely for blockdev mappings. */ static struct page * grow_dev_page(struct block_device *bdev, sector_t block, pgoff_t index, int size) { struct inode *inode = bdev->bd_inode; struct page *page; struct buffer_head *bh; page = find_or_create_page(inode->i_mapping, index, (mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS)|__GFP_MOVABLE); if (!page) return NULL; BUG_ON(!PageLocked(page)); if (page_has_buffers(page)) { bh = page_buffers(page); if (bh->b_size == size) { init_page_buffers(page, bdev, block, size); return page; } if (!try_to_free_buffers(page)) goto failed; } /* * Allocate some buffers for this page */ bh = alloc_page_buffers(page, size, 0); if (!bh) goto failed; /* * Link the page to the buffers and initialise them. Take the * lock to be atomic wrt __find_get_block(), which does not * run under the page lock. */ spin_lock(&inode->i_mapping->private_lock); link_dev_buffers(page, bh); init_page_buffers(page, bdev, block, size); spin_unlock(&inode->i_mapping->private_lock); return page; failed: BUG(); unlock_page(page); page_cache_release(page); return NULL; } /* * Create buffers for the specified block device block's page. If * that page was dirty, the buffers are set dirty also. */ static int grow_buffers(struct block_device *bdev, sector_t block, int size) { struct page *page; pgoff_t index; int sizebits; sizebits = -1; do { sizebits++; } while ((size << sizebits) < PAGE_SIZE); index = block >> sizebits; /* * Check for a block which wants to lie outside our maximum possible * pagecache index. (this comparison is done using sector_t types). */ if (unlikely(index != block >> sizebits)) { char b[BDEVNAME_SIZE]; printk(KERN_ERR "%s: requested out-of-range block %llu for " "device %s\n", __func__, (unsigned long long)block, bdevname(bdev, b)); return -EIO; } block = index << sizebits; /* Create a page with the proper size buffers.. */ page = grow_dev_page(bdev, block, index, size); if (!page) return 0; unlock_page(page); page_cache_release(page); return 1; } static struct buffer_head * __getblk_slow(struct block_device *bdev, sector_t block, int size) { /* Size must be multiple of hard sectorsize */ if (unlikely(size & (bdev_hardsect_size(bdev)-1) || (size < 512 || size > PAGE_SIZE))) { printk(KERN_ERR "getblk(): invalid block size %d requested\n", size); printk(KERN_ERR "hardsect size: %d\n", bdev_hardsect_size(bdev)); dump_stack(); return NULL; } for (;;) { struct buffer_head * bh; int ret; bh = __find_get_block(bdev, block, size); if (bh) return bh; ret = grow_buffers(bdev, block, size); if (ret < 0) return NULL; if (ret == 0) free_more_memory(); } } /* * The relationship between dirty buffers and dirty pages: * * Whenever a page has any dirty buffers, the page's dirty bit is set, and * the page is tagged dirty in its radix tree. * * At all times, the dirtiness of the buffers represents the dirtiness of * subsections of the page. If the page has buffers, the page dirty bit is * merely a hint about the true dirty state. * * When a page is set dirty in its entirety, all its buffers are marked dirty * (if the page has buffers). * * When a buffer is marked dirty, its page is dirtied, but the page's other * buffers are not. * * Also. When blockdev buffers are explicitly read with bread(), they * individually become uptodate. But their backing page remains not * uptodate - even if all of its buffers are uptodate. A subsequent * block_read_full_page() against that page will discover all the uptodate * buffers, will set the page uptodate and will perform no I/O. */ /** * mark_buffer_dirty - mark a buffer_head as needing writeout * @bh: the buffer_head to mark dirty * * mark_buffer_dirty() will set the dirty bit against the buffer, then set its * backing page dirty, then tag the page as dirty in its address_space's radix * tree and then attach the address_space's inode to its superblock's dirty * inode list. * * mark_buffer_dirty() is atomic. It takes bh->b_page->mapping->private_lock, * mapping->tree_lock and the global inode_lock. */ void mark_buffer_dirty(struct buffer_head *bh) { WARN_ON_ONCE(!buffer_uptodate(bh)); /* * Very *carefully* optimize the it-is-already-dirty case. * * Don't let the final "is it dirty" escape to before we * perhaps modified the buffer. */ if (buffer_dirty(bh)) { smp_mb(); if (buffer_dirty(bh)) return; } if (!test_set_buffer_dirty(bh)) __set_page_dirty(bh->b_page, page_mapping(bh->b_page), 0); } /* * Decrement a buffer_head's reference count. If all buffers against a page * have zero reference count, are clean and unlocked, and if the page is clean * and unlocked then try_to_free_buffers() may strip the buffers from the page * in preparation for freeing it (sometimes, rarely, buffers are removed from * a page but it ends up not being freed, and buffers may later be reattached). */ void __brelse(struct buffer_head * buf) { if (atomic_read(&buf->b_count)) { put_bh(buf); return; } WARN(1, KERN_ERR "VFS: brelse: Trying to free free buffer\n"); } /* * bforget() is like brelse(), except it discards any * potentially dirty data. */ void __bforget(struct buffer_head *bh) { clear_buffer_dirty(bh); if (bh->b_assoc_map) { struct address_space *buffer_mapping = bh->b_page->mapping; spin_lock(&buffer_mapping->private_lock); list_del_init(&bh->b_assoc_buffers); bh->b_assoc_map = NULL; spin_unlock(&buffer_mapping->private_lock); } __brelse(bh); } static struct buffer_head *__bread_slow(struct buffer_head *bh) { lock_buffer(bh); if (buffer_uptodate(bh)) { unlock_buffer(bh); return bh; } else { get_bh(bh); bh->b_end_io = end_buffer_read_sync; submit_bh(READ, bh); wait_on_buffer(bh); if (buffer_uptodate(bh)) return bh; } brelse(bh); return NULL; } /* * Per-cpu buffer LRU implementation. To reduce the cost of __find_get_block(). * The bhs[] array is sorted - newest buffer is at bhs[0]. Buffers have their * refcount elevated by one when they're in an LRU. A buffer can only appear * once in a particular CPU's LRU. A single buffer can be present in multiple * CPU's LRUs at the same time. * * This is a transparent caching front-end to sb_bread(), sb_getblk() and * sb_find_get_block(). * * The LRUs themselves only need locking against invalidate_bh_lrus. We use * a local interrupt disable for that. */ #define BH_LRU_SIZE 8 struct bh_lru { struct buffer_head *bhs[BH_LRU_SIZE]; }; static DEFINE_PER_CPU(struct bh_lru, bh_lrus) = {{ NULL }}; #ifdef CONFIG_SMP #define bh_lru_lock() local_irq_disable() #define bh_lru_unlock() local_irq_enable() #else #define bh_lru_lock() preempt_disable() #define bh_lru_unlock() preempt_enable() #endif static inline void check_irqs_on(void) { #ifdef irqs_disabled BUG_ON(irqs_disabled()); #endif } /* * The LRU management algorithm is dopey-but-simple. Sorry. */ static void bh_lru_install(struct buffer_head *bh) { struct buffer_head *evictee = NULL; struct bh_lru *lru; check_irqs_on(); bh_lru_lock(); lru = &__get_cpu_var(bh_lrus); if (lru->bhs[0] != bh) { struct buffer_head *bhs[BH_LRU_SIZE]; int in; int out = 0; get_bh(bh); bhs[out++] = bh; for (in = 0; in < BH_LRU_SIZE; in++) { struct buffer_head *bh2 = lru->bhs[in]; if (bh2 == bh) { __brelse(bh2); } else { if (out >= BH_LRU_SIZE) { BUG_ON(evictee != NULL); evictee = bh2; } else { bhs[out++] = bh2; } } } while (out < BH_LRU_SIZE) bhs[out++] = NULL; memcpy(lru->bhs, bhs, sizeof(bhs)); } bh_lru_unlock(); if (evictee) __brelse(evictee); } /* * Look up the bh in this cpu's LRU. If it's there, move it to the head. */ static struct buffer_head * lookup_bh_lru(struct block_device *bdev, sector_t block, unsigned size) { struct buffer_head *ret = NULL; struct bh_lru *lru; unsigned int i; check_irqs_on(); bh_lru_lock(); lru = &__get_cpu_var(bh_lrus); for (i = 0; i < BH_LRU_SIZE; i++) { struct buffer_head *bh = lru->bhs[i]; if (bh && bh->b_bdev == bdev && bh->b_blocknr == block && bh->b_size == size) { if (i) { while (i) { lru->bhs[i] = lru->bhs[i - 1]; i--; } lru->bhs[0] = bh; } get_bh(bh); ret = bh; break; } } bh_lru_unlock(); return ret; } /* * Perform a pagecache lookup for the matching buffer. If it's there, refresh * it in the LRU and mark it as accessed. If it is not present then return * NULL */ struct buffer_head * __find_get_block(struct block_device *bdev, sector_t block, unsigned size) { struct buffer_head *bh = lookup_bh_lru(bdev, block, size); if (bh == NULL) { bh = __find_get_block_slow(bdev, block); if (bh) bh_lru_install(bh); } if (bh) touch_buffer(bh); return bh; } EXPORT_SYMBOL(__find_get_block); /* * __getblk will locate (and, if necessary, create) the buffer_head * which corresponds to the passed block_device, block and size. The * returned buffer has its reference count incremented. * * __getblk() cannot fail - it just keeps trying. If you pass it an * illegal block number, __getblk() will happily return a buffer_head * which represents the non-existent block. Very weird. * * __getblk() will lock up the machine if grow_dev_page's try_to_free_buffers() * attempt is failing. FIXME, perhaps? */ struct buffer_head * __getblk(struct block_device *bdev, sector_t block, unsigned size) { struct buffer_head *bh = __find_get_block(bdev, block, size); might_sleep(); if (bh == NULL) bh = __getblk_slow(bdev, block, size); return bh; } EXPORT_SYMBOL(__getblk); /* * Do async read-ahead on a buffer.. */ void __breadahead(struct block_device *bdev, sector_t block, unsigned size) { struct buffer_head *bh = __getblk(bdev, block, size); if (likely(bh)) { ll_rw_block(READA, 1, &bh); brelse(bh); } } EXPORT_SYMBOL(__breadahead); /** * __bread() - reads a specified block and returns the bh * @bdev: the block_device to read from * @block: number of block * @size: size (in bytes) to read * * Reads a specified block, and returns buffer head that contains it. * It returns NULL if the block was unreadable. */ struct buffer_head * __bread(struct block_device *bdev, sector_t block, unsigned size) { struct buffer_head *bh = __getblk(bdev, block, size); if (likely(bh) && !buffer_uptodate(bh)) bh = __bread_slow(bh); return bh; } EXPORT_SYMBOL(__bread); /* * invalidate_bh_lrus() is called rarely - but not only at unmount. * This doesn't race because it runs in each cpu either in irq * or with preempt disabled. */ static void invalidate_bh_lru(void *arg) { struct bh_lru *b = &get_cpu_var(bh_lrus); int i; for (i = 0; i < BH_LRU_SIZE; i++) { brelse(b->bhs[i]); b->bhs[i] = NULL; } put_cpu_var(bh_lrus); } void invalidate_bh_lrus(void) { on_each_cpu(invalidate_bh_lru, NULL, 1); } EXPORT_SYMBOL_GPL(invalidate_bh_lrus); void set_bh_page(struct buffer_head *bh, struct page *page, unsigned long offset) { bh->b_page = page; BUG_ON(offset >= PAGE_SIZE); if (PageHighMem(page)) /* * This catches illegal uses and preserves the offset: */ bh->b_data = (char *)(0 + offset); else bh->b_data = page_address(page) + offset; } EXPORT_SYMBOL(set_bh_page); /* * Called when truncating a buffer on a page completely. */ static void discard_buffer(struct buffer_head * bh) { lock_buffer(bh); clear_buffer_dirty(bh); bh->b_bdev = NULL; clear_buffer_mapped(bh); clear_buffer_req(bh); clear_buffer_new(bh); clear_buffer_delay(bh); clear_buffer_unwritten(bh); unlock_buffer(bh); } /** * block_invalidatepage - invalidate part of all of a buffer-backed page * * @page: the page which is affected * @offset: the index of the truncation point * * block_invalidatepage() is called when all or part of the page has become * invalidatedby a truncate operation. * * block_invalidatepage() does not have to release all buffers, but it must * ensure that no dirty buffer is left outside @offset and that no I/O * is underway against any of the blocks which are outside the truncation * point. Because the caller is about to free (and possibly reuse) those * blocks on-disk. */ void block_invalidatepage(struct page *page, unsigned long offset) { struct buffer_head *head, *bh, *next; unsigned int curr_off = 0; BUG_ON(!PageLocked(page)); if (!page_has_buffers(page)) goto out; head = page_buffers(page); bh = head; do { unsigned int next_off = curr_off + bh->b_size; next = bh->b_this_page; /* * is this block fully invalidated? */ if (offset <= curr_off) discard_buffer(bh); curr_off = next_off; bh = next; } while (bh != head); /* * We release buffers only if the entire page is being invalidated. * The get_block cached value has been unconditionally invalidated, * so real IO is not possible anymore. */ if (offset == 0) try_to_release_page(page, 0); out: return; } EXPORT_SYMBOL(block_invalidatepage); /* * We attach and possibly dirty the buffers atomically wrt * __set_page_dirty_buffers() via private_lock. try_to_free_buffers * is already excluded via the page lock. */ void create_empty_buffers(struct page *page, unsigned long blocksize, unsigned long b_state) { struct buffer_head *bh, *head, *tail; head = alloc_page_buffers(page, blocksize, 1); bh = head; do { bh->b_state |= b_state; tail = bh; bh = bh->b_this_page; } while (bh); tail->b_this_page = head; spin_lock(&page->mapping->private_lock); if (PageUptodate(page) || PageDirty(page)) { bh = head; do { if (PageDirty(page)) set_buffer_dirty(bh); if (PageUptodate(page)) set_buffer_uptodate(bh); bh = bh->b_this_page; } while (bh != head); } attach_page_buffers(page, head); spin_unlock(&page->mapping->private_lock); } EXPORT_SYMBOL(create_empty_buffers); /* * We are taking a block for data and we don't want any output from any * buffer-cache aliases starting from return from that function and * until the moment when something will explicitly mark the buffer * dirty (hopefully that will not happen until we will free that block ;-) * We don't even need to mark it not-uptodate - nobody can expect * anything from a newly allocated buffer anyway. We used to used * unmap_buffer() for such invalidation, but that was wrong. We definitely * don't want to mark the alias unmapped, for example - it would confuse * anyone who might pick it with bread() afterwards... * * Also.. Note that bforget() doesn't lock the buffer. So there can * be writeout I/O going on against recently-freed buffers. We don't * wait on that I/O in bforget() - it's more efficient to wait on the I/O * only if we really need to. That happens here. */ void unmap_underlying_metadata(struct block_device *bdev, sector_t block) { struct buffer_head *old_bh; might_sleep(); old_bh = __find_get_block_slow(bdev, block); if (old_bh) { clear_buffer_dirty(old_bh); wait_on_buffer(old_bh); clear_buffer_req(old_bh); __brelse(old_bh); } } EXPORT_SYMBOL(unmap_underlying_metadata); /* * NOTE! All mapped/uptodate combinations are valid: * * Mapped Uptodate Meaning * * No No "unknown" - must do get_block() * No Yes "hole" - zero-filled * Yes No "allocated" - allocated on disk, not read in * Yes Yes "valid" - allocated and up-to-date in memory. * * "Dirty" is valid only with the last case (mapped+uptodate). */ /* * While block_write_full_page is writing back the dirty buffers under * the page lock, whoever dirtied the buffers may decide to clean them * again at any time. We handle that by only looking at the buffer * state inside lock_buffer(). * * If block_write_full_page() is called for regular writeback * (wbc->sync_mode == WB_SYNC_NONE) then it will redirty a page which has a * locked buffer. This only can happen if someone has written the buffer * directly, with submit_bh(). At the address_space level PageWriteback * prevents this contention from occurring. */ static int __block_write_full_page(struct inode *inode, struct page *page, get_block_t *get_block, struct writeback_control *wbc) { int err; sector_t block; sector_t last_block; struct buffer_head *bh, *head; const unsigned blocksize = 1 << inode->i_blkbits; int nr_underway = 0; BUG_ON(!PageLocked(page)); last_block = (i_size_read(inode) - 1) >> inode->i_blkbits; if (!page_has_buffers(page)) { create_empty_buffers(page, blocksize, (1 << BH_Dirty)|(1 << BH_Uptodate)); } /* * Be very careful. We have no exclusion from __set_page_dirty_buffers * here, and the (potentially unmapped) buffers may become dirty at * any time. If a buffer becomes dirty here after we've inspected it * then we just miss that fact, and the page stays dirty. * * Buffers outside i_size may be dirtied by __set_page_dirty_buffers; * handle that here by just cleaning them. */ block = (sector_t)page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits); head = page_buffers(page); bh = head; /* * Get all the dirty buffers mapped to disk addresses and * handle any aliases from the underlying blockdev's mapping. */ do { if (block > last_block) { /* * mapped buffers outside i_size will occur, because * this page can be outside i_size when there is a * truncate in progress. */ /* * The buffer was zeroed by block_write_full_page() */ clear_buffer_dirty(bh); set_buffer_uptodate(bh); } else if ((!buffer_mapped(bh) || buffer_delay(bh)) && buffer_dirty(bh)) { WARN_ON(bh->b_size != blocksize); err = get_block(inode, block, bh, 1); if (err) goto recover; clear_buffer_delay(bh); if (buffer_new(bh)) { /* blockdev mappings never come here */ clear_buffer_new(bh); unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr); } } bh = bh->b_this_page; block++; } while (bh != head); do { if (!buffer_mapped(bh)) continue; /* * If it's a fully non-blocking write attempt and we cannot * lock the buffer then redirty the page. Note that this can * potentially cause a busy-wait loop from pdflush and kswapd * activity, but those code paths have their own higher-level * throttling. */ if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) { lock_buffer(bh); } else if (!trylock_buffer(bh)) { redirty_page_for_writepage(wbc, page); continue; } if (test_clear_buffer_dirty(bh)) { mark_buffer_async_write(bh); } else { unlock_buffer(bh); } } while ((bh = bh->b_this_page) != head); /* * The page and its buffers are protected by PageWriteback(), so we can * drop the bh refcounts early. */ BUG_ON(PageWriteback(page)); set_page_writeback(page); do { struct buffer_head *next = bh->b_this_page; if (buffer_async_write(bh)) { submit_bh(WRITE, bh); nr_underway++; } bh = next; } while (bh != head); unlock_page(page); err = 0; done: if (nr_underway == 0) { /* * The page was marked dirty, but the buffers were * clean. Someone wrote them back by hand with * ll_rw_block/submit_bh. A rare case. */ end_page_writeback(page); /* * The page and buffer_heads can be released at any time from * here on. */ } return err; recover: /* * ENOSPC, or some other error. We may already have added some * blocks to the file, so we need to write these out to avoid * exposing stale data. * The page is currently locked and not marked for writeback */ bh = head; /* Recovery: lock and submit the mapped buffers */ do { if (buffer_mapped(bh) && buffer_dirty(bh) && !buffer_delay(bh)) { lock_buffer(bh); mark_buffer_async_write(bh); } else { /* * The buffer may have been set dirty during * attachment to a dirty page. */ clear_buffer_dirty(bh); } } while ((bh = bh->b_this_page) != head); SetPageError(page); BUG_ON(PageWriteback(page)); mapping_set_error(page->mapping, err); set_page_writeback(page); do { struct buffer_head *next = bh->b_this_page; if (buffer_async_write(bh)) { clear_buffer_dirty(bh); submit_bh(WRITE, bh); nr_underway++; } bh = next; } while (bh != head); unlock_page(page); goto done; } /* * If a page has any new buffers, zero them out here, and mark them uptodate * and dirty so they'll be written out (in order to prevent uninitialised * block data from leaking). And clear the new bit. */ void page_zero_new_buffers(struct page *page, unsigned from, unsigned to) { unsigned int block_start, block_end; struct buffer_head *head, *bh; BUG_ON(!PageLocked(page)); if (!page_has_buffers(page)) return; bh = head = page_buffers(page); block_start = 0; do { block_end = block_start + bh->b_size; if (buffer_new(bh)) { if (block_end > from && block_start < to) { if (!PageUptodate(page)) { unsigned start, size; start = max(from, block_start); size = min(to, block_end) - start; zero_user(page, start, size); set_buffer_uptodate(bh); } clear_buffer_new(bh); mark_buffer_dirty(bh); } } block_start = block_end; bh = bh->b_this_page; } while (bh != head); } EXPORT_SYMBOL(page_zero_new_buffers); static int __block_prepare_write(struct inode *inode, struct page *page, unsigned from, unsigned to, get_block_t *get_block) { unsigned block_start, block_end; sector_t block; int err = 0; unsigned blocksize, bbits; struct buffer_head *bh, *head, *wait[2], **wait_bh=wait; BUG_ON(!PageLocked(page)); BUG_ON(from > PAGE_CACHE_SIZE); BUG_ON(to > PAGE_CACHE_SIZE); BUG_ON(from > to); blocksize = 1 << inode->i_blkbits; if (!page_has_buffers(page)) create_empty_buffers(page, blocksize, 0); head = page_buffers(page); bbits = inode->i_blkbits; block = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits); for(bh = head, block_start = 0; bh != head || !block_start; block++, block_start=block_end, bh = bh->b_this_page) { block_end = block_start + blocksize; if (block_end <= from || block_start >= to) { if (PageUptodate(page)) { if (!buffer_uptodate(bh)) set_buffer_uptodate(bh); } continue; } if (buffer_new(bh)) clear_buffer_new(bh); if (!buffer_mapped(bh)) { WARN_ON(bh->b_size != blocksize); err = get_block(inode, block, bh, 1); if (err) break; if (buffer_new(bh)) { unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr); if (PageUptodate(page)) { clear_buffer_new(bh); set_buffer_uptodate(bh); mark_buffer_dirty(bh); continue; } if (block_end > to || block_start < from) zero_user_segments(page, to, block_end, block_start, from); continue; } } if (PageUptodate(page)) { if (!buffer_uptodate(bh)) set_buffer_uptodate(bh); continue; } if (!buffer_uptodate(bh) && !buffer_delay(bh) && !buffer_unwritten(bh) && (block_start < from || block_end > to)) { ll_rw_block(READ, 1, &bh); *wait_bh++=bh; } } /* * If we issued read requests - let them complete. */ while(wait_bh > wait) { wait_on_buffer(*--wait_bh); if (!buffer_uptodate(*wait_bh)) err = -EIO; } if (unlikely(err)) page_zero_new_buffers(page, from, to); return err; } static int __block_commit_write(struct inode *inode, struct page *page, unsigned from, unsigned to) { unsigned block_start, block_end; int partial = 0; unsigned blocksize; struct buffer_head *bh, *head; blocksize = 1 << inode->i_blkbits; for(bh = head = page_buffers(page), block_start = 0; bh != head || !block_start; block_start=block_end, bh = bh->b_this_page) { block_end = block_start + blocksize; if (block_end <= from || block_start >= to) { if (!buffer_uptodate(bh)) partial = 1; } else { set_buffer_uptodate(bh); mark_buffer_dirty(bh); } clear_buffer_new(bh); } /* * If this is a partial write which happened to make all buffers * uptodate then we can optimize away a bogus readpage() for * the next read(). Here we 'discover' whether the page went * uptodate as a result of this (potentially partial) write. */ if (!partial) SetPageUptodate(page); return 0; } /* * block_write_begin takes care of the basic task of block allocation and * bringing partial write blocks uptodate first. * * If *pagep is not NULL, then block_write_begin uses the locked page * at *pagep rather than allocating its own. In this case, the page will * not be unlocked or deallocated on failure. */ int block_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata, get_block_t *get_block) { struct inode *inode = mapping->host; int status = 0; struct page *page; pgoff_t index; unsigned start, end; int ownpage = 0; index = pos >> PAGE_CACHE_SHIFT; start = pos & (PAGE_CACHE_SIZE - 1); end = start + len; page = *pagep; if (page == NULL) { ownpage = 1; page = grab_cache_page_write_begin(mapping, index, flags); if (!page) { status = -ENOMEM; goto out; } *pagep = page; } else BUG_ON(!PageLocked(page)); status = __block_prepare_write(inode, page, start, end, get_block); if (unlikely(status)) { ClearPageUptodate(page); if (ownpage) { unlock_page(page); page_cache_release(page); *pagep = NULL; /* * prepare_write() may have instantiated a few blocks * outside i_size. Trim these off again. Don't need * i_size_read because we hold i_mutex. */ if (pos + len > inode->i_size) vmtruncate(inode, inode->i_size); } goto out; } out: return status; } EXPORT_SYMBOL(block_write_begin); int block_write_end(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata) { struct inode *inode = mapping->host; unsigned start; start = pos & (PAGE_CACHE_SIZE - 1); if (unlikely(copied < len)) { /* * The buffers that were written will now be uptodate, so we * don't have to worry about a readpage reading them and * overwriting a partial write. However if we have encountered * a short write and only partially written into a buffer, it * will not be marked uptodate, so a readpage might come in and * destroy our partial write. * * Do the simplest thing, and just treat any short write to a * non uptodate page as a zero-length write, and force the * caller to redo the whole thing. */ if (!PageUptodate(page)) copied = 0; page_zero_new_buffers(page, start+copied, start+len); } flush_dcache_page(page); /* This could be a short (even 0-length) commit */ __block_commit_write(inode, page, start, start+copied); return copied; } EXPORT_SYMBOL(block_write_end); int generic_write_end(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata) { struct inode *inode = mapping->host; int i_size_changed = 0; copied = block_write_end(file, mapping, pos, len, copied, page, fsdata); /* * No need to use i_size_read() here, the i_size * cannot change under us because we hold i_mutex. * * But it's important to update i_size while still holding page lock: * page writeout could otherwise come in and zero beyond i_size. */ if (pos+copied > inode->i_size) { i_size_write(inode, pos+copied); i_size_changed = 1; } unlock_page(page); page_cache_release(page); /* * Don't mark the inode dirty under page lock. First, it unnecessarily * makes the holding time of page lock longer. Second, it forces lock * ordering of page lock and transaction start for journaling * filesystems. */ if (i_size_changed) mark_inode_dirty(inode); return copied; } EXPORT_SYMBOL(generic_write_end); /* * block_is_partially_uptodate checks whether buffers within a page are * uptodate or not. * * Returns true if all buffers which correspond to a file portion * we want to read are uptodate. */ int block_is_partially_uptodate(struct page *page, read_descriptor_t *desc, unsigned long from) { struct inode *inode = page->mapping->host; unsigned block_start, block_end, blocksize; unsigned to; struct buffer_head *bh, *head; int ret = 1; if (!page_has_buffers(page)) return 0; blocksize = 1 << inode->i_blkbits; to = min_t(unsigned, PAGE_CACHE_SIZE - from, desc->count); to = from + to; if (from < blocksize && to > PAGE_CACHE_SIZE - blocksize) return 0; head = page_buffers(page); bh = head; block_start = 0; do { block_end = block_start + blocksize; if (block_end > from && block_start < to) { if (!buffer_uptodate(bh)) { ret = 0; break; } if (block_end >= to) break; } block_start = block_end; bh = bh->b_this_page; } while (bh != head); return ret; } EXPORT_SYMBOL(block_is_partially_uptodate); /* * Generic "read page" function for block devices that have the normal * get_block functionality. This is most of the block device filesystems. * Reads the page asynchronously --- the unlock_buffer() and * set/clear_buffer_uptodate() functions propagate buffer state into the * page struct once IO has completed. */ int block_read_full_page(struct page *page, get_block_t *get_block) { struct inode *inode = page->mapping->host; sector_t iblock, lblock; struct buffer_head *bh, *head, *arr[MAX_BUF_PER_PAGE]; unsigned int blocksize; int nr, i; int fully_mapped = 1; BUG_ON(!PageLocked(page)); blocksize = 1 << inode->i_blkbits; if (!page_has_buffers(page)) create_empty_buffers(page, blocksize, 0); head = page_buffers(page); iblock = (sector_t)page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits); lblock = (i_size_read(inode)+blocksize-1) >> inode->i_blkbits; bh = head; nr = 0; i = 0; do { if (buffer_uptodate(bh)) continue; if (!buffer_mapped(bh)) { int err = 0; fully_mapped = 0; if (iblock < lblock) { WARN_ON(bh->b_size != blocksize); err = get_block(inode, iblock, bh, 0); if (err) SetPageError(page); } if (!buffer_mapped(bh)) { zero_user(page, i * blocksize, blocksize); if (!err) set_buffer_uptodate(bh); continue; } /* * get_block() might have updated the buffer * synchronously */ if (buffer_uptodate(bh)) continue; } arr[nr++] = bh; } while (i++, iblock++, (bh = bh->b_this_page) != head); if (fully_mapped) SetPageMappedToDisk(page); if (!nr) { /* * All buffers are uptodate - we can set the page uptodate * as well. But not if get_block() returned an error. */ if (!PageError(page)) SetPageUptodate(page); unlock_page(page); return 0; } /* Stage two: lock the buffers */ for (i = 0; i < nr; i++) { bh = arr[i]; lock_buffer(bh); mark_buffer_async_read(bh); } /* * Stage 3: start the IO. Check for uptodateness * inside the buffer lock in case another process reading * the underlying blockdev brought it uptodate (the sct fix). */ for (i = 0; i < nr; i++) { bh = arr[i]; if (buffer_uptodate(bh)) end_buffer_async_read(bh, 1); else submit_bh(READ, bh); } return 0; } /* utility function for filesystems that need to do work on expanding * truncates. Uses filesystem pagecache writes to allow the filesystem to * deal with the hole. */ int generic_cont_expand_simple(struct inode *inode, loff_t size) { struct address_space *mapping = inode->i_mapping; struct page *page; void *fsdata; unsigned long limit; int err; err = -EFBIG; limit = current->signal->rlim[RLIMIT_FSIZE].rlim_cur; if (limit != RLIM_INFINITY && size > (loff_t)limit) { send_sig(SIGXFSZ, current, 0); goto out; } if (size > inode->i_sb->s_maxbytes) goto out; err = pagecache_write_begin(NULL, mapping, size, 0, AOP_FLAG_UNINTERRUPTIBLE|AOP_FLAG_CONT_EXPAND, &page, &fsdata); if (err) goto out; err = pagecache_write_end(NULL, mapping, size, 0, 0, page, fsdata); BUG_ON(err > 0); out: return err; } static int cont_expand_zero(struct file *file, struct address_space *mapping, loff_t pos, loff_t *bytes) { struct inode *inode = mapping->host; unsigned blocksize = 1 << inode->i_blkbits; struct page *page; void *fsdata; pgoff_t index, curidx; loff_t curpos; unsigned zerofrom, offset, len; int err = 0; index = pos >> PAGE_CACHE_SHIFT; offset = pos & ~PAGE_CACHE_MASK; while (index > (curidx = (curpos = *bytes)>>PAGE_CACHE_SHIFT)) { zerofrom = curpos & ~PAGE_CACHE_MASK; if (zerofrom & (blocksize-1)) { *bytes |= (blocksize-1); (*bytes)++; } len = PAGE_CACHE_SIZE - zerofrom; err = pagecache_write_begin(file, mapping, curpos, len, AOP_FLAG_UNINTERRUPTIBLE, &page, &fsdata); if (err) goto out; zero_user(page, zerofrom, len); err = pagecache_write_end(file, mapping, curpos, len, len, page, fsdata); if (err < 0) goto out; BUG_ON(err != len); err = 0; balance_dirty_pages_ratelimited(mapping); } /* page covers the boundary, find the boundary offset */ if (index == curidx) { zerofrom = curpos & ~PAGE_CACHE_MASK; /* if we will expand the thing last block will be filled */ if (offset <= zerofrom) { goto out; } if (zerofrom & (blocksize-1)) { *bytes |= (blocksize-1); (*bytes)++; } len = offset - zerofrom; err = pagecache_write_begin(file, mapping, curpos, len, AOP_FLAG_UNINTERRUPTIBLE, &page, &fsdata); if (err) goto out; zero_user(page, zerofrom, len); err = pagecache_write_end(file, mapping, curpos, len, len, page, fsdata); if (err < 0) goto out; BUG_ON(err != len); err = 0; } out: return err; } /* * For moronic filesystems that do not allow holes in file. * We may have to extend the file. */ int cont_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata, get_block_t *get_block, loff_t *bytes) { struct inode *inode = mapping->host; unsigned blocksize = 1 << inode->i_blkbits; unsigned zerofrom; int err; err = cont_expand_zero(file, mapping, pos, bytes); if (err) goto out; zerofrom = *bytes & ~PAGE_CACHE_MASK; if (pos+len > *bytes && zerofrom & (blocksize-1)) { *bytes |= (blocksize-1); (*bytes)++; } *pagep = NULL; err = block_write_begin(file, mapping, pos, len, flags, pagep, fsdata, get_block); out: return err; } int block_prepare_write(struct page *page, unsigned from, unsigned to, get_block_t *get_block) { struct inode *inode = page->mapping->host; int err = __block_prepare_write(inode, page, from, to, get_block); if (err) ClearPageUptodate(page); return err; } int block_commit_write(struct page *page, unsigned from, unsigned to) { struct inode *inode = page->mapping->host; __block_commit_write(inode,page,from,to); return 0; } /* * block_page_mkwrite() is not allowed to change the file size as it gets * called from a page fault handler when a page is first dirtied. Hence we must * be careful to check for EOF conditions here. We set the page up correctly * for a written page which means we get ENOSPC checking when writing into * holes and correct delalloc and unwritten extent mapping on filesystems that * support these features. * * We are not allowed to take the i_mutex here so we have to play games to * protect against truncate races as the page could now be beyond EOF. Because * vmtruncate() writes the inode size before removing pages, once we have the * page lock we can determine safely if the page is beyond EOF. If it is not * beyond EOF, then the page is guaranteed safe against truncation until we * unlock the page. */ int block_page_mkwrite(struct vm_area_struct *vma, struct page *page, get_block_t get_block) { struct inode *inode = vma->vm_file->f_path.dentry->d_inode; unsigned long end; loff_t size; int ret = -EINVAL; lock_page(page); size = i_size_read(inode); if ((page->mapping != inode->i_mapping) || (page_offset(page) > size)) { /* page got truncated out from underneath us */ goto out_unlock; } /* page is wholly or partially inside EOF */ if (((page->index + 1) << PAGE_CACHE_SHIFT) > size) end = size & ~PAGE_CACHE_MASK; else end = PAGE_CACHE_SIZE; ret = block_prepare_write(page, 0, end, get_block); if (!ret) ret = block_commit_write(page, 0, end); out_unlock: unlock_page(page); return ret; } /* * nobh_write_begin()'s prereads are special: the buffer_heads are freed * immediately, while under the page lock. So it needs a special end_io * handler which does not touch the bh after unlocking it. */ static void end_buffer_read_nobh(struct buffer_head *bh, int uptodate) { __end_buffer_read_notouch(bh, uptodate); } /* * Attach the singly-linked list of buffers created by nobh_write_begin, to * the page (converting it to circular linked list and taking care of page * dirty races). */ static void attach_nobh_buffers(struct page *page, struct buffer_head *head) { struct buffer_head *bh; BUG_ON(!PageLocked(page)); spin_lock(&page->mapping->private_lock); bh = head; do { if (PageDirty(page)) set_buffer_dirty(bh); if (!bh->b_this_page) bh->b_this_page = head; bh = bh->b_this_page; } while (bh != head); attach_page_buffers(page, head); spin_unlock(&page->mapping->private_lock); } /* * On entry, the page is fully not uptodate. * On exit the page is fully uptodate in the areas outside (from,to) */ int nobh_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata, get_block_t *get_block) { struct inode *inode = mapping->host; const unsigned blkbits = inode->i_blkbits; const unsigned blocksize = 1 << blkbits; struct buffer_head *head, *bh; struct page *page; pgoff_t index; unsigned from, to; unsigned block_in_page; unsigned block_start, block_end; sector_t block_in_file; int nr_reads = 0; int ret = 0; int is_mapped_to_disk = 1; index = pos >> PAGE_CACHE_SHIFT; from = pos & (PAGE_CACHE_SIZE - 1); to = from + len; page = grab_cache_page_write_begin(mapping, index, flags); if (!page) return -ENOMEM; *pagep = page; *fsdata = NULL; if (page_has_buffers(page)) { unlock_page(page); page_cache_release(page); *pagep = NULL; return block_write_begin(file, mapping, pos, len, flags, pagep, fsdata, get_block); } if (PageMappedToDisk(page)) return 0; /* * Allocate buffers so that we can keep track of state, and potentially * attach them to the page if an error occurs. In the common case of * no error, they will just be freed again without ever being attached * to the page (which is all OK, because we're under the page lock). * * Be careful: the buffer linked list is a NULL terminated one, rather * than the circular one we're used to. */ head = alloc_page_buffers(page, blocksize, 0); if (!head) { ret = -ENOMEM; goto out_release; } block_in_file = (sector_t)page->index << (PAGE_CACHE_SHIFT - blkbits); /* * We loop across all blocks in the page, whether or not they are * part of the affected region. This is so we can discover if the * page is fully mapped-to-disk. */ for (block_start = 0, block_in_page = 0, bh = head; block_start < PAGE_CACHE_SIZE; block_in_page++, block_start += blocksize, bh = bh->b_this_page) { int create; block_end = block_start + blocksize; bh->b_state = 0; create = 1; if (block_start >= to) create = 0; ret = get_block(inode, block_in_file + block_in_page, bh, create); if (ret) goto failed; if (!buffer_mapped(bh)) is_mapped_to_disk = 0; if (buffer_new(bh)) unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr); if (PageUptodate(page)) { set_buffer_uptodate(bh); continue; } if (buffer_new(bh) || !buffer_mapped(bh)) { zero_user_segments(page, block_start, from, to, block_end); continue; } if (buffer_uptodate(bh)) continue; /* reiserfs does this */ if (block_start < from || block_end > to) { lock_buffer(bh); bh->b_end_io = end_buffer_read_nobh; submit_bh(READ, bh); nr_reads++; } } if (nr_reads) { /* * The page is locked, so these buffers are protected from * any VM or truncate activity. Hence we don't need to care * for the buffer_head refcounts. */ for (bh = head; bh; bh = bh->b_this_page) { wait_on_buffer(bh); if (!buffer_uptodate(bh)) ret = -EIO; } if (ret) goto failed; } if (is_mapped_to_disk) SetPageMappedToDisk(page); *fsdata = head; /* to be released by nobh_write_end */ return 0; failed: BUG_ON(!ret); /* * Error recovery is a bit difficult. We need to zero out blocks that * were newly allocated, and dirty them to ensure they get written out. * Buffers need to be attached to the page at this point, otherwise * the handling of potential IO errors during writeout would be hard * (could try doing synchronous writeout, but what if that fails too?) */ attach_nobh_buffers(page, head); page_zero_new_buffers(page, from, to); out_release: unlock_page(page); page_cache_release(page); *pagep = NULL; if (pos + len > inode->i_size) vmtruncate(inode, inode->i_size); return ret; } EXPORT_SYMBOL(nobh_write_begin); int nobh_write_end(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata) { struct inode *inode = page->mapping->host; struct buffer_head *head = fsdata; struct buffer_head *bh; BUG_ON(fsdata != NULL && page_has_buffers(page)); if (unlikely(copied < len) && !page_has_buffers(page)) attach_nobh_buffers(page, head); if (page_has_buffers(page)) return generic_write_end(file, mapping, pos, len, copied, page, fsdata); SetPageUptodate(page); set_page_dirty(page); if (pos+copied > inode->i_size) { i_size_write(inode, pos+copied); mark_inode_dirty(inode); } unlock_page(page); page_cache_release(page); while (head) { bh = head; head = head->b_this_page; free_buffer_head(bh); } return copied; } EXPORT_SYMBOL(nobh_write_end); /* * nobh_writepage() - based on block_full_write_page() except * that it tries to operate without attaching bufferheads to * the page. */ int nobh_writepage(struct page *page, get_block_t *get_block, struct writeback_control *wbc) { struct inode * const inode = page->mapping->host; loff_t i_size = i_size_read(inode); const pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT; unsigned offset; int ret; /* Is the page fully inside i_size? */ if (page->index < end_index) goto out; /* Is the page fully outside i_size? (truncate in progress) */ offset = i_size & (PAGE_CACHE_SIZE-1); if (page->index >= end_index+1 || !offset) { /* * The page may have dirty, unmapped buffers. For example, * they may have been added in ext3_writepage(). Make them * freeable here, so the page does not leak. */ #if 0 /* Not really sure about this - do we need this ? */ if (page->mapping->a_ops->invalidatepage) page->mapping->a_ops->invalidatepage(page, offset); #endif unlock_page(page); return 0; /* don't care */ } /* * The page straddles i_size. It must be zeroed out on each and every * writepage invocation because it may be mmapped. "A file is mapped * in multiples of the page size. For a file that is not a multiple of * the page size, the remaining memory is zeroed when mapped, and * writes to that region are not written out to the file." */ zero_user_segment(page, offset, PAGE_CACHE_SIZE); out: ret = mpage_writepage(page, get_block, wbc); if (ret == -EAGAIN) ret = __block_write_full_page(inode, page, get_block, wbc); return ret; } EXPORT_SYMBOL(nobh_writepage); int nobh_truncate_page(struct address_space *mapping, loff_t from, get_block_t *get_block) { pgoff_t index = from >> PAGE_CACHE_SHIFT; unsigned offset = from & (PAGE_CACHE_SIZE-1); unsigned blocksize; sector_t iblock; unsigned length, pos; struct inode *inode = mapping->host; struct page *page; struct buffer_head map_bh; int err; blocksize = 1 << inode->i_blkbits; length = offset & (blocksize - 1); /* Block boundary? Nothing to do */ if (!length) return 0; length = blocksize - length; iblock = (sector_t)index << (PAGE_CACHE_SHIFT - inode->i_blkbits); page = grab_cache_page(mapping, index); err = -ENOMEM; if (!page) goto out; if (page_has_buffers(page)) { has_buffers: unlock_page(page); page_cache_release(page); return block_truncate_page(mapping, from, get_block); } /* Find the buffer that contains "offset" */ pos = blocksize; while (offset >= pos) { iblock++; pos += blocksize; } err = get_block(inode, iblock, &map_bh, 0); if (err) goto unlock; /* unmapped? It's a hole - nothing to do */ if (!buffer_mapped(&map_bh)) goto unlock; /* Ok, it's mapped. Make sure it's up-to-date */ if (!PageUptodate(page)) { err = mapping->a_ops->readpage(NULL, page); if (err) { page_cache_release(page); goto out; } lock_page(page); if (!PageUptodate(page)) { err = -EIO; goto unlock; } if (page_has_buffers(page)) goto has_buffers; } zero_user(page, offset, length); set_page_dirty(page); err = 0; unlock: unlock_page(page); page_cache_release(page); out: return err; } EXPORT_SYMBOL(nobh_truncate_page); int block_truncate_page(struct address_space *mapping, loff_t from, get_block_t *get_block) { pgoff_t index = from >> PAGE_CACHE_SHIFT; unsigned offset = from & (PAGE_CACHE_SIZE-1); unsigned blocksize; sector_t iblock; unsigned length, pos; struct inode *inode = mapping->host; struct page *page; struct buffer_head *bh; int err; blocksize = 1 << inode->i_blkbits; length = offset & (blocksize - 1); /* Block boundary? Nothing to do */ if (!length) return 0; length = blocksize - length; iblock = (sector_t)index << (PAGE_CACHE_SHIFT - inode->i_blkbits); page = grab_cache_page(mapping, index); err = -ENOMEM; if (!page) goto out; if (!page_has_buffers(page)) create_empty_buffers(page, blocksize, 0); /* Find the buffer that contains "offset" */ bh = page_buffers(page); pos = blocksize; while (offset >= pos) { bh = bh->b_this_page; iblock++; pos += blocksize; } err = 0; if (!buffer_mapped(bh)) { WARN_ON(bh->b_size != blocksize); err = get_block(inode, iblock, bh, 0); if (err) goto unlock; /* unmapped? It's a hole - nothing to do */ if (!buffer_mapped(bh)) goto unlock; } /* Ok, it's mapped. Make sure it's up-to-date */ if (PageUptodate(page)) set_buffer_uptodate(bh); if (!buffer_uptodate(bh) && !buffer_delay(bh) && !buffer_unwritten(bh)) { err = -EIO; ll_rw_block(READ, 1, &bh); wait_on_buffer(bh); /* Uhhuh. Read error. Complain and punt. */ if (!buffer_uptodate(bh)) goto unlock; } zero_user(page, offset, length); mark_buffer_dirty(bh); err = 0; unlock: unlock_page(page); page_cache_release(page); out: return err; } /* * The generic ->writepage function for buffer-backed address_spaces */ int block_write_full_page(struct page *page, get_block_t *get_block, struct writeback_control *wbc) { struct inode * const inode = page->mapping->host; loff_t i_size = i_size_read(inode); const pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT; unsigned offset; /* Is the page fully inside i_size? */ if (page->index < end_index) return __block_write_full_page(inode, page, get_block, wbc); /* Is the page fully outside i_size? (truncate in progress) */ offset = i_size & (PAGE_CACHE_SIZE-1); if (page->index >= end_index+1 || !offset) { /* * The page may have dirty, unmapped buffers. For example, * they may have been added in ext3_writepage(). Make them * freeable here, so the page does not leak. */ do_invalidatepage(page, 0); unlock_page(page); return 0; /* don't care */ } /* * The page straddles i_size. It must be zeroed out on each and every * writepage invokation because it may be mmapped. "A file is mapped * in multiples of the page size. For a file that is not a multiple of * the page size, the remaining memory is zeroed when mapped, and * writes to that region are not written out to the file." */ zero_user_segment(page, offset, PAGE_CACHE_SIZE); return __block_write_full_page(inode, page, get_block, wbc); } sector_t generic_block_bmap(struct address_space *mapping, sector_t block, get_block_t *get_block) { struct buffer_head tmp; struct inode *inode = mapping->host; tmp.b_state = 0; tmp.b_blocknr = 0; tmp.b_size = 1 << inode->i_blkbits; get_block(inode, block, &tmp, 0); return tmp.b_blocknr; } static void end_bio_bh_io_sync(struct bio *bio, int err) { struct buffer_head *bh = bio->bi_private; if (err == -EOPNOTSUPP) { set_bit(BIO_EOPNOTSUPP, &bio->bi_flags); set_bit(BH_Eopnotsupp, &bh->b_state); } bh->b_end_io(bh, test_bit(BIO_UPTODATE, &bio->bi_flags)); bio_put(bio); } int submit_bh(int rw, struct buffer_head * bh) { struct bio *bio; int ret = 0; BUG_ON(!buffer_locked(bh)); BUG_ON(!buffer_mapped(bh)); BUG_ON(!bh->b_end_io); /* * Mask in barrier bit for a write (could be either a WRITE or a * WRITE_SYNC */ if (buffer_ordered(bh) && (rw & WRITE)) rw |= WRITE_BARRIER; /* * Only clear out a write error when rewriting */ if (test_set_buffer_req(bh) && (rw & WRITE)) clear_buffer_write_io_error(bh); /* * from here on down, it's all bio -- do the initial mapping, * submit_bio -> generic_make_request may further map this bio around */ bio = bio_alloc(GFP_NOIO, 1); bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9); bio->bi_bdev = bh->b_bdev; bio->bi_io_vec[0].bv_page = bh->b_page; bio->bi_io_vec[0].bv_len = bh->b_size; bio->bi_io_vec[0].bv_offset = bh_offset(bh); bio->bi_vcnt = 1; bio->bi_idx = 0; bio->bi_size = bh->b_size; bio->bi_end_io = end_bio_bh_io_sync; bio->bi_private = bh; bio_get(bio); submit_bio(rw, bio); if (bio_flagged(bio, BIO_EOPNOTSUPP)) ret = -EOPNOTSUPP; bio_put(bio); return ret; } /** * ll_rw_block: low-level access to block devices (DEPRECATED) * @rw: whether to %READ or %WRITE or %SWRITE or maybe %READA (readahead) * @nr: number of &struct buffer_heads in the array * @bhs: array of pointers to &struct buffer_head * * ll_rw_block() takes an array of pointers to &struct buffer_heads, and * requests an I/O operation on them, either a %READ or a %WRITE. The third * %SWRITE is like %WRITE only we make sure that the *current* data in buffers * are sent to disk. The fourth %READA option is described in the documentation * for generic_make_request() which ll_rw_block() calls. * * This function drops any buffer that it cannot get a lock on (with the * BH_Lock state bit) unless SWRITE is required, any buffer that appears to be * clean when doing a write request, and any buffer that appears to be * up-to-date when doing read request. Further it marks as clean buffers that * are processed for writing (the buffer cache won't assume that they are * actually clean until the buffer gets unlocked). * * ll_rw_block sets b_end_io to simple completion handler that marks * the buffer up-to-date (if approriate), unlocks the buffer and wakes * any waiters. * * All of the buffers must be for the same device, and must also be a * multiple of the current approved size for the device. */ void ll_rw_block(int rw, int nr, struct buffer_head *bhs[]) { int i; for (i = 0; i < nr; i++) { struct buffer_head *bh = bhs[i]; if (rw == SWRITE || rw == SWRITE_SYNC) lock_buffer(bh); else if (!trylock_buffer(bh)) continue; if (rw == WRITE || rw == SWRITE || rw == SWRITE_SYNC) { if (test_clear_buffer_dirty(bh)) { bh->b_end_io = end_buffer_write_sync; get_bh(bh); if (rw == SWRITE_SYNC) submit_bh(WRITE_SYNC, bh); else submit_bh(WRITE, bh); continue; } } else { if (!buffer_uptodate(bh)) { bh->b_end_io = end_buffer_read_sync; get_bh(bh); submit_bh(rw, bh); continue; } } unlock_buffer(bh); } } /* * For a data-integrity writeout, we need to wait upon any in-progress I/O * and then start new I/O and then wait upon it. The caller must have a ref on * the buffer_head. */ int sync_dirty_buffer(struct buffer_head *bh) { int ret = 0; WARN_ON(atomic_read(&bh->b_count) < 1); lock_buffer(bh); if (test_clear_buffer_dirty(bh)) { get_bh(bh); bh->b_end_io = end_buffer_write_sync; ret = submit_bh(WRITE_SYNC, bh); wait_on_buffer(bh); if (buffer_eopnotsupp(bh)) { clear_buffer_eopnotsupp(bh); ret = -EOPNOTSUPP; } if (!ret && !buffer_uptodate(bh)) ret = -EIO; } else { unlock_buffer(bh); } return ret; } /* * try_to_free_buffers() checks if all the buffers on this particular page * are unused, and releases them if so. * * Exclusion against try_to_free_buffers may be obtained by either * locking the page or by holding its mapping's private_lock. * * If the page is dirty but all the buffers are clean then we need to * be sure to mark the page clean as well. This is because the page * may be against a block device, and a later reattachment of buffers * to a dirty page will set *all* buffers dirty. Which would corrupt * filesystem data on the same device. * * The same applies to regular filesystem pages: if all the buffers are * clean then we set the page clean and proceed. To do that, we require * total exclusion from __set_page_dirty_buffers(). That is obtained with * private_lock. * * try_to_free_buffers() is non-blocking. */ static inline int buffer_busy(struct buffer_head *bh) { return atomic_read(&bh->b_count) | (bh->b_state & ((1 << BH_Dirty) | (1 << BH_Lock))); } static int drop_buffers(struct page *page, struct buffer_head **buffers_to_free) { struct buffer_head *head = page_buffers(page); struct buffer_head *bh; bh = head; do { if (buffer_write_io_error(bh) && page->mapping) set_bit(AS_EIO, &page->mapping->flags); if (buffer_busy(bh)) goto failed; bh = bh->b_this_page; } while (bh != head); do { struct buffer_head *next = bh->b_this_page; if (bh->b_assoc_map) __remove_assoc_queue(bh); bh = next; } while (bh != head); *buffers_to_free = head; __clear_page_buffers(page); return 1; failed: return 0; } int try_to_free_buffers(struct page *page) { struct address_space * const mapping = page->mapping; struct buffer_head *buffers_to_free = NULL; int ret = 0; BUG_ON(!PageLocked(page)); if (PageWriteback(page)) return 0; if (mapping == NULL) { /* can this still happen? */ ret = drop_buffers(page, &buffers_to_free); goto out; } spin_lock(&mapping->private_lock); ret = drop_buffers(page, &buffers_to_free); /* * If the filesystem writes its buffers by hand (eg ext3) * then we can have clean buffers against a dirty page. We * clean the page here; otherwise the VM will never notice * that the filesystem did any IO at all. * * Also, during truncate, discard_buffer will have marked all * the page's buffers clean. We discover that here and clean * the page also. * * private_lock must be held over this entire operation in order * to synchronise against __set_page_dirty_buffers and prevent the * dirty bit from being lost. */ if (ret) cancel_dirty_page(page, PAGE_CACHE_SIZE); spin_unlock(&mapping->private_lock); out: if (buffers_to_free) { struct buffer_head *bh = buffers_to_free; do { struct buffer_head *next = bh->b_this_page; free_buffer_head(bh); bh = next; } while (bh != buffers_to_free); } return ret; } EXPORT_SYMBOL(try_to_free_buffers); void block_sync_page(struct page *page) { struct address_space *mapping; smp_mb(); mapping = page_mapping(page); if (mapping) blk_run_backing_dev(mapping->backing_dev_info, page); } /* * There are no bdflush tunables left. But distributions are * still running obsolete flush daemons, so we terminate them here. * * Use of bdflush() is deprecated and will be removed in a future kernel. * The `pdflush' kernel threads fully replace bdflush daemons and this call. */ SYSCALL_DEFINE2(bdflush, int, func, long, data) { static int msg_count; if (!capable(CAP_SYS_ADMIN)) return -EPERM; if (msg_count < 5) { msg_count++; printk(KERN_INFO "warning: process `%s' used the obsolete bdflush" " system call\n", current->comm); printk(KERN_INFO "Fix your initscripts?\n"); } if (func == 1) do_exit(0); return 0; } /* * Buffer-head allocation */ static struct kmem_cache *bh_cachep; /* * Once the number of bh's in the machine exceeds this level, we start * stripping them in writeback. */ static int max_buffer_heads; int buffer_heads_over_limit; struct bh_accounting { int nr; /* Number of live bh's */ int ratelimit; /* Limit cacheline bouncing */ }; static DEFINE_PER_CPU(struct bh_accounting, bh_accounting) = {0, 0}; static void recalc_bh_state(void) { int i; int tot = 0; if (__get_cpu_var(bh_accounting).ratelimit++ < 4096) return; __get_cpu_var(bh_accounting).ratelimit = 0; for_each_online_cpu(i) tot += per_cpu(bh_accounting, i).nr; buffer_heads_over_limit = (tot > max_buffer_heads); } struct buffer_head *alloc_buffer_head(gfp_t gfp_flags) { struct buffer_head *ret = kmem_cache_alloc(bh_cachep, gfp_flags); if (ret) { INIT_LIST_HEAD(&ret->b_assoc_buffers); get_cpu_var(bh_accounting).nr++; recalc_bh_state(); put_cpu_var(bh_accounting); } return ret; } EXPORT_SYMBOL(alloc_buffer_head); void free_buffer_head(struct buffer_head *bh) { BUG_ON(!list_empty(&bh->b_assoc_buffers)); kmem_cache_free(bh_cachep, bh); get_cpu_var(bh_accounting).nr--; recalc_bh_state(); put_cpu_var(bh_accounting); } EXPORT_SYMBOL(free_buffer_head); static void buffer_exit_cpu(int cpu) { int i; struct bh_lru *b = &per_cpu(bh_lrus, cpu); for (i = 0; i < BH_LRU_SIZE; i++) { brelse(b->bhs[i]); b->bhs[i] = NULL; } get_cpu_var(bh_accounting).nr += per_cpu(bh_accounting, cpu).nr; per_cpu(bh_accounting, cpu).nr = 0; put_cpu_var(bh_accounting); } static int buffer_cpu_notify(struct notifier_block *self, unsigned long action, void *hcpu) { if (action == CPU_DEAD || action == CPU_DEAD_FROZEN) buffer_exit_cpu((unsigned long)hcpu); return NOTIFY_OK; } /** * bh_uptodate_or_lock - Test whether the buffer is uptodate * @bh: struct buffer_head * * Return true if the buffer is up-to-date and false, * with the buffer locked, if not. */ int bh_uptodate_or_lock(struct buffer_head *bh) { if (!buffer_uptodate(bh)) { lock_buffer(bh); if (!buffer_uptodate(bh)) return 0; unlock_buffer(bh); } return 1; } EXPORT_SYMBOL(bh_uptodate_or_lock); /** * bh_submit_read - Submit a locked buffer for reading * @bh: struct buffer_head * * Returns zero on success and -EIO on error. */ int bh_submit_read(struct buffer_head *bh) { BUG_ON(!buffer_locked(bh)); if (buffer_uptodate(bh)) { unlock_buffer(bh); return 0; } get_bh(bh); bh->b_end_io = end_buffer_read_sync; submit_bh(READ, bh); wait_on_buffer(bh); if (buffer_uptodate(bh)) return 0; return -EIO; } EXPORT_SYMBOL(bh_submit_read); static void init_buffer_head(void *data) { struct buffer_head *bh = data; memset(bh, 0, sizeof(*bh)); INIT_LIST_HEAD(&bh->b_assoc_buffers); } void __init buffer_init(void) { int nrpages; bh_cachep = kmem_cache_create("buffer_head", sizeof(struct buffer_head), 0, (SLAB_RECLAIM_ACCOUNT|SLAB_PANIC| SLAB_MEM_SPREAD), init_buffer_head); /* * Limit the bh occupancy to 10% of ZONE_NORMAL */ nrpages = (nr_free_buffer_pages() * 10) / 100; max_buffer_heads = nrpages * (PAGE_SIZE / sizeof(struct buffer_head)); hotcpu_notifier(buffer_cpu_notify, 0); } EXPORT_SYMBOL(__bforget); EXPORT_SYMBOL(__brelse); EXPORT_SYMBOL(__wait_on_buffer); EXPORT_SYMBOL(block_commit_write); EXPORT_SYMBOL(block_prepare_write); EXPORT_SYMBOL(block_page_mkwrite); EXPORT_SYMBOL(block_read_full_page); EXPORT_SYMBOL(block_sync_page); EXPORT_SYMBOL(block_truncate_page); EXPORT_SYMBOL(block_write_full_page); EXPORT_SYMBOL(cont_write_begin); EXPORT_SYMBOL(end_buffer_read_sync); EXPORT_SYMBOL(end_buffer_write_sync); EXPORT_SYMBOL(file_fsync); EXPORT_SYMBOL(fsync_bdev); EXPORT_SYMBOL(generic_block_bmap); EXPORT_SYMBOL(generic_cont_expand_simple); EXPORT_SYMBOL(init_buffer); EXPORT_SYMBOL(invalidate_bdev); EXPORT_SYMBOL(ll_rw_block); EXPORT_SYMBOL(mark_buffer_dirty); EXPORT_SYMBOL(submit_bh); EXPORT_SYMBOL(sync_dirty_buffer); EXPORT_SYMBOL(unlock_buffer); --=-UIf3LxEbYx4KmvZuWDGh-- From agruen@suse.de Sun Feb 8 17:01:43 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.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 n18N1gfc200325 for ; Sun, 8 Feb 2009 17:01:43 -0600 X-ASG-Debug-ID: 1234134063-145903aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 143D918F00AC for ; Sun, 8 Feb 2009 15:01:03 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id RJadhAz8DWqmNRww for ; Sun, 08 Feb 2009 15:01:03 -0800 (PST) Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id B1A99473B2; Mon, 9 Feb 2009 00:00:30 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: Brandon Philips X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Date: Sun, 8 Feb 2009 23:59:59 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-4-pae; KDE/4.1.3; i686; ; ) Cc: Christoph Hellwig , xfs@oss.sgi.com References: <20090108021947.404730068@ifup.org> <20090108165820.GA3832@jenkins> <20090207091033.GO29636@jenkins.ifup.org> In-Reply-To: <20090207091033.GO29636@jenkins.ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090000.00162.agruen@suse.de> X-Barracuda-Connect: mx2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1234134065 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0808 1.0000 -1.5090 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.51 X-Barracuda-Spam-Status: No, SCORE=-1.51 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.17369 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 Saturday 07 February 2009 10:10:33 Brandon Philips wrote: > On 08:58 Thu 08 Jan 2009, Brandon Philips wrote: > > On 10:44 Thu 08 Jan 2009, Christoph Hellwig wrote: > > > On Wed, Jan 07, 2009 at 06:19:47PM -0800, brandon@ifup.org wrote: > > > > NOTE: Timothy Shimmin's email (tes@sgi.com) seems to be gone. Who > > > > should I send patches like this to in the future? > > > > > > That's not quite sorted out. For now send them to Andreas Gruenbacher > > > and the xfs list. > > > > Ok, thanks. > > > > Andreas, please review these patches if you can: > > http://oss.sgi.com/archives/xfs/2009-01/msg00136.html > > http://oss.sgi.com/archives/xfs/2009-01/msg00146.html > > I noticed that Christoph put acl-dev.git and attr-dev.git on > git.kernel.org. Great news! Yes, and the trees have nice histories as well, which is great. > But, can I suggest that we merge the attr-dev and acl-dev tree into one > git repo and share libmisc? I have done it over here: > > http://ifup.org/git/?p=acl-attr-dev.git;a=summary > git clone git://ifup.org/philips/acl-attr-dev.git > > What do you think? I believe it's a good start; we probably want to merge the trees eventually. The way how you have moved libmisc breaks the tarballs though; I have fixed it. Also, I was surprised that your repository has all the history rewritten instead of merging Christoph's trees, so I redid the merge. http://www.kernel.org/pub/scm/linux/kernel/git/agruen/xattr-tools.git git://git.kernel.org/pub/scm/linux/kernel/git/agruen/xattr-tools.git Are you fine with this tree? > Also, my test/ patchset hasn't gotten any feedback. I will merge them > into either {acl,attr}-dev.git or my acl-attr-dev.git if they seem > acceptable and send you a pull request. > > http://oss.sgi.com/pipermail/xfs/2009-January/039600.html > http://oss.sgi.com/pipermail/xfs/2009-January/039610.html Sorry for being slow. I will first add the other acked distro patches, then look at your changes. Andreas From alessandro.bono@gmail.com Sun Feb 8 17:25:06 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,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 n18NP5EW201482 for ; Sun, 8 Feb 2009 17:25:05 -0600 X-ASG-Debug-ID: 1234135467-61b300560000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f168.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4A99318EF01F for ; Sun, 8 Feb 2009 15:24:27 -0800 (PST) Received: from mail-bw0-f168.google.com (mail-bw0-f168.google.com [209.85.218.168]) by cuda.sgi.com with ESMTP id TfVnqYFeryCC9CaL for ; Sun, 08 Feb 2009 15:24:27 -0800 (PST) Received: by bwz12 with SMTP id 12so861267bwz.20 for ; Sun, 08 Feb 2009 15:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=X5ME6ZOcRmhoyh18i3Q2gs+z6kwxvj8ip14sgjdueFc=; b=ulLjCUaeL78d2mmh0ZDkbFCxz8NTBwNrkNTq0825HEZUfi7V4G3+vH/iFTuW+ochWS 2ygBNvs+LaIc9Mb40ES1zN1KtCBmCYTlSG7nEWE7LkQu7RX69tzL6PXKYgtX5+Epuloy t7GznPxZPhhhU0wZNbJ5BnvEF18rzTbPgkDqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=dUv8kIUtFvSdZZfsBg29mLKn1fvhWDENMIo3y/SHta2fMdrw2E07CFH2H1rRT8M49l geF2YywMRgAPnnAKy+FAbXXyfzYc3+IPg1jngSRsPD5T1szTrYb7PxC780UYDuKRWIcj g2LDlWP3XBem4vq4HUP+w0AO0a6Y/KWXFKR4M= Received: by 10.103.172.7 with SMTP id z7mr1832508muo.15.1234135466519; Sun, 08 Feb 2009 15:24:26 -0800 (PST) Received: from ?10.151.1.19? (host-62-10-44-87.cust-adsl.tiscali.it [62.10.44.87]) by mx.google.com with ESMTPS id e9sm1181650muf.38.2009.02.08.15.24.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 15:24:25 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Dave Chinner Cc: linux-kernel , linux-xfs In-Reply-To: <20090208221625.GB8830@disturbed> References: <1234011974.7435.11.camel@champagne.cantina> <20090208221625.GB8830@disturbed> Content-Type: text/plain Date: Mon, 09 Feb 2009 00:24:23 +0100 Message-Id: <1234135463.12370.47.camel@champagne.cantina> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-bw0-f168.google.com[209.85.218.168] X-Barracuda-Start-Time: 1234135468 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.17369 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, 2009-02-09 at 09:16 +1100, Dave Chinner wrote: > On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: > > Hi all > > > > This time I hit kernel bug without any particular operation, normal > > browsing, mail, news, etc > > tell me if you need info asap because I want to reformat this machine > > and switch back to ext3. > > > > xfs seems really unstable in this particular > > machine and after this crash I lose again configuration file of opened > > program at crash time > > That's not XFS's fault - that's a broken application that does not > safely overwrite files and hence you lose data on crash. In the past I lose configuration files from kde, gconf based programs (gnome), pan, firefox, etc maybe xfs expose more this problem > > > Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut > > here ]------------ > > Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at > > fs/buffer.c:470! > > I can't remember seeing that problem before. > > > Call Trace: > > [] ? need_resched+0x1e/0x28 > > [] ? __up_write+0x12/0x45 > > [] ? xfs_destroy_ioend+0x23/0x71 [xfs] > > [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] > > [] ? run_workqueue+0x79/0xfe > > [] ? worker_thread+0xf0/0x102 > > [] ? autoremove_wake_function+0x0/0x2e > > [] ? worker_thread+0x0/0x102 > > [] ? kthread+0x47/0x73 > > [] ? schedule_tail+0x27/0x60 > > [] ? child_rip+0xa/0x11 > > [] ? kthread+0x0/0x73 > > [] ? child_rip+0x0/0x11 > > Standard delayed allocation IO completion trace. No idea what > could have caused it. Perhaps a memory error? I'm starting to think the same thing If needed I can replace memory dimm, this is my principal notebook and I need it to work > > Can you send the output of xfs_info on that filesystem, and > perhaps run an xfs_repair -n on it to see if there are any > undetected errors on disk? root@champagne:/home/sandro# xfs_info / meta-data=/dev/mapper/vol00-root isize=256 agcount=17, agsize=1600000 blks = sectsz=512 attr=1 data = bsize=4096 blocks=26781696, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12500, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 root fs on lvm on dm_crypt to run xfs_repair I have to boot from a live distribution that support this stack, I need some time > > Also, I note that you are using ext4 on some disks. Does this > problem show up if you don't use ext4 at all? (We have had problems > in the past with one filesystem not leaving bufferheads in the > correct state and the system crashing when a different type of > filesystem got them reallocated). First time of this bug, not sure if it's ext4 related Ext4 disk is my personal mirror of data taken from my server, I can reformat ext4 disk to xfs Ironically I started test ext4 to replace xfs on this machine :-( thanks > > Cheers, > > Dave. -- --- Cordiali Saluti Alessandro Bono From brandon@ifup.org Sun Feb 8 17:39: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.4 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 n18Ndcna202464 for ; Sun, 8 Feb 2009 17:39:39 -0600 X-ASG-Debug-ID: 1234136339-61b200b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 00A4F18F1D58 for ; Sun, 8 Feb 2009 15:38:59 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by cuda.sgi.com with ESMTP id qW81t6C38BYayjEb for ; Sun, 08 Feb 2009 15:38:59 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so910841waf.4 for ; Sun, 08 Feb 2009 15:38:58 -0800 (PST) Received: by 10.114.147.1 with SMTP id u1mr3097649wad.115.1234136338680; Sun, 08 Feb 2009 15:38:58 -0800 (PST) Received: from localhost (c-76-105-255-252.hsd1.or.comcast.net [76.105.255.252]) by mx.google.com with ESMTPS id m27sm9182286pof.13.2009.02.08.15.38.57 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 15:38:58 -0800 (PST) Date: Sun, 8 Feb 2009 15:38:37 -0800 From: Brandon Philips To: Andreas Gruenbacher Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Message-ID: <20090208233837.GA446@jenkins.ifup.org> References: <20090108021947.404730068@ifup.org> <20090108165820.GA3832@jenkins> <20090207091033.GO29636@jenkins.ifup.org> <200902090000.00162.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200902090000.00162.agruen@suse.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.177] X-Barracuda-Start-Time: 1234136340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0076 1.0000 -1.9711 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.17369 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 23:59 Sun 08 Feb 2009, Andreas Grünbacher wrote: > On Saturday 07 February 2009 10:10:33 Brandon Philips wrote: > I believe it's a good start; we probably want to merge the trees eventually. > The way how you have moved libmisc breaks the tarballs though; I have fixed > it. Thanks. But, what do you mean by break the tarballs? > Also, I was surprised that your repository has all the history > rewritten instead of merging Christoph's trees, so I redid the merge. I used git-stitch-repo[1] to rewrite the history as if they had been in the same tree. This has the advantage that you can go: `git log acl/setfacl/setfacl.c` and have the whole history. Either way is fine with me though. [1] http://ifup.org/2009/02/07/the-right-tool-for-the-job-git-stitch-repo > http://www.kernel.org/pub/scm/linux/kernel/git/agruen/xattr-tools.git > git://git.kernel.org/pub/scm/linux/kernel/git/agruen/xattr-tools.git > > Are you fine with this tree? They look good to me. > Sorry for being slow. I will first add the other acked distro patches, then > look at your changes. Great. Can we set a precedent that as patches get merged an email gets sent to xfs@oss.sgi.com still? If not I will just rss2email the git tree. Thanks, Brandon From markgw@sgi.com Sun Feb 8 18:28: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.4 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 n190S9JJ205664 for ; Sun, 8 Feb 2009 18:28:10 -0600 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay3.corp.sgi.com (Postfix) with SMTP id 84912AC026; Sun, 8 Feb 2009 16:27:26 -0800 (PST) Received: from [134.14.52.241] ([134.14.52.241]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25645; Mon, 9 Feb 2009 11:27:22 +1100 Message-ID: <498F7861.6010109@sgi.com> Date: Mon, 09 Feb 2009 11:27:13 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Russell Cattelan CC: Christoph Hellwig , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Gary Hagensen , George Beshers , John Hesterberg , xfs-oss , xfs-dev , Tony Ernst , Ric Wheeler 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> <20090205112906.GB11781@infradead.org> <498D8F18.3080903@thebarn.com> In-Reply-To: <498D8F18.3080903@thebarn.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 Russell Cattelan wrote: > Christoph Hellwig wrote: > ... >>> 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 > > or maybe we should just update the existing xfs-website tree? > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=cattelan/xfs-website/.git;a=summary Rus, I didn't know that tree existed - it now has incorrect copyright notices for the doc sources. However, since it's ahead of ptools (and has cvs imported history too), I'll clone it as a replacement and then merge in the training docs with updated copyrights. It's easier for SGI if the official tree is git://oss.sgi.com/xfs/cmds/xfsdocs.git since the directory structure mirrors the internal ptools hierarchy, along with the other xfs/cmds trees. >> 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? >> > I moved cvsimported xfs-import dmapi-import and xfs-cmds under archive. Thanks for that. Cheers -- Mark From agruen@suse.de Sun Feb 8 18:32:14 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.3 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 n190WDcF205950 for ; Sun, 8 Feb 2009 18:32:14 -0600 X-ASG-Debug-ID: 1234139495-5dce02250000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 57B4218F1ADE for ; Sun, 8 Feb 2009 16:31:36 -0800 (PST) Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id pnvgtdy1zmyuYtFu for ; Sun, 08 Feb 2009 16:31:36 -0800 (PST) Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 1B09C466CB; Mon, 9 Feb 2009 01:31:35 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: Brandon Philips X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Date: Mon, 9 Feb 2009 01:31:32 +0100 User-Agent: KMail/1.9.9 Cc: Christoph Hellwig , xfs@oss.sgi.com References: <20090108021947.404730068@ifup.org> <200902090000.00162.agruen@suse.de> <20090208233837.GA446@jenkins.ifup.org> In-Reply-To: <20090208233837.GA446@jenkins.ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902090131.33240.agruen@suse.de> X-Barracuda-Connect: ns2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1234139496 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.17370 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 Monday, 9 February 2009 0:38:37 Brandon Philips wrote: > On 23:59 Sun 08 Feb 2009, Andreas Gr=FCnbacher wrote: > > On Saturday 07 February 2009 10:10:33 Brandon Philips wrote: > > I believe it's a good start; we probably want to merge the trees > > eventually. The way how you have moved libmisc breaks the tarballs > > though; I have fixed it. > > Thanks. But, what do you mean by break the tarballs? Here's what I got after ./Makepkgs: $ tar tfz build/attr-2.4.43.src.tar.gz attr-2.4.43/... libmisc/... attr-2.4.43/... > > Sorry for being slow. I will first add the other acked distro patches, > > then look at your changes. > > Great. Can we set a precedent that as patches get merged an email gets > sent to xfs@oss.sgi.com still? If not I will just rss2email the git > tree. I haven't managed to set that up, yet. Andreas From cattelan@thebarn.com Sun Feb 8 18:53: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.4 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 n190rq6u207133 for ; Sun, 8 Feb 2009 18:53:53 -0600 X-ASG-Debug-ID: 1234140787-342a001e0002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from slurp.thebarn.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 816E418F1E7B for ; Sun, 8 Feb 2009 16:53:14 -0800 (PST) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by cuda.sgi.com with ESMTP id vspFGVSOAM59r7gN for ; Sun, 08 Feb 2009 16:53:14 -0800 (PST) Received: from funky.thebarn.com (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.3/8.14.0) with ESMTP id n190rdrZ030592; Sun, 8 Feb 2009 18:53:40 -0600 (CST) (envelope-from cattelan@xfs.org) Message-ID: <498F7E71.8040600@xfs.org> Date: Sun, 08 Feb 2009 18:53:05 -0600 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: markgw@sgi.com CC: Russell Cattelan , Christoph Hellwig , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Gary Hagensen , George Beshers , John Hesterberg , xfs-oss , xfs-dev , Tony Ernst , Ric Wheeler 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> <20090205112906.GB11781@infradead.org> <498D8F18.3080903@thebarn.com> <498F7861.6010109@sgi.com> In-Reply-To: <498F7861.6010109@sgi.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/8835/Sun Jan 4 21:47:36 2009 on slurp.thebarn.com X-Virus-Status: Clean X-Barracuda-Connect: cattelan-host202.dsl.visi.com[208.42.117.202] X-Barracuda-Start-Time: 1234140795 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3353 1.0000 -0.2064 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.21 X-Barracuda-Spam-Status: No, SCORE=-0.21 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.17371 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Mark Goodwin wrote: > > > Russell Cattelan wrote: >> Christoph Hellwig wrote: >> ... >>>> 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 >> >> or maybe we should just update the existing xfs-website tree? >> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=cattelan/xfs-website/.git;a=summary >> > > Rus, I didn't know that tree existed - it now has incorrect copyright > notices for the doc sources. However, since it's ahead of ptools > (and has cvs imported history too), I'll clone it as a replacement > and then merge in the training docs with updated copyrights. It's easier > for SGI if the official tree is git://oss.sgi.com/xfs/cmds/xfsdocs.git > since the directory structure mirrors the internal ptools hierarchy, > along with the other xfs/cmds trees. That's cool, I'll change the web site to point to the new repo once you have it fixed up. Just trying to keep the clutter down. > >>> 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? >>> >> I moved cvsimported xfs-import dmapi-import and xfs-cmds under archive. > > Thanks for that. > > Cheers > -- Mark > From agruen@suse.de Sun Feb 8 19:30:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.1 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 n191UYZW208995 for ; Sun, 8 Feb 2009 19:30:35 -0600 X-ASG-Debug-ID: 1234142994-5d5902f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E6D1318F15C6 for ; Sun, 8 Feb 2009 17:29:54 -0800 (PST) Received: from mx2.suse.de (ns2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id L9SAsXCT0F7hyeEj for ; Sun, 08 Feb 2009 17:29:54 -0800 (PST) Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 225D5466CB; Mon, 9 Feb 2009 02:29:54 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 2/5] [PATCH] acl: various improvements for test/run Subject: Re: [patch 2/5] [PATCH] acl: various improvements for test/run Date: Mon, 9 Feb 2009 02:29:47 +0100 User-Agent: KMail/1.9.9 Cc: brandon@ifup.org, tes@sgi.com, Brandon Philips References: <20090108015355.613058570@ifup.org> <20090108015418.699729152@ifup.org> In-Reply-To: <20090108015418.699729152@ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090229.47550.agruen@suse.de> X-Barracuda-Connect: ns2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1234142995 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.17372 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 Brandon, the version of the run script in the attr and acl packages is somewhat dated; I have made a few improvements since. I'll move this out of {acl,attr}/test and put the latest version into the libmisc/ directory. Note that I recently rewrote the run script from scratch. Unlike the old version, the new one runs the whole script inside the same shell. There are still a few problems to be solved; most importantly, user switching doesn't work, yet. Eventually I want to replace the old version, though. http://savannah.nongnu.org/projects/shrun On Thursday, 8 January 2009 2:53:57 brandon@ifup.org wrote: > First move process_test to avoid a warning: > > main::process_test() called too early to check prototype at ./run line 47. > main::process_test() called too early to check prototype at ./run line 60. The new version had this fixed already. > Create two ENV variables TUSER and TGROUP to get the user/group > running the test. Good idea. Added. (Stuff like this will be obsolete with shrun.) > Add a | test line that is similar to > but is interpreted as a regular > expression. I have been using ">~" instead of "|" for that. I'm still not sure that including regular expression matching was a good idea though, so shrun doesn't have any of that yet. We'll se how things develop. Thanks, Andreas From agruen@suse.de Sun Feb 8 19:36:12 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.0 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 n191aBqJ209351 for ; Sun, 8 Feb 2009 19:36:12 -0600 X-ASG-Debug-ID: 1234143334-5d5903030000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0D40B18F1EF0 for ; Sun, 8 Feb 2009 17:35:34 -0800 (PST) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id EVe2xIhG0jAlTKge for ; Sun, 08 Feb 2009 17:35:34 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 25B6F446AE; Mon, 9 Feb 2009 02:35:02 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 1/5] [PATCH] acl: add make test target and use make to run tests Subject: Re: [patch 1/5] [PATCH] acl: add make test target and use make to run tests Date: Mon, 9 Feb 2009 02:34:55 +0100 User-Agent: KMail/1.9.9 Cc: brandon@ifup.org, tes@sgi.com, Brandon Philips References: <20090108015355.613058570@ifup.org> <20090108015418.504806823@ifup.org> In-Reply-To: <20090108015418.504806823@ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090234.55384.agruen@suse.de> X-Barracuda-Connect: ns1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1234143335 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 Thursday, 8 January 2009 2:53:56 brandon@ifup.org wrote: > The tests are difficult to run. So, this patch adds a Make target that > sets up the path and runs *.test files in the test/ directory. Makes sense in principle, except that the patch removes the makefile rules that cause the tests to get added to the tarball :-( Would you mind to fix that? Thanks, Andreas From agruen@suse.de Sun Feb 8 19:41:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24 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 n191fGwI209640 for ; Sun, 8 Feb 2009 19:41:16 -0600 X-ASG-Debug-ID: 1234143638-343500c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6CAD818F1F23 for ; Sun, 8 Feb 2009 17:40:39 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id D43tnsfiHEvCuio1 for ; Sun, 08 Feb 2009 17:40:39 -0800 (PST) Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 51998473B2; Mon, 9 Feb 2009 02:40:06 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 5/5] [PATCH] acl: minor fix to cp.test Subject: Re: [patch 5/5] [PATCH] acl: minor fix to cp.test Date: Mon, 9 Feb 2009 02:40:04 +0100 User-Agent: KMail/1.9.9 Cc: brandon@ifup.org, tes@sgi.com, Brandon Philips References: <20090108015355.613058570@ifup.org> <20090108015419.298358378@ifup.org> In-Reply-To: <20090108015419.298358378@ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090240.04861.agruen@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1234143639 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.17372 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 Thursday, 8 January 2009 2:54:00 brandon@ifup.org wrote: > X -> x Added, thanks. From agruen@suse.de Sun Feb 8 19:52:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 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 n191qYWE210335 for ; Sun, 8 Feb 2009 19:52:35 -0600 X-ASG-Debug-ID: 1234144317-623302d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E3AE118F20DC for ; Sun, 8 Feb 2009 17:51:57 -0800 (PST) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id O9XhhVheTNrnrGCA for ; Sun, 08 Feb 2009 17:51:57 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id BB212446AE; Mon, 9 Feb 2009 02:51:56 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 4/5] [PATCH] acl: move nfs tests to their own folder Subject: Re: [patch 4/5] [PATCH] acl: move nfs tests to their own folder Date: Mon, 9 Feb 2009 02:51:54 +0100 User-Agent: KMail/1.9.9 Cc: brandon@ifup.org, tes@sgi.com, Brandon Philips References: <20090108015355.613058570@ifup.org> <20090108015419.101811540@ifup.org> In-Reply-To: <20090108015419.101811540@ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090251.55264.agruen@suse.de> X-Barracuda-Connect: ns1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1234144317 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 Thursday, 8 January 2009 2:53:59 brandon@ifup.org wrote: > Since these tests require nfs mounts to run move them into a seperate > folder so they don't run by default. Added. Andreas From agruen@suse.de Sun Feb 8 19:53:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.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 n191rMQu210401 for ; Sun, 8 Feb 2009 19:53:22 -0600 X-ASG-Debug-ID: 1234144364-599903930000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 415B418F20F4 for ; Sun, 8 Feb 2009 17:52:44 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id L1NloOmUm8kTcXC3 for ; Sun, 08 Feb 2009 17:52:44 -0800 (PST) Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9B5FF47794; Mon, 9 Feb 2009 02:52:12 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs / Novell To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 3/5] [PATCH] acl: move root tests to their own folder Subject: Re: [patch 3/5] [PATCH] acl: move root tests to their own folder Date: Mon, 9 Feb 2009 02:52:11 +0100 User-Agent: KMail/1.9.9 Cc: brandon@ifup.org, tes@sgi.com, Brandon Philips References: <20090108015355.613058570@ifup.org> <20090108015418.899764003@ifup.org> In-Reply-To: <20090108015418.899764003@ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902090252.11554.agruen@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1234144365 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.17372 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 Thursday, 8 January 2009 2:53:58 brandon@ifup.org wrote: > Since these tests require root perms to run move them into a seperate > folder so they don't run by default. Added. Andreas From david@fromorbit.com Sun Feb 8 20:12:19 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 n192CIOq211248 for ; Sun, 8 Feb 2009 20:12:19 -0600 X-ASG-Debug-ID: 1234145499-4d6a03dd0000-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 BBA6BFC61B for ; Sun, 8 Feb 2009 18:11:39 -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 M7QDjArFTxgM7tnB for ; Sun, 08 Feb 2009 18:11:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEAGYdj0l5LClx/2dsb2JhbACVQLdDhBoG X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286038544" 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; 09 Feb 2009 12:41:37 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWLcW-0002Cc-Bi; Mon, 09 Feb 2009 13:11:36 +1100 Date: Mon, 9 Feb 2009 13:11:36 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_db: fix wrong sibling pointers offset for the bmbt attr block Subject: Re: xfs_db: fix wrong sibling pointers offset for the bmbt attr block Message-ID: <20090209021136.GC8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090208211515.GB22118@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090208211515.GB22118@infradead.org> 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: 1234145501 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.17372 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 08, 2009 at 04:15:15PM -0500, Christoph Hellwig wrote: > The attr bmbt should use long, not short pointers. > > > Signed-off-by: Christoph Hellwig > > Index: xfsprogs-dev/db/btblock.c > =================================================================== > --- xfsprogs-dev.orig/db/btblock.c 2009-02-08 22:13:05.225944103 +0100 > +++ xfsprogs-dev/db/btblock.c 2009-02-08 22:13:14.143944165 +0100 > @@ -227,8 +227,8 @@ const field_t bmapbtd_flds[] = { > { "magic", FLDT_UINT32X, OI(OFF(magic)), C1, 0, TYP_NONE }, > { "level", FLDT_UINT16D, OI(OFF(level)), C1, 0, TYP_NONE }, > { "numrecs", FLDT_UINT16D, OI(OFF(numrecs)), C1, 0, TYP_NONE }, > - { "leftsib", FLDT_DFSBNO, OI(OFF(u.s.bb_leftsib)), C1, 0, TYP_BMAPBTD }, > - { "rightsib", FLDT_DFSBNO, OI(OFF(u.s.bb_rightsib)), C1, 0, TYP_BMAPBTD }, > + { "leftsib", FLDT_DFSBNO, OI(OFF(u.l.bb_leftsib)), C1, 0, TYP_BMAPBTD }, > + { "rightsib", FLDT_DFSBNO, OI(OFF(u.l.bb_rightsib)), C1, 0, TYP_BMAPBTD }, > { "recs", FLDT_BMAPBTDREC, btblock_rec_offset, btblock_rec_count, > FLD_ARRAY|FLD_ABASE1|FLD_COUNT|FLD_OFFSET, TYP_NONE }, > { "keys", FLDT_BMAPBTDKEY, btblock_key_offset, btblock_key_count, Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:16: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 n192GLID211722 for ; Sun, 8 Feb 2009 20:16:22 -0600 X-ASG-Debug-ID: 1234145743-342f01310000-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 B8AFE18F1C4D for ; Sun, 8 Feb 2009 18:15:43 -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 wFylpuRcEFbWZ0lQ for ; Sun, 08 Feb 2009 18:15:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACkhj0l5LClx/2dsb2JhbADMfYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286041164" 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; 09 Feb 2009 12:45:23 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWLg9-0002IJ-VB; Mon, 09 Feb 2009 13:15:21 +1100 Date: Mon, 9 Feb 2009 13:15:21 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 06/17] xfs: remove iclog calculation special cases Subject: Re: [PATCH 06/17] xfs: remove iclog calculation special cases Message-ID: <20090209021521.GD8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073201.333455000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073201.333455000@bombadil.infradead.org> 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: 1234145744 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.17372 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, Jan 26, 2009 at 02:31:42AM -0500, Christoph Hellwig wrote: > Our default has been to always use 8 32KB log buffers for a while now, so > remove the special casing for larger block size filesystem to use the same > or even lower number of buffers. > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:17: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 (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id n192HNIW211861 for ; Sun, 8 Feb 2009 20:17:24 -0600 X-ASG-Debug-ID: 1234145805-49cf00100000-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 0B614FC62A for ; Sun, 8 Feb 2009 18:16:46 -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 hQaMlQ8nlnvJh59c for ; Sun, 08 Feb 2009 18:16:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACkhj0l5LClx/2dsb2JhbADMfYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286041987" 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; 09 Feb 2009 12:46:44 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWLhU-0002K6-9r; Mon, 09 Feb 2009 13:16:44 +1100 Date: Mon, 9 Feb 2009 13:16:44 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 07/17] xfs: remove superflous inobt macros Subject: Re: [PATCH 07/17] xfs: remove superflous inobt macros Message-ID: <20090209021644.GE8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073201.697358000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073201.697358000@bombadil.infradead.org> 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: 1234145807 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.17372 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, Jan 26, 2009 at 02:31:43AM -0500, Christoph Hellwig wrote: > xfs_ialloc_btree.h has a a cuple of macros that only obsfucate the code > but don't provide any abstraction benefits. This patches removes those > and cleans up the reamaining defintions up a little. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:18:50 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 n192Ionl212087 for ; Sun, 8 Feb 2009 20:18:50 -0600 X-ASG-Debug-ID: 1234145892-49c6002a0000-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 589D8FC634 for ; Sun, 8 Feb 2009 18:18:12 -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 pbykmjCuu4aLS2Cg for ; Sun, 08 Feb 2009 18:18:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACkhj0l5LClx/2dsb2JhbADMfYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286042972" 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; 09 Feb 2009 12:48:11 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWLit-0002M0-0s; Mon, 09 Feb 2009 13:18:11 +1100 Date: Mon, 9 Feb 2009 13:18:10 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/17] xfs: remove uchar_t/ushort_t/uint_t/ulong_t types Subject: Re: [PATCH 08/17] xfs: remove uchar_t/ushort_t/uint_t/ulong_t types Message-ID: <20090209021810.GF8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073201.963253000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073201.963253000@bombadil.infradead.org> 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: 1234145893 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.17372 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, Jan 26, 2009 at 02:31:44AM -0500, Christoph Hellwig wrote: > Just another set of types obsfucating the code, remove them. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:41: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.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 n192ftfE213143 for ; Sun, 8 Feb 2009 20:41:55 -0600 X-ASG-Debug-ID: 1234147277-49d100e40000-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 9C05DFC6A7 for ; Sun, 8 Feb 2009 18:41:17 -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 nVu5RwmfgwApBHz9 for ; Sun, 08 Feb 2009 18:41:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKokj0l5LClx/2dsb2JhbADMd4QaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286064102" 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; 09 Feb 2009 13:11:16 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWM5D-0002s3-6c; Mon, 09 Feb 2009 13:41:15 +1100 Date: Mon, 9 Feb 2009 13:41:15 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 13/17] xfs: get rid of indirections in the quotaops implementation Subject: Re: [PATCH 13/17] xfs: get rid of indirections in the quotaops implementation Message-ID: <20090209024115.GH8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.961302000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073202.961302000@bombadil.infradead.org> 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: 1234147278 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.17372 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, Jan 26, 2009 at 02:31:49AM -0500, Christoph Hellwig wrote: > Currently we call from the nicely abstracted linux quotaops into a ugly > multiplexer just to split the calls out at the same boundary again. > Rewrite the quota ops handling to remove that obfucation. > > > Signed-off-by: Christoph Hellwig ..... > +STATIC int > +xfs_fs_get_xstate( > + struct super_block *sb, > + struct fs_quota_stat *fqs) > +{ > + struct xfs_mount *mp = XFS_M(sb); > + > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return -ENOSYS; > + return xfs_qm_scall_getqstat(mp, fqs); The return of xfs_qm_scall_getqstat() needs to be negated. > +STATIC int > +xfs_fs_set_xquota( > + struct super_block *sb, > + int type, > + qid_t id, > + struct fs_disk_quota *fdq) > +{ > + struct xfs_mount *mp = XFS_M(sb); > + > + if (sb->s_flags & MS_RDONLY) > + return -EROFS; > + if (!XFS_IS_QUOTA_RUNNING(mp)) > + return -ENOSYS; > + if (!XFS_IS_QUOTA_ON(mp)) > + return -ESRCH; > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + > + return xfs_qm_scall_setqlim(mp, id, xfs_quota_type(type), fdq); That should be negated as well. Other than those two little things, looks good. Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:43:25 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 n192hP6s213258 for ; Sun, 8 Feb 2009 20:43:25 -0600 X-ASG-Debug-ID: 1234147367-49c400df0000-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 6AD4EFC70C for ; Sun, 8 Feb 2009 18:42:47 -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 Y1vsZamHQDqLM3HG for ; Sun, 08 Feb 2009 18:42:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKokj0l5LClx/2dsb2JhbADMd4QaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286065161" 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; 09 Feb 2009 13:12:42 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWM6b-0002uK-As; Mon, 09 Feb 2009 13:42:41 +1100 Date: Mon, 9 Feb 2009 13:42:41 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 15/17] xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE Subject: Re: [PATCH 15/17] xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE Message-ID: <20090209024241.GI8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073203.388857000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073203.388857000@bombadil.infradead.org> 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: 1234147368 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.17372 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, Jan 26, 2009 at 02:31:51AM -0500, Christoph Hellwig wrote: > Remove these macros which only obsfucated the code in rather nast ways. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:46:50 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 n192koda213771 for ; Sun, 8 Feb 2009 20:46:50 -0600 X-ASG-Debug-ID: 1234147571-61db03ac0000-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 5A19418E596F for ; Sun, 8 Feb 2009 18:46:11 -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 Vo3AKM6XHDemcxHF for ; Sun, 08 Feb 2009 18:46:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADQoj0l5LClx/2dsb2JhbADMfYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286068248" 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; 09 Feb 2009 13:15:56 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWM9g-0002zW-6p; Mon, 09 Feb 2009 13:45:52 +1100 Date: Mon, 9 Feb 2009 13:45:52 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 17/17] xfs: sanitize qh_lock wrappers Subject: Re: [PATCH 17/17] xfs: sanitize qh_lock wrappers Message-ID: <20090209024552.GK8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073203.727645000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073203.727645000@bombadil.infradead.org> 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: 1234147573 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.17372 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, Jan 26, 2009 at 02:31:53AM -0500, Christoph Hellwig wrote: > Get rid of various obsfucating wrappers for accessing the quota hash lock, > we only keep the accessors for accessing the mplist and freelist locks as > they encode a multi-level datastructure walk. But make sure all of them > are defined in the same way as simple macros. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:47:11 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 n192lAWL213815 for ; Sun, 8 Feb 2009 20:47:10 -0600 X-ASG-Debug-ID: 1234147591-61db03b00000-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 2331618EF9F0 for ; Sun, 8 Feb 2009 18:46:32 -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 gtp6R7PO7ehwldxm for ; Sun, 08 Feb 2009 18:46:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACkhj0l5LClx/2dsb2JhbADMfYQaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286052041" 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; 09 Feb 2009 12:58:16 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWLsd-0002cL-Er; Mon, 09 Feb 2009 13:28:15 +1100 Date: Mon, 9 Feb 2009 13:28:15 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 12/17] xfs: merge xfs_mkdir into xfs_create Subject: Re: [PATCH 12/17] xfs: merge xfs_mkdir into xfs_create Message-ID: <20090209022815.GG8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.764168000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073202.764168000@bombadil.infradead.org> 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: 1234147593 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.17372 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, Jan 26, 2009 at 02:31:48AM -0500, Christoph Hellwig wrote: > xfs_create and xfs_mkdir only have minor differences, so merge both of them > into a sigle function. While we're at it also make the error handling code > more straight-forward. > > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Feb 8 20:49: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 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 n192nCGb214032 for ; Sun, 8 Feb 2009 20:49:12 -0600 X-ASG-Debug-ID: 1234147714-49c401030000-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 7FA2FFC754 for ; Sun, 8 Feb 2009 18:48:34 -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 2cYw3jYHKsdckxWW for ; Sun, 08 Feb 2009 18:48:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKokj0l5LClx/2dsb2JhbADMd4QaBg X-IronPort-AV: E=Sophos;i="4.37,401,1231075800"; d="scan'208";a="286065366" 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; 09 Feb 2009 13:12:59 +1030 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1LWM6t-0002up-JW; Mon, 09 Feb 2009 13:42:59 +1100 Date: Mon, 9 Feb 2009 13:42:59 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 16/17] xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED Subject: Re: [PATCH 16/17] xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED Message-ID: <20090209024259.GJ8830@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20090126073136.384490000@bombadil.infradead.org> <20090126073203.550396000@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090126073203.550396000@bombadil.infradead.org> 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: 1234147715 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.17372 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, Jan 26, 2009 at 02:31:52AM -0500, Christoph Hellwig wrote: > Now that we have a helper to test if a mutex is held use it instead of our > own little hacks. > > Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From sandeen@sandeen.net Sun Feb 8 21:17: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.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 n193HMkI215452 for ; Sun, 8 Feb 2009 21:17:23 -0600 X-ASG-Debug-ID: 1234149405-1d8a00490000-w1Z2WR 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 93EE518F222E for ; Sun, 8 Feb 2009 19:16:45 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id kCCdCsJZnxjCZgDN for ; Sun, 08 Feb 2009 19:16:45 -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 n192rucY014787; Sun, 8 Feb 2009 21:53:56 -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 n192rurT006546; Sun, 8 Feb 2009 21:53:56 -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 n192rtN6031019; Sun, 8 Feb 2009 21:53:56 -0500 Message-ID: <498F9AC2.2020703@sandeen.net> Date: Sun, 08 Feb 2009 20:53:54 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alessandro Bono CC: Christoph Hellwig , linux-xfs , linux-kernel X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <498F9A53.3090409@sandeen.net> In-Reply-To: <498F9A53.3090409@sandeen.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: 1234149405 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.17372 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: > Alessandro Bono wrote: .. >> sure, attached > > Well, that seems to not be from the kernel you were running; there is no > BUG() on line 470: > > $ cat -n buffer.c | grep -8 " 470" > 462 bdevname(bh->b_bdev, b)); > 463 } > 464 set_bit(AS_EIO, &page->mapping->flags); > 465 set_buffer_write_io_error(bh); > 466 clear_buffer_uptodate(bh); > 467 SetPageError(page); > 468 } > 469 > 470 first = page_buffers(page); oh, oops :) it's probably this BUG(): #define page_buffers(page) \ ({ \ BUG_ON(!PagePrivate(page)); \ -Eric From sandeen@sandeen.net Sun Feb 8 21:17: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.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 n193HN08215456 for ; Sun, 8 Feb 2009 21:17:24 -0600 X-ASG-Debug-ID: 1234149405-1d8a00490002-w1Z2WR 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 1C17118F2233 for ; Sun, 8 Feb 2009 19:16:45 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id KDNJSkMlYUb0mpPm for ; Sun, 08 Feb 2009 19:16:45 -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 n192q5Tv014639; Sun, 8 Feb 2009 21:52:07 -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 n192q5tI006403; Sun, 8 Feb 2009 21:52:06 -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 n192q48r030918; Sun, 8 Feb 2009 21:52:04 -0500 Message-ID: <498F9A53.3090409@sandeen.net> Date: Sun, 08 Feb 2009 20:52:03 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alessandro Bono CC: Christoph Hellwig , linux-xfs , linux-kernel X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> In-Reply-To: <1234133120.12370.7.camel@champagne.cantina> 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: 1234149406 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.17372 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 Alessandro Bono wrote: > On Sun, 2009-02-08 at 17:42 -0500, Christoph Hellwig wrote: >> On Sun, Feb 08, 2009 at 11:39:12PM +0100, Alessandro Bono wrote: >>> On Sun, 2009-02-08 at 17:28 -0500, Christoph Hellwig wrote: >>>> On Sat, Feb 07, 2009 at 02:06:13PM +0100, Alessandro Bono wrote: >>>>> Feb 7 12:43:12 champagne kernel: [ 5828.167041] ------------[ cut >>>>> here ]------------ >>>>> Feb 7 12:43:12 champagne kernel: [ 5828.167048] kernel BUG at >>>>> fs/buffer.c:470! >>>> Per >>>> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=blob;f=fs/buffer.c;h=665d446b25bc034241ef54c3c6b1d239c0ccf0f9;hb=d5b562330ec766292a3ac54ae5e0673610bd5b3d >>>> >>>> line 470 in fs/buffer.c of 2.6.28.4 has a comment and no actual code. >>>> >>>> What additional patches do you have applied? >>>> >>> vanilla kernel >>> no additional patches at all >> Well, the 2.6.28.4 clearly doesn't have a bug there. Can you >> attach the fs/buffer.c you built the kernel from? >> > > sure, attached Well, that seems to not be from the kernel you were running; there is no BUG() on line 470: $ cat -n buffer.c | grep -8 " 470" 462 bdevname(bh->b_bdev, b)); 463 } 464 set_bit(AS_EIO, &page->mapping->flags); 465 set_buffer_write_io_error(bh); 466 clear_buffer_uptodate(bh); 467 SetPageError(page); 468 } 469 470 first = page_buffers(page); 471 local_irq_save(flags); 472 bit_spin_lock(BH_Uptodate_Lock, &first->b_state); 473 474 clear_buffer_async_write(bh); 475 unlock_buffer(bh); 476 tmp = bh->b_this_page; 477 while (tmp != bh) { 478 if (buffer_async_write(tmp)) { From gnb@melbourne.sgi.com Sun Feb 8 22:32: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=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 n194Wlw9219288 for ; Sun, 8 Feb 2009 22:32:47 -0600 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay1.corp.sgi.com (Postfix) with SMTP id 6004D8F81DB; Sun, 8 Feb 2009 20:32:04 -0800 (PST) Received: from [134.14.52.243] ([134.14.52.243]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02524; Mon, 9 Feb 2009 15:32:02 +1100 Message-ID: <498FB128.4060008@melbourne.sgi.com> Date: Mon, 09 Feb 2009 15:29:28 +1100 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Andreas Gruenbacher CC: xfs@oss.sgi.com, tes@sgi.com, Brandon Philips , brandon@ifup.org Subject: Re: [patch 2/5] [PATCH] acl: various improvements for test/run References: <20090108015355.613058570@ifup.org> <20090108015418.699729152@ifup.org> <200902090229.47550.agruen@suse.de> In-Reply-To: <200902090229.47550.agruen@suse.de> Content-Type: text/plain; charset=ISO-8859-1 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 Andreas Gruenbacher wrote: > Brandon, > > the version of the run script in the attr and acl packages is somewhat dated; > I have made a few improvements since. I'll move this out of {acl,attr}/test > and put the latest version into the libmisc/ directory. > > Note that I recently rewrote the run script from scratch. Unlike the old > version, the new one runs the whole script inside the same shell. There are > still a few problems to be solved; most importantly, user switching doesn't > work, yet. I hope you get that feature done soon, and look forward to reviewing it. Let me just be Captain Obvious and say that user switching is a critical feature for code used to drive ACL tests ;-) > Eventually I want to replace the old version, though. > > http://savannah.nongnu.org/projects/shrun > > > > >> Add a | test line that is similar to > but is interpreted as a regular >> expression. >> > > I have been using ">~" instead of "|" for that. I'm still not sure that > including regular expression matching was a good idea though, so shrun > doesn't have any of that yet. We'll se how things develop. > > > Regexp matching is the kind of thing that sounds like it could be quite useful, but it's a pain to implement. When I wrote a Python interpreter for the shrun language for use in Newpynfs, I didn't bother implementing the regexp feature. -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. From markgw@sgi.com Mon Feb 9 01:08: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.4 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 n1978Jj0231009 for ; Mon, 9 Feb 2009 01:08:20 -0600 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by relay3.corp.sgi.com (Postfix) with SMTP id 110A5AC026; Sun, 8 Feb 2009 23:07:36 -0800 (PST) Received: from [134.14.52.241] ([134.14.52.241]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA06005; Mon, 9 Feb 2009 18:07:32 +1100 Message-ID: <498FD62D.9010604@sgi.com> Date: Mon, 09 Feb 2009 18:07:25 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Russell Cattelan CC: Christoph Hellwig , Eric Sandeen , SGI Engineering Interfaces to Red Hat , Marizol Martinez , Gary Hagensen , George Beshers , John Hesterberg , xfs-oss , xfs-dev , Tony Ernst , Ric Wheeler 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> <20090205112906.GB11781@infradead.org> <498D8F18.3080903@thebarn.com> <498F7861.6010109@sgi.com> <498F7E71.8040600@xfs.org> In-Reply-To: <498F7E71.8040600@xfs.org> 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 Russell Cattelan wrote: > Mark Goodwin wrote: >> .... I'll clone it as a replacement and then merge in the training >> docs with updated copyrights. It's easier for SGI if the official >> tree is git://oss.sgi.com/xfs/cmds/xfsdocs.git > That's cool, I'll change the web site to point to the new repo > once you have it fixed up. > Just trying to keep the clutter down. Ok, done -- Mark From SRS0+baec9931e3585034ca2c+1996+infradead.org+hch@bombadil.srs.infradead.org Mon Feb 9 01:47:11 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 n197lAkh232924 for ; Mon, 9 Feb 2009 01:47:11 -0600 X-ASG-Debug-ID: 1234165592-6e1901810000-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 CC1A4FD00A for ; Sun, 8 Feb 2009 23:46:32 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Hln7SesXyxyiBvhw for ; Sun, 08 Feb 2009 23:46:32 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWQqe-0001Hd-IM; Mon, 09 Feb 2009 07:46:32 +0000 Date: Mon, 9 Feb 2009 02:46:32 -0500 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 13/17] xfs: get rid of indirections in the quotaops implementation Subject: Re: [PATCH 13/17] xfs: get rid of indirections in the quotaops implementation Message-ID: <20090209074632.GA32322@infradead.org> References: <20090126073136.384490000@bombadil.infradead.org> <20090126073202.961302000@bombadil.infradead.org> <20090209024115.GH8830@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090209024115.GH8830@disturbed> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234165593 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, Feb 09, 2009 at 01:41:15PM +1100, Dave Chinner wrote: > > +STATIC int > > +xfs_fs_get_xstate( > > + struct super_block *sb, > > + struct fs_quota_stat *fqs) > > +{ > > + struct xfs_mount *mp = XFS_M(sb); > > + > > + if (!XFS_IS_QUOTA_RUNNING(mp)) > > + return -ENOSYS; > > + return xfs_qm_scall_getqstat(mp, fqs); > > The return of xfs_qm_scall_getqstat() needs to be negated. Currently it only ever returns 0. But I agree, if this ever returns an error it would be a positive one, so I added the inversion. > > + return xfs_qm_scall_setqlim(mp, id, xfs_quota_type(type), fdq); > > That should be negated as well. But this one can already return a positive error, so it's definitively needed. Thanks, I've commited the updated version. From SRS0+baec9931e3585034ca2c+1996+infradead.org+hch@bombadil.srs.infradead.org Mon Feb 9 01:53: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 n197rkdH233207 for ; Mon, 9 Feb 2009 01:53:46 -0600 X-ASG-Debug-ID: 1234165989-50f402860000-w1Z2WR 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 D714EFCE2D for ; Sun, 8 Feb 2009 23:53:09 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id JkN73CoRMTVv4hk0 for ; Sun, 08 Feb 2009 23:53:09 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWQx2-00023s-Td; Mon, 09 Feb 2009 07:53:08 +0000 Date: Mon, 9 Feb 2009 02:53:08 -0500 From: Christoph Hellwig To: Alessandro Bono Cc: Christoph Hellwig , linux-xfs , linux-kernel X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Message-ID: <20090209075308.GA7360@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234133120.12370.7.camel@champagne.cantina> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234165989 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 08, 2009 at 11:45:20PM +0100, Alessandro Bono wrote: > sure, attached That would be a missing PagePrivate bit in page_buffers() called from end_buffer_async_write. PG_private can only be cleared via drop_buffers which requires the page not having PG_writeback set which must be set until end_buffer_async_write is done. Very strange, and all this is generic code without xfs involvement. Did this happen once or can you reproduce it? From michael.monnerie@is.it-management.at Mon Feb 9 02:35: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_53 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 n198ZeDh234696 for ; Mon, 9 Feb 2009 02:35:42 -0600 X-ASG-Debug-ID: 1234168501-144500fb0000-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 48ADFFD21E for ; Mon, 9 Feb 2009 00:35:01 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id kV2jtbJ6GEWHd9ty for ; Mon, 09 Feb 2009 00:35:01 -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 A310E3E74 for ; Mon, 9 Feb 2009 09:34:59 +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 2D599400160 for ; Mon, 9 Feb 2009 09:35:00 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: 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? Date: Mon, 9 Feb 2009 09:34:59 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; ) References: <884979c90902050643m78d2e0dbt85aa7f4369e243ef@mail.gmail.com> <20090206230502.GQ24173@disturbed> In-Reply-To: <20090206230502.GQ24173@disturbed> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9027189.6jedKY3HOG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902090934.59738@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1234168502 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.17372 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 --nextPart9027189.6jedKY3HOG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Samstag 07 Februar 2009 Dave Chinner wrote: >> 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. But what would be? Of course people will pull out an USB stick/drive=20 wihtout unmounting, and it should be save anyway if 1) disk write cache=3Doff and/or barrier enabled 2) they wait until the light of the USB stick/drive stops blinking after=20 copying the file onto it. That usually means it's finished. There will be logs about problems, because it's not a nice way to=20 shutdown the filesystem, but it should be safe I'd say. 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 --nextPart9027189.6jedKY3HOG 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) iEYEABECAAYFAkmP6rMACgkQzhSR9xwSCbQ+twCfVaiIFVwg/nqinyOeU2xHmXSf M5MAnR20A+19pZG0TuvIuZbNsiolPDYh =Cqxz -----END PGP SIGNATURE----- --nextPart9027189.6jedKY3HOG-- From michael.monnerie@is.it-management.at Mon Feb 9 02:41: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,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 n198f21G234899 for ; Mon, 9 Feb 2009 02:41:02 -0600 X-ASG-Debug-ID: 1234168824-1444012c0000-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 47E6BFD288 for ; Mon, 9 Feb 2009 00:40:24 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by cuda.sgi.com with ESMTP id dMqO4BCc1Uhe9Zq4 for ; Mon, 09 Feb 2009 00:40: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 72F313E70 for ; Mon, 9 Feb 2009 09:40: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 EB75E400160 for ; Mon, 9 Feb 2009 09:40:23 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Date: Mon, 9 Feb 2009 09:40:23 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; ) References: <1234011974.7435.11.camel@champagne.cantina> <20090208221625.GB8830@disturbed> <1234135463.12370.47.camel@champagne.cantina> In-Reply-To: <1234135463.12370.47.camel@champagne.cantina> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1498478.VM3jkeMBfU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902090940.23561@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.162.198] X-Barracuda-Start-Time: 1234168825 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.17372 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 --nextPart1498478.VM3jkeMBfU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Montag 09 Februar 2009 Alessandro Bono wrote: > If needed I can replace memory dimm, this is my principal notebook > and I need it to work Go download an openSUSE 11.1 DVD from opensuse.org, boot from that DVD=20 and select "memory test" and let it run several hours. Of course you=20 could also get a copy of "memtest86" somewhere, but that DVD thingy=20 might be simpler. 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 --nextPart1498478.VM3jkeMBfU 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) iEYEABECAAYFAkmP6/cACgkQzhSR9xwSCbSy/ACgm72adEuRD1jESqHW6ysEcZGg 7TYAoKf/FFpRQfAssvBQA0bynKB6us8y =9BEY -----END PGP SIGNATURE----- --nextPart1498478.VM3jkeMBfU-- From ito_evo_megabass@pchome.com.tw Mon Feb 9 04:02: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.2 required=5.0 tests=BAYES_50,J_CHICKENPOX_12, J_CHICKENPOX_52,RCVD_IN_BL_SPAMCOP_NET 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 n19A2Qs0239260 for ; Mon, 9 Feb 2009 04:02:27 -0600 X-ASG-Debug-ID: 1234173706-7ded00890000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ms03-i.ethome.com.tw (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 08BE8FD5F9 for ; Mon, 9 Feb 2009 02:01:46 -0800 (PST) Received: from ms03-i.ethome.com.tw (ms03.ethome.com.tw [211.76.112.33]) by cuda.sgi.com with ESMTP id IRR2O9xXUgP3JtFm for ; Mon, 09 Feb 2009 02:01:46 -0800 (PST) Received: from localhost (localhost.ethome.com.tw [127.0.0.1]) by ms03-i.ethome.com.tw (Rmail v1.9 Gaghiel(v1.9p0109)) with ESMTP id 99481302A85 for ; Mon, 9 Feb 2009 18:02:19 +0800 (CST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: amavisd-new at ethome.com.tw Received: from ms03-i.ethome.com.tw ([127.0.0.1]) by localhost (ms03-i.ethome.com.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd4Qxq++d1k3 for ; Mon, 9 Feb 2009 18:02:19 +0800 (CST) Received: from eddy (123-192-108-229.dynamic.kbronet.com.tw [123.192.108.229]) by ms03-i.ethome.com.tw (Rmail v1.9 Gaghiel(v1.9p0109)) with ESMTP id 1B1C4302A83 for ; Mon, 9 Feb 2009 18:02:19 +0800 (CST) From: "Eddie" X-ASG-Orig-Subj: Megabass rods & reel for sale Subject: Megabass rods & reel for sale To: xfs@oss.sgi.com Content-Type: text/plain Reply-To: ito_evo_megabass@pchome.com.tw Date: Mon, 9 Feb 2009 18:01:13 +0800 X-Priority: 3 X-Library: Indy 9.00.10 X-Antivirus: avast! (VPS 090208-1, 2009/02/08), Outbound message X-Antivirus-Status: Clean Message-Id: <20090209100219.1B1C4302A83@ms03-i.ethome.com.tw> X-Barracuda-Connect: ms03.ethome.com.tw[211.76.112.33] X-Barracuda-Start-Time: 1234173708 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4942 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.17372 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean Dear all , I'm Eddie Li . I've some rods and reels to sell on eBay. You could check the item as below if you're interested in my auctions on eBay. Please don't hesitate to ask me if you have any question............... You could contact me wiht megabass_ito@pchome.com.tw . Have a nice day. Thanks , Eddie Li If you don't wanna receive this eMail, please let me know. I'll remove your eMail address from the list. Sorry for inconvenience. Please check==> http://shop.ebay.com.my/merchant/ionoi Megabass ito F4-59TX 5'9 Rapid Shot use rod sale No Res $0.01 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260359079693 ( Low Starting Price - No Reserve Price ) Shimano Scorpion 1602R-4 6'0" 4 pcs used rod for sale http://cgi.ebay.com.my/Shimano-Scorpion-1602R-4-60-4-pcs-used-rod-for-sale_W0QQitemZ260359073379 USD$139.00 Daiwa Silver Creek MS60L 6'0" used rod for sale http://cgi.ebay.com.my/Daiwa-Silver-Creek-MS60L-60-used-rod-for-sale_W0QQitemZ260359073114 USD$219.00 Jackall Poison C-64ML AB used rod for sale Megabass ito http://cgi.ebay.com.my/Jackall-Poison-C-64ML-AB-used-rod-for-sale-Megabass-ito_W0QQitemZ260359073555 USD$229.00 Megabass ito Alphas-ito 103L-Ai used Casting Reel sale http://cgi.ebay.com.my/Megabass-ito-Alphas-ito-103L-Ai-used-Casting-Reel-sale_W0QQitemZ260359073531 USD$269.00 TD-AEGIS 2004C used reel for sale lighter then TD-ito http://cgi.ebay.com.my/TD-AEGIS-2004C-used-reel-for-sale-lighter-then-TD-ito_W0QQitemZ260359073508 USD$279.00 Megabass itoXi'ze TD-ito 103M used reel for sale http://cgi.ebay.com.my/Megabass-itoXize-TD-ito-103M-used-reel-for-sale_W0QQitemZ260359073479 USD$339.00 Team Daiwa BA-LTD 601MLFS-02 Ingram 6'0" New rod Sale http://cgi.ebay.com.my/Team-Daiwa-BA-LTD-601MLFS-02-Ingram-60-New-rod-Sale_W0QQitemZ260359073462 USD$329.00 Daiwa i'ze TD-Z 103HL Type R+ used Left handle reel ito http://cgi.ebay.com.my/Daiwa-ize-TD-Z-103HL-Type-R-used-Left-handle-reel-ito_W0QQitemZ260359073444 USD$379.00 EverGreen TMJC-70XH 7'0" Amazon Flip used rod for sale http://cgi.ebay.com.my/EverGreen-TMJC-70XH-70-Amazon-Flip-used-rod-for-sale_W0QQitemZ260359073428 USD$389.00 EverGreen Temujin TXFC-66MR 6'6" Steed used rod sale http://cgi.ebay.com.my/EverGreen-Temujin-TXFC-66MR-66-Steed-used-rod-sale_W0QQitemZ260359073414 USD$389.00 Megabass F7-74DG 7'4" Orochi Destruction used rod sale http://cgi.ebay.com.my/Megabass-F7-74DG-74-Orochi-Destruction-used-rod-sale_W0QQitemZ260359073396 USD$439.00 Please check==> http://shop.ebay.com.my/merchant/ionoi You could check my other items : http://shop.ebay.com.my/merchant/ionoi Thank you!! From peterz@infradead.org Mon Feb 9 04:34: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=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 n19AY8pJ240559 for ; Mon, 9 Feb 2009 04:34:08 -0600 X-ASG-Debug-ID: 1234175610-70d403d70000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6969EFD812 for ; Mon, 9 Feb 2009 02:33:31 -0800 (PST) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id ht8mzNIL8tDsLAlY for ; Mon, 09 Feb 2009 02:33:31 -0800 (PST) Received: from d9244.upc-d.chello.nl ([213.46.9.244] helo=dyad.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1LWTSC-0004PZ-Jm; Mon, 09 Feb 2009 10:33:28 +0000 Received: from [192.168.0.35] (unknown [192.168.0.35]) by dyad.programming.kicks-ass.net (Postfix) with ESMTP id 6CF7039364; Mon, 9 Feb 2009 11:33:03 +0100 (CET) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Peter Zijlstra To: Alessandro Bono Cc: Dave Chinner , linux-kernel , linux-xfs In-Reply-To: <1234135463.12370.47.camel@champagne.cantina> References: <1234011974.7435.11.camel@champagne.cantina> <20090208221625.GB8830@disturbed> <1234135463.12370.47.camel@champagne.cantina> Content-Type: text/plain Date: Mon, 09 Feb 2009 11:33:27 +0100 Message-Id: <1234175607.5951.76.camel@laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.25.90 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1234175611 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.17372 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, 2009-02-09 at 00:24 +0100, Alessandro Bono wrote: > In the past I lose configuration files from kde, gconf based programs > (gnome), pan, firefox, etc > maybe xfs expose more this problem >From what I heard Linux userspace is on crack and thinks it can get away without calling fsync(). From alessandro.bono@gmail.com Mon Feb 9 05:07:24 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,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 n19B7N7K241874 for ; Mon, 9 Feb 2009 05:07:24 -0600 X-ASG-Debug-ID: 1234177605-2862010a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-fx0-f12.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BF1E618F2F71 for ; Mon, 9 Feb 2009 03:06:45 -0800 (PST) Received: from mail-fx0-f12.google.com (mail-fx0-f12.google.com [209.85.220.12]) by cuda.sgi.com with ESMTP id j8FrS0mIxfE4JCZx for ; Mon, 09 Feb 2009 03:06:45 -0800 (PST) Received: by fxm5 with SMTP id 5so642107fxm.20 for ; Mon, 09 Feb 2009 03:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=WEcTU9VRo3cZS/SvWk4wdJ9VUt+u62v23dV6prXPOWo=; b=eTh7RDfrITwzQv4220DJEzIce+ykYfKV/2Q0ATJWkIAVVN/wtWdDDrPWtIkHFLHzUP 8ZxrHAJRm03rbyk8nT2FaUkt8EdBifyvrkljCChvAxWAOehc6YSJv4y3xSaN1PztdVxd DYNKxKi2NduK0m9a/HBiLZigGaKlkx9Wy1Ykg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=E5xXRXigKUu1BbvSaGbfvFgmj5PBcTnbr8hXM4zIYNFL+lGTwtnmxpXqMNXzR37ujx tSl1gHU3FAg62fKfIkl+tJQ+L60tsYphko7ktd0zggYzyI1/832Pw+r8VGeU7uvKhdrb xQUGBhqXWYRjB3f0iJn0EMgAcHZUGUx0luj8c= Received: by 10.103.248.17 with SMTP id a17mr1773050mus.83.1234170154856; Mon, 09 Feb 2009 01:02:34 -0800 (PST) Received: from ?10.151.1.19? (host-62-10-44-87.cust-adsl.tiscali.it [62.10.44.87]) by mx.google.com with ESMTPS id e9sm1726842muf.8.2009.02.09.01.02.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Feb 2009 01:02:34 -0800 (PST) X-ASG-Orig-Subj: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 Subject: Re: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4 From: Alessandro Bono To: Christoph Hellwig Cc: linux-xfs , linux-kernel In-Reply-To: <20090209075308.GA7360@infradead.org> References: <1234011974.7435.11.camel@champagne.cantina> <20090208222859.GA2532@infradead.org> <1234132752.12370.0.camel@champagne.cantina> <20090208224249.GA11931@infradead.org> <1234133120.12370.7.camel@champagne.cantina> <20090209075308.GA7360@infradead.org> Content-Type: multipart/mixed; boundary="=-rXq4RUyDVrzU2JG/c0Qa" Date: Mon, 09 Feb 2009 10:02:28 +0100 Message-Id: <1234170148.7544.10.camel@champagne.cantina> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 X-Barracuda-Connect: mail-fx0-f12.google.com[209.85.220.12] X-Barracuda-Start-Time: 1234177606 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.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.17372 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 --=-rXq4RUyDVrzU2JG/c0Qa Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2009-02-09 at 02:53 -0500, Christoph Hellwig wrote: > On Sun, Feb 08, 2009 at 11:45:20PM +0100, Alessandro Bono wrote: > > sure, attached > > That would be a missing PagePrivate bit in page_buffers() called from > end_buffer_async_write. PG_private can only be cleared via drop_buffers > which requires the page not having PG_writeback set which must be > set until end_buffer_async_write is done. Very strange, and all this > is generic code without xfs involvement. Did this happen once > or can you reproduce it? > this night to eliminate ext4 from equation I reformatted usb disk in xfs and started rsync as usual (after a machine restart) this is the result (also attached for better readability) Feb 9 01:33:17 champagne kernel: [ 3689.392066] ------------[ cut here ]------------ Feb 9 01:33:17 champagne kernel: [ 3689.392071] kernel BUG at fs/buffer.c:470! Feb 9 01:33:17 champagne kernel: [ 3689.392072] invalid opcode: 0000 [#1] SMP Feb 9 01:33:17 champagne kernel: [ 3689.392075] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map Feb 9 01:33:17 champagne kernel: [ 3689.392077] CPU 1 Feb 9 01:33:17 champagne kernel: [ 3689.392078] Modules linked in: usb_storage libusual af_packet binfmt_misc rfcomm bridge stp llc bnep sco l2cap acpi_cpu freq cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative sbs sbshc pci_slot ipt_LOG xt_limit ipt_addrtype xt_ state xt_tcpudp xt_conntrack ip6table_filter ip6_tables ipv6 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables ext3 jbd mbcache hp_wmi coretemp sbp2 loop arc4 ecb snd_seq_dummy iwlagn snd_seq_oss iwlcore snd_seq_midi sn d_hda_intel rfkill snd_rawmidi snd_pcm_oss snd_mixer_oss pcmcia mac80211 lis3lv02d leds_hp_disk snd_seq_midi_event tpm_infineon tpm tpm_bios btusb parport_p c parport sdhci_pci sdhci mmc_core ricoh_mmc yenta_socket rsrc_nonstatic pcmcia_core video output bluetooth led_class wmi pcspkr evdev container snd_pcm snd _page_alloc button snd_seq ac cfg80211 iTCO_wdt iTCO_vendor_support psmouse serio_raw snd_hwd Feb 9 01:33:17 champagne kernel: p battery snd_timer snd_seq_device snd dm_multipath soundcore xfs sd_mod crc_t10dif sg sr_mod cdrom ohci1394 ahci ata_piix ieee1394 libata scsi_mod ehci_hcd uhci_hcd usbcore e1000e dm_crypt dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processor fan thermal_sys hwm on fuse Feb 9 01:33:17 champagne kernel: [ 3689.392149] Pid: 2490, comm: xfsdatad/1 Not tainted 2.6.28.4 #1 Feb 9 01:33:17 champagne kernel: [ 3689.392151] RIP: 0010:[] [] end_buffer_async_write +0x8f/0x12c Feb 9 01:33:17 champagne kernel: [ 3689.392158] RSP: 0018:ffff8801389a3e40 EFLAGS: 00010246 Feb 9 01:33:17 champagne kernel: [ 3689.392159] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 000000000000000b Feb 9 01:33:17 champagne kernel: [ 3689.392161] RDX: 0000000000000000 RSI: ffffe200014d7edc RDI: 0000000000000040 Feb 9 01:33:17 champagne kernel: [ 3689.392163] RBP: ffff8800358ef930 R08: 4000000000000000 R09: ffff880039f25302 Feb 9 01:33:17 champagne kernel: [ 3689.392165] R10: ffff88003782e4e0 R11: ffff8801389a3dd0 R12: ffff88013880b088 Feb 9 01:33:17 champagne kernel: [ 3689.392166] R13: ffff88013b85fee0 R14: ffffe200014d7edc R15: 0000000000000001 Feb 9 01:33:17 champagne kernel: [ 3689.392169] FS: 0000000000000000(0000) GS:ffff88013b803a00(0000) knlGS:0000000000000000 Feb 9 01:33:17 champagne kernel: [ 3689.392171] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Feb 9 01:33:17 champagne kernel: [ 3689.392172] CR2: 00007f49ba397000 CR3: 000000006e112000 CR4: 00000000000006e0 Feb 9 01:33:17 champagne kernel: [ 3689.392174] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Feb 9 01:33:17 champagne kernel: [ 3689.392176] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Feb 9 01:33:17 champagne kernel: [ 3689.392178] Process xfsdatad/1 (pid: 2490, threadinfo ffff8801389a2000, task ffff880139f9cc50) Feb 9 01:33:17 champagne kernel: [ 3689.392180] Stack: Feb 9 01:33:17 champagne kernel: [ 3689.392181] ffff8801389a3e50 ffffffff8022806f 0000000000000286 ffffffff8030be35 Feb 9 01:33:17 champagne kernel: [ 3689.392184] ffff8800358efaf0 ffff8800379e7960 ffff88013880b088 ffff88013b85fee0 Feb 9 01:33:17 champagne kernel: [ 3689.392187] ffff88013b85ff00 ffffffffa01c5269 ffffffffa01c53db ffff88013880b080 Feb 9 01:33:17 champagne kernel: [ 3689.392190] Call Trace: Feb 9 01:33:17 champagne kernel: [ 3689.392191] [] ? need_resched+0x1e/0x28 Feb 9 01:33:17 champagne kernel: [ 3689.392195] [] ? __up_write+0x12/0x45 Feb 9 01:33:17 champagne kernel: [ 3689.392201] [] ? xfs_destroy_ioend+0x23/0x71 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392225] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392243] [] ? xfs_end_bio_delalloc+0x0/0x19 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392259] [] ? run_workqueue+0x79/0xfe Feb 9 01:33:17 champagne kernel: [ 3689.392263] [] ? worker_thread+0xf0/0x102 Feb 9 01:33:17 champagne kernel: [ 3689.392265] [] ? autoremove_wake_function+0x0/0x2e Feb 9 01:33:17 champagne kernel: [ 3689.392269] [] ? worker_thread+0x0/0x102 Feb 9 01:33:17 champagne kernel: [ 3689.392271] [] ? kthread+0x47/0x73 Feb 9 01:33:17 champagne kernel: [ 3689.392274] [] ? schedule_tail+0x27/0x60 Feb 9 01:33:17 champagne kernel: [ 3689.392277] [] ? child_rip+0xa/0x11 Feb 9 01:33:17 champagne kernel: [ 3689.392280] [] ? kthread+0x0/0x73 Feb 9 01:33:17 champagne kernel: [ 3689.392283] [] ? child_rip+0x0/0x11 Feb 9 01:33:17 champagne kernel: [ 3689.392285] Code: 8b 46 18 48 8d 50 62 f0 80 48 62 20 48 8d 45 01 f0 80 4d 01 08 f0 80 65 00 fe f0 41 80 0e 02 4c 89 f7 e8 f4 e3 ff ff 85 c0 75 04 <0f> 0b eb fe 4d 8b 66 10 9c 41 5d fa eb 13 f3 90 4c 89 e6 bf 04 Feb 9 01:33:17 champagne kernel: [ 3689.392307] RIP [] end_buffer_async_write+0x8f/0x12c Feb 9 01:33:17 champagne kernel: [ 3689.392310] RSP Feb 9 01:33:17 champagne kernel: [ 3689.392312] ---[ end trace 0c3741da6a2192b7 ]--- -- --- Cordiali Saluti Alessandro Bono --=-rXq4RUyDVrzU2JG/c0Qa Content-Disposition: attachment; filename="bug3-2.2.28.4" Content-Type: text/plain; name="bug3-2.2.28.4"; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Feb 9 01:33:17 champagne kernel: [ 3689.392066] ------------[ cut here ]--= ---------- Feb 9 01:33:17 champagne kernel: [ 3689.392071] kernel BUG at fs/buffer.c:= 470! Feb 9 01:33:17 champagne kernel: [ 3689.392072] invalid opcode: 0000 [#1] = SMP=20 Feb 9 01:33:17 champagne kernel: [ 3689.392075] last sysfs file: /sys/devi= ces/system/cpu/cpu1/cache/index2/shared_cpu_map Feb 9 01:33:17 champagne kernel: [ 3689.392077] CPU 1=20 Feb 9 01:33:17 champagne kernel: [ 3689.392078] Modules linked in: usb_sto= rage libusual af_packet binfmt_misc rfcomm bridge stp llc bnep sco l2cap ac= pi_cpufreq cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondema= nd freq_table cpufreq_conservative sbs sbshc pci_slot ipt_LOG xt_limit ipt_= addrtype xt_state xt_tcpudp xt_conntrack ip6table_filter ip6_tables ipv6 nf= _nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv= 4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables ext3 jbd = mbcache hp_wmi coretemp sbp2 loop arc4 ecb snd_seq_dummy iwlagn snd_seq_oss= iwlcore snd_seq_midi snd_hda_intel rfkill snd_rawmidi snd_pcm_oss snd_mixe= r_oss pcmcia mac80211 lis3lv02d leds_hp_disk snd_seq_midi_event tpm_infineo= n tpm tpm_bios btusb parport_pc parport sdhci_pci sdhci mmc_core ricoh_mmc = yenta_socket rsrc_nonstatic pcmcia_core video output bluetooth led_class wm= i pcspkr evdev container snd_pcm snd_page_alloc button snd_seq ac cfg80211 = iTCO_wdt iTCO_vendor_support psmouse serio_raw snd_hwd Feb 9 01:33:17 champagne kernel: p battery snd_timer snd_seq_device snd dm= _multipath soundcore xfs sd_mod crc_t10dif sg sr_mod cdrom ohci1394 ahci at= a_piix ieee1394 libata scsi_mod ehci_hcd uhci_hcd usbcore e1000e dm_crypt d= m_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processor fan the= rmal_sys hwmon fuse Feb 9 01:33:17 champagne kernel: [ 3689.392149] Pid: 2490, comm: xfsdatad/= 1 Not tainted 2.6.28.4 #1 Feb 9 01:33:17 champagne kernel: [ 3689.392151] RIP: 0010:[] [] end_buffer_async_write+0x8f/0x12c Feb 9 01:33:17 champagne kernel: [ 3689.392158] RSP: 0018:ffff8801389a3e40= EFLAGS: 00010246 Feb 9 01:33:17 champagne kernel: [ 3689.392159] RAX: 0000000000000000 RBX:= 0000000000000001 RCX: 000000000000000b Feb 9 01:33:17 champagne kernel: [ 3689.392161] RDX: 0000000000000000 RSI:= ffffe200014d7edc RDI: 0000000000000040 Feb 9 01:33:17 champagne kernel: [ 3689.392163] RBP: ffff8800358ef930 R08:= 4000000000000000 R09: ffff880039f25302 Feb 9 01:33:17 champagne kernel: [ 3689.392165] R10: ffff88003782e4e0 R11:= ffff8801389a3dd0 R12: ffff88013880b088 Feb 9 01:33:17 champagne kernel: [ 3689.392166] R13: ffff88013b85fee0 R14:= ffffe200014d7edc R15: 0000000000000001 Feb 9 01:33:17 champagne kernel: [ 3689.392169] FS: 0000000000000000(0000= ) GS:ffff88013b803a00(0000) knlGS:0000000000000000 Feb 9 01:33:17 champagne kernel: [ 3689.392171] CS: 0010 DS: 0018 ES: 001= 8 CR0: 000000008005003b Feb 9 01:33:17 champagne kernel: [ 3689.392172] CR2: 00007f49ba397000 CR3:= 000000006e112000 CR4: 00000000000006e0 Feb 9 01:33:17 champagne kernel: [ 3689.392174] DR0: 0000000000000000 DR1:= 0000000000000000 DR2: 0000000000000000 Feb 9 01:33:17 champagne kernel: [ 3689.392176] DR3: 0000000000000000 DR6:= 00000000ffff0ff0 DR7: 0000000000000400 Feb 9 01:33:17 champagne kernel: [ 3689.392178] Process xfsdatad/1 (pid: 2= 490, threadinfo ffff8801389a2000, task ffff880139f9cc50) Feb 9 01:33:17 champagne kernel: [ 3689.392180] Stack: Feb 9 01:33:17 champagne kernel: [ 3689.392181] ffff8801389a3e50 ffffffff= 8022806f 0000000000000286 ffffffff8030be35 Feb 9 01:33:17 champagne kernel: [ 3689.392184] ffff8800358efaf0 ffff8800= 379e7960 ffff88013880b088 ffff88013b85fee0 Feb 9 01:33:17 champagne kernel: [ 3689.392187] ffff88013b85ff00 ffffffff= a01c5269 ffffffffa01c53db ffff88013880b080 Feb 9 01:33:17 champagne kernel: [ 3689.392190] Call Trace: Feb 9 01:33:17 champagne kernel: [ 3689.392191] [] ? ne= ed_resched+0x1e/0x28 Feb 9 01:33:17 champagne kernel: [ 3689.392195] [] ? __= up_write+0x12/0x45 Feb 9 01:33:17 champagne kernel: [ 3689.392201] [] ? xf= s_destroy_ioend+0x23/0x71 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392225] [] ? xf= s_end_bio_delalloc+0x0/0x19 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392243] [] ? xf= s_end_bio_delalloc+0x0/0x19 [xfs] Feb 9 01:33:17 champagne kernel: [ 3689.392259] [] ? ru= n_workqueue+0x79/0xfe Feb 9 01:33:17 champagne kernel: [ 3689.392263] [] ? wo= rker_thread+0xf0/0x102 Feb 9 01:33:17 champagne kernel: [ 3689.392265] [] ? au= toremove_wake_function+0x0/0x2e Feb 9 01:33:17 champagne kernel: [ 3689.392269] [] ? wo= rker_thread+0x0/0x102 Feb 9 01:33:17 champagne kernel: [ 3689.392271] [] ? kt= hread+0x47/0x73 Feb 9 01:33:17 champagne kernel: [ 3689.392274] [] ? sc= hedule_tail+0x27/0x60 Feb 9 01:33:17 champagne kernel: [ 3689.392277] [] ? ch= ild_rip+0xa/0x11 Feb 9 01:33:17 champagne kernel: [ 3689.392280] [] ? kt= hread+0x0/0x73 Feb 9 01:33:17 champagne kernel: [ 3689.392283] [] ? ch= ild_rip+0x0/0x11 Feb 9 01:33:17 champagne kernel: [ 3689.392285] Code: 8b 46 18 48 8d 50 62= f0 80 48 62 20 48 8d 45 01 f0 80 4d 01 08 f0 80 65 00 fe f0 41 80 0e 02 4c= 89 f7 e8 f4 e3 ff ff 85 c0 75 04 <0f> 0b eb fe 4d 8b 66 10 9c 41 5d fa eb = 13 f3 90 4c 89 e6 bf 04=20 Feb 9 01:33:17 champagne kernel: [ 3689.392307] RIP [] = end_buffer_async_write+0x8f/0x12c Feb 9 01:33:17 champagne kernel: [ 3689.392310] RSP Feb 9 01:33:17 champagne kernel: [ 3689.392312] ---[ end trace 0c3741da6a2= 192b7 ]--- --=-rXq4RUyDVrzU2JG/c0Qa-- From webchannel2@gmail.com Mon Feb 9 08:28:46 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,HTML_FONT_SIZE_HUGE, 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 n19ESj4h250815 for ; Mon, 9 Feb 2009 08:28:46 -0600 X-ASG-Debug-ID: 1234189683-2b9a03bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from vsmtp6.jaring.my (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 83C2718F3335 for ; Mon, 9 Feb 2009 06:28:03 -0800 (PST) Received: from vsmtp6.jaring.my (vsmtp6.jaring.my [192.228.250.86]) by cuda.sgi.com with ESMTP id RlQ65LTOGvdQZ90k for ; Mon, 09 Feb 2009 06:28:03 -0800 (PST) Received: from localhost (localhost.jaring.my [127.0.0.1]) by vsmtp6.jaring.my (8.14.3/8.14.3) with ESMTP id n19ERqde002908; Mon, 9 Feb 2009 22:27:52 +0800 (MYT) (envelope-from webchannel2@gmail.com) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: by JARING Malware Filters (jaring.my) Received: from vsmtp6.jaring.my ([127.0.0.1]) by localhost (vsmtp6.jaring.my [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EHTulAvjHATT; Mon, 9 Feb 2009 22:27:51 +0800 (MYT) Received: from Director (j121.kja51.jaring.my [61.6.139.135]) by vsmtp6.jaring.my (8.14.3/8.14.3) with ESMTP id n19ERa70002634; Mon, 9 Feb 2009 22:27:40 +0800 (MYT) (envelope-from webchannel2@gmail.com) Message-Id: <200902091427.n19ERa70002634@vsmtp6.jaring.my> From: "Sean Wong" Reply-To: sales@channel2.com.my X-ASG-Orig-Subj: 2009 New Web Design for Your Company.. Subject: 2009 New Web Design for Your Company.. To: refer2u@msia-biz.org Date: Mon, 09 Feb 2009 22:27:20 +0800 X-Mailer: diffondi V4,0,4,0 (W95/NT) (Build: Aug 26 2001) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: vsmtp6.jaring.my[192.228.250.86] X-Barracuda-Start-Time: 1234189686 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4997 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.39 X-Barracuda-Spam-Status: No, SCORE=0.39 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_FONT_SIZE_HUGE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17379 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.39 HTML_FONT_SIZE_HUGE BODY: HTML font size is huge X-Virus-Status: Clean This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings! It's time to have a new web design for your company=2E=2E=2E Now you may have a new web design for only RM750 while a full web package for only RM880 including domain name, web/email hosting, plus 4-pages web design! We also provide web page updates and maintenance at reasonable rate=2E You may also order or renew your web/email hosting = at only RM200/year (unlimited email accounts): Domain Name =2Ecom RM50 =2Ecom=2Emy RM100 Web Hosting Unlimited Emails 1Gig RM200 Web Design 4 Pages RM750 10 Pages RM1490 WebChois 4 Pages + Domain + Hosting =3D RM880 Your web pages will be customized to your corporate image and marketing strategy=2E You'll be amazed how easy and affordable to have your fresh website online now! Feel free to contact me for more information=2E Thanks!   Regards, Sean WongMarketing Executive Tel: 03-58822355, 58821580 Details check: http://www=2Echannel2=2Ecom=2Emy To unsubscribe pls reply: nolist@channel2=2Ecom=2Emy R R R R R ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings!

It's time to have a new web = design for your company=2E=2E=2E

Now you may have a new w= eb design for only RM750 while a full web package for only RM880 including domain = name, web/email hosting, plus 4-pages web design!

We also provide web page updates and maintenanc= e at reasonable rate=2E You may also order or renew your web/email= hosting at only RM200/year (unlimited email accounts):


Domain = Name
=2Ecom RM50
=2Ecom=2Emy RM100
Web Hosting
Unlimited Emails
1Gig RM200<= /div>

Web Design
4 Pages RM750
10 Pages RM1490

WebChois
4 Pages + Domain
+ Hosting =3D RM880


Your web pages will be customized to your corporate image and marketing st= rategy=2E You'll be amazed how easy and affordable to have your fresh website online now!

Feel free to contact me = for more information=2E Thanks!
 

Regards,

= Sean Wong
Marketing Execu= tive
Tel: 03-58822355, 58821580

Details check: http://www=2Echannel2=2Ecom=2Emy=

To unsubscribe pls = reply:
nolist@channel2=2Ecom=2Emy

R R R R R
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From rg@stz-softwaretechnik.de Mon Feb 9 08:34: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.0 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 n19EYECL251061 for ; Mon, 9 Feb 2009 08:34:15 -0600 X-ASG-Debug-ID: 1234190016-2bef03c90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from stlx01.stz-softwaretechnik.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7011C18F337A for ; Mon, 9 Feb 2009 06:33:36 -0800 (PST) Received: from stlx01.stz-softwaretechnik.com (stz-softwaretechnik.de [217.160.223.211]) by cuda.sgi.com with ESMTP id 7ZC9Xve6w9q5Sxc6 for ; Mon, 09 Feb 2009 06:33:36 -0800 (PST) Received: from rg by stlx01.stz-softwaretechnik.com with local (Exim 3.36 #1 (Debian)) id 1LWXCP-0005hi-00 for ; Mon, 09 Feb 2009 15:33:25 +0100 Date: Mon, 9 Feb 2009 15:33:15 +0100 From: Ralf Gross To: xfs@oss.sgi.com X-ASG-Orig-Subj: kernel: Access to block zero: fs: inode: 231137029.... Subject: kernel: Access to block zero: fs: inode: 231137029.... Message-ID: <20090209143315.GB2535@p15145560.pureserver.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: Ralf Gross X-Barracuda-Connect: stz-softwaretechnik.de[217.160.223.211] X-Barracuda-Start-Time: 1234190017 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.17379 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, this is the second time I got hit by this problem in the last 2 months. The server did respond to ping and all processes were still running, but the load went up to >30. Neither a shutdown nor a sync command could be executed, in the end I had to reset the server because nobody could access the samba shares anymore. System: Debian Etch linux-image-2.6.18-6-amd64 (since today 2.6.24 from etch-n-half). sdg is a fibre attached (QLA2422) RAID array. Any idea what the reason for this could be? xfs_check of /dev/sdg didn't find anything. Ralf Feb 6 20:53:04 VU0EF005 kernel: Access to block zero: fs: inode: 231137029 start_block : 0 start_off : 0 blkcnt : 0 extent-state : 0 Feb 6 20:53:04 VU0EF005 kernel: ----------- [cut here ] --------- [please bite here ] --------- Feb 6 20:53:04 VU0EF005 kernel: Kernel BUG at fs/xfs/support/debug.c:57 Feb 6 20:53:04 VU0EF005 kernel: invalid opcode: 0000 [1] SMP Feb 6 20:53:04 VU0EF005 kernel: CPU 0 Feb 6 20:53:04 VU0EF005 kernel: Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc button ac battery ipv6 bonding xfs loop sr_mod parport_pc parport floppy sg i2c_i801 i2c_core serio_raw psmouse pcspkr shpchp pci_hotplug evdev joydev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod raid1 md_mod ide_generic usbhid usb_storage ide_cd cdrom ehci_hcd uhci_hcd e1000 sd_mod thermal processor fan qla2xxx firmware_class scsi_transport_fc ahci libata scsi_mod piix ide_core Feb 6 20:53:04 VU0EF005 kernel: Pid: 10532, comm: smbd Not tainted 2.6.18-6-amd64 #1 Feb 6 20:53:04 VU0EF005 kernel: RIP: 0010:[] [] :xfs:cmn_err+0xda/0x11f Feb 6 20:53:04 VU0EF005 kernel: RSP: 0018:ffff810132b95868 EFLAGS: 00010246 Feb 6 20:53:04 VU0EF005 kernel: RAX: 000000000000006f RBX: ffffffff88297a7c RCX: ffff81042149c000 Feb 6 20:53:04 VU0EF005 kernel: RDX: 0000000000000003 RSI: 0000000000000297 RDI: ffffffff882afc8c Feb 6 20:53:04 VU0EF005 kernel: RBP: 0000000000000000 R08: ffffffff8044f868 R09: 0000000000000000 Feb 6 20:53:04 VU0EF005 kernel: R10: 0000000000000046 R11: ffff810001036620 R12: 0000000000000297 Feb 6 20:53:04 VU0EF005 kernel: R13: ffff810219837a00 R14: 0000000001840000 R15: ffff810132b95c58 Feb 6 20:53:04 VU0EF005 kernel: FS: 00002b9024223e80(0000) GS:ffffffff80521000(0000) knlGS:0000000000000000 Feb 6 20:53:04 VU0EF005 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Feb 6 20:53:04 VU0EF005 kernel: CR2: 00002b7956cb2000 CR3: 00000002121d4000 CR4: 00000000000006e0 Feb 6 20:53:04 VU0EF005 kernel: Process smbd (pid: 10532, threadinfo ffff810132b94000, task ffff81041e62f080) Feb 6 20:53:04 VU0EF005 kernel: Stack: 0000003000000030 ffff810132b95968 ffff810132b95888 000000000000183f Feb 6 20:53:04 VU0EF005 kernel: ffffffff8826f6cb ffff810132b95ba0 ffff810420f6e2e0 000000000dc6df05 Feb 6 20:53:04 VU0EF005 kernel: 0000000000000000 0000000000000000 ffff810219835000 ffff810219837a00 Feb 6 20:53:04 VU0EF005 kernel: Call Trace: Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_iext_get_ext+0x43/0x69 Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_iext_get_ext+0x43/0x69 Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_bmap_search_multi_extents+0x9a/0xd7 Feb 6 20:53:04 VU0EF005 kernel: [] __up_write+0x21/0x10d Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_bmap_search_extents+0xb5/0xc2 Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_bmapi+0x29a/0x1c83 Feb 6 20:53:04 VU0EF005 kernel: [] remove_wait_queue+0x12/0x45 Feb 6 20:53:04 VU0EF005 kernel: [] free_poll_entry+0x11/0x1a Feb 6 20:53:04 VU0EF005 kernel: [] poll_freewait+0x29/0x6a Feb 6 20:53:04 VU0EF005 kernel: [] do_select+0x41c/0x439 Feb 6 20:53:04 VU0EF005 kernel: [] default_wake_function+0x0/0xe Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_zero_eof+0x180/0x22e Feb 6 20:53:04 VU0EF005 kernel: [] _spin_lock_bh+0x9/0x14 Feb 6 20:53:04 VU0EF005 kernel: [] current_fs_time+0x3b/0x40 Feb 6 20:53:04 VU0EF005 kernel: [] __down_write_nested+0x12/0x9a Feb 6 20:53:04 VU0EF005 kernel: [] tcp_recvmsg+0x9f0/0xb05 Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_write+0x4af/0x95c Feb 6 20:53:04 VU0EF005 kernel: [] sock_aio_read+0x4f/0x5e Feb 6 20:53:04 VU0EF005 kernel: [] :xfs:xfs_file_aio_write+0x69/0x6e Feb 6 20:53:04 VU0EF005 kernel: [] do_sync_write+0xc7/0x104 Feb 6 20:53:04 VU0EF005 kernel: [] autoremove_wake_function+0x0/0x2e Feb 6 20:53:04 VU0EF005 kernel: [] mntput_no_expire+0x19/0x8b Feb 6 20:53:04 VU0EF005 kernel: [] vfs_write+0xce/0x174 Feb 6 20:53:04 VU0EF005 kernel: [] sys_pwrite64+0x50/0x70 Feb 6 20:53:04 VU0EF005 kernel: [] system_call+0x7e/0x83 Feb 6 20:53:04 VU0EF005 kernel: Feb 6 20:53:04 VU0EF005 kernel: Feb 6 20:53:04 VU0EF005 kernel: Code: 0f 0b 68 b0 b0 29 88 c2 39 00 eb 2b 48 c7 c6 ce b0 29 88 48 Feb 6 20:53:04 VU0EF005 kernel: RIP [] :xfs:cmn_err+0xda/0x11f Feb 6 20:53:04 VU0EF005 kernel: RSP From felixb@oss.sgi.com Mon Feb 9 10:08:38 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 n19G8bLC255347 for ; Mon, 9 Feb 2009 10:08:38 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n19G8XnX255309; Mon, 9 Feb 2009 10:08:33 -0600 Date: Mon, 9 Feb 2009 10:08:33 -0600 Message-Id: <200902091608.n19G8XnX255309@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-12763-gd5b5623 X-Git-Refname: refs/heads/mainline X-Git-Reftype: branch X-Git-Oldrev: b1792e367053968f2ddb48bc911d314143ce6242 X-Git-Newrev: d5b562330ec766292a3ac54ae5e0673610bd5b3d 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 43f3f05 [XFS] Warn on transaction in flight on read-only remount 6139a23 xfs: Check buffer lengths in log recovery f0e0059 don't reallocate sxp variable passed into xfs_swapext from b1792e367053968f2ddb48bc911d314143ce6242 (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/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(-) hooks/post-receive -- XFS development tree From felixb@oss.sgi.com Mon Feb 9 10:08:41 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 n19G8fDe255425 for ; Mon, 9 Feb 2009 10:08:41 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n19G8cDJ255352; Mon, 9 Feb 2009 10:08:38 -0600 Date: Mon, 9 Feb 2009 10:08:38 -0600 Message-Id: <200902091608.n19G8cDJ255352@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-12800-g9483c89 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 3228149ceb8b045e324cd268be9182bb26e6488b X-Git-Newrev: 9483c89eae58bee79b0280c625ca35a7b78fa300 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 8e9b6e7 xfs: remove the unused XFS_QMOPT_DQLOCK flag 4346cdd xfs: cleanup xfs_find_handle ef8f7fc xfs: cleanup error handling in xfs_swap_extents d4bb6d0 xfs: merge xfs_inode_flush into xfs_fs_write_inode e1486de xfs: factor out attr fork reset handling c52e9fd xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK cb3f35b xfs: tiny cleanup for xfs_link b93b6e4 xfs: make sure to free the real-time inodes in the mount error path f9057e3 xfs: cleanup error handling in xfs_mountfs: from 3228149ceb8b045e324cd268be9182bb26e6488b (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 8e9b6e7fa4544ea8a0e030c8987b918509c8ff47 Author: Christoph Hellwig Date: Sun Feb 8 21:51:42 2009 +0100 xfs: remove the unused XFS_QMOPT_DQLOCK flag The XFS_QMOPT_DQLOCK flag introduces major complexity in the quota subsystem but isn't actually used anywhere. So remove it and all the hazzles it introduces. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit 4346cdd4647e5eef15817dbfc2c091cac55e33d9 Author: Christoph Hellwig Date: Sun Feb 8 21:51:14 2009 +0100 xfs: cleanup xfs_find_handle 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 Reviewed-by: Felix Blyakher commit ef8f7fc549bf345d92f396f5aa7b152b4969cbf7 Author: Josef 'Jeff' Sipek Date: Wed Feb 4 09:37:43 2009 +0100 xfs: cleanup error handling in xfs_swap_extents Use multiple lables for proper error unwinding and get rid of some now superflous variables. Signed-off-by: Josef 'Jeff' Sipek Signed-off-by: Christoph Hellwig Tested-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit d4bb6d0698090c485e2e80e8a13852be5a8bfb04 Author: Christoph Hellwig Date: Wed Feb 4 09:36:19 2009 +0100 xfs: merge xfs_inode_flush into xfs_fs_write_inode Splitting the task for a VFS-induced inode flush into two functions doesn't make any sense, so merge the two functions dealing with it. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher Reviewed-by: Dave Chinner commit e1486dea0bf4bc75a52a983281076f454a894b66 Author: Christoph Hellwig Date: Wed Feb 4 09:36:00 2009 +0100 xfs: factor out attr fork reset handling We currently duplicate code to reset the attribute fork after the last attribute has been deleted. Factor this out into a small helper. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit c52e9fd8a9d3ac019680ffa315c1a0689d401ce3 Author: Christoph Hellwig Date: Wed Feb 4 09:34:34 2009 +0100 xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK These aren't only unused but also reference a lock that doesn't exist anymore. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit cb3f35bb3bf0759e00cd4f68155da9b636421f84 Author: Christoph Hellwig Date: Wed Feb 4 09:34:20 2009 +0100 xfs: tiny cleanup for xfs_link The source and target inodes are guaranteed to never be the same by the VFS, so no need to check for that (and we would get into bad trouble later anyway if that were the case). Also clean up the error handling to use two gotos instead of nested conditions. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit b93b6e434c046459cf3111c76dce46ba4abcb2b6 Author: Christoph Hellwig Date: Wed Feb 4 09:33:58 2009 +0100 xfs: make sure to free the real-time inodes in the mount error path When mount fails after allocating the real-time inodes we currently leak them. Add a new helper to free the real-time inodes which can be used by both the mount and unmount path. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher commit f9057e3da79d18fdbd9d6adbb183f032c614feeb Author: Christoph Hellwig Date: Wed Feb 4 09:31:52 2009 +0100 xfs: cleanup error handling in xfs_mountfs: Clean up the error handling in xfs_mountfs. Use readable goto label names, simplify the uuid handling and other error conditions. Signed-off-by: Christoph Hellwig Reviewed-by: Felix Blyakher ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_ioctl.c | 116 +++++++++++++------------------ fs/xfs/linux-2.6/xfs_super.c | 43 ++++++++++-- fs/xfs/linux-2.6/xfs_vnode.h | 5 -- fs/xfs/quota/xfs_qm.c | 146 ++++++++++++---------------------------- fs/xfs/quota/xfs_trans_dquot.c | 16 ++--- fs/xfs/xfs_attr_leaf.c | 55 +++++++-------- fs/xfs/xfs_dfrag.c | 62 +++++++---------- fs/xfs/xfs_mount.c | 84 ++++++++++------------- fs/xfs/xfs_mount.h | 3 - fs/xfs/xfs_quota.h | 1 - fs/xfs/xfs_rtalloc.c | 10 +++ fs/xfs/xfs_rtalloc.h | 4 + fs/xfs/xfs_vnodeops.c | 51 +------------- fs/xfs/xfs_vnodeops.h | 1 - 14 files changed, 244 insertions(+), 353 deletions(-) hooks/post-receive -- XFS development tree From m_mlk@yahoo.com Mon Feb 9 10:44:19 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_WEB 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 n19GiIuv256891 for ; Mon, 9 Feb 2009 10:44:19 -0600 X-ASG-Debug-ID: 1234197820-62b902360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34506.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id E04641B39E48 for ; Mon, 9 Feb 2009 08:43:40 -0800 (PST) Received: from web34506.mail.mud.yahoo.com (web34506.mail.mud.yahoo.com [66.163.178.172]) by cuda.sgi.com with SMTP id fOibIN9mFvIrCplz for ; Mon, 09 Feb 2009 08:43:40 -0800 (PST) Received: (qmail 40880 invoked by uid 60001); 9 Feb 2009 16:43:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=iToWbgIAW0iccymX3qYeDyj8Fdjgpsb3s1PA4FYRugagrkRMg/P/F5CZZrmk9IWgonrjCIwlHNnoEmXlpcUby2Q7Q1xJ4X9XYlbBzpiePFn066QhkK3LLjw363eCo3DRtmB+ze9jba8IO3Cdsm2LEp1FEA5TtXQQpVYzNE9R7bY=; X-YMail-OSG: a1Yjg98VM1mBKCuQfLsfCDaDD8i7l6Uaz4xF8b8UH9JLSrWCJfl.DFJChvbm_aoxk1dpySad3uUT4yHO5mJSov3IGGlMLDuoCdKv_N9rIYD5T_npqbATiBFziRPfKSJUovxqDCh0L0jApPl3wmSdAaUgC.kHl6_.P._VKCrHhdM.zKzeN3KfP7lrfVQ480UaiROp7Hgyx6o39N7_wG0eYvzgiQiXPo0- Received: from [85.115.136.164] by web34506.mail.mud.yahoo.com via HTTP; Mon, 09 Feb 2009 08:43:40 PST X-Mailer: YahooMailRC/1156.82 YahooMailWebService/0.7.260.1 Date: Mon, 9 Feb 2009 08:43:40 -0800 (PST) From: Martin Mielke X-ASG-Orig-Subj: Accesing data on (old) XFS devices Subject: Accesing data on (old) XFS devices To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <54506.39868.qm@web34506.mail.mud.yahoo.com> X-Barracuda-Connect: web34506.mail.mud.yahoo.com[66.163.178.172] X-Barracuda-Start-Time: 1234197821 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0008 1.0000 -2.0157 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.17387 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 all, I have 2 SCSI disks which were used on an (old) Silicon Graphics running on IRIX 6.5.x I need to recover the data from those disks, dump them somewhere else and forget about the SGI disks... OpenSUSE 11 sees the devices correctly and with fdisk I can see the partitions: -- # fdisk -l /dev/sda Disk /dev/sda (SGI disk label): 255 heads, 63 sectors, 4865 cylinders Units = cylinders of 16065 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 1: /dev/sda1 boot 66 2213 34510368 a SGI xfs 2: /dev/sda2 swap 1 65 1048576 3 SGI raw 9: /dev/sda3 0 0 4096 0 SGI volhdr 11: /dev/sda4 0 2213 35563040 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sash sector 2 size 273408 1: ide sector 536 size 249856 2: symmon sector 1024 size 1113600 # fdisk -l /dev/sdd Disk /dev/sdd (SGI disk label): 255 heads, 63 sectors, 9729 cylinders Units = cylinders of 16065 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 3: /dev/sdd1 1 16 262144 3 SGI raw 4: /dev/sdd2 17 32 262144 3 SGI raw 5: /dev/sdd3 33 293 4194304 3 SGI raw 6: /dev/sdd4 294 555 4194304 3 SGI raw 7: /dev/sdd5 556 816 4194304 3 SGI raw 8: /dev/sdd6 817 1077 4194304 3 SGI raw 9: /dev/sdd7 0 0 4096 0 SGI volhdr 11: /dev/sdd8 0 2213 35563040 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- -- I added the following to /etc/raw: -- raw1:sdd1 raw2:sdd2 raw3:sdd3 raw4:sdd4 raw5:sdd5 raw6:sdd6 -- ...but then I get this error: -- # /etc/init.d/raw start bind /dev/raw/raw1 to /dev/sdd1... failed bind /dev/raw/raw2 to /dev/sdd2... failed bind /dev/raw/raw3 to /dev/sdd3... failed bind /dev/raw/raw4 to /dev/sdd4... failed bind /dev/raw/raw5 to /dev/sdd5... failed bind /dev/raw/raw6 to /dev/sdd6... failed -- Later on I found this thread: http://oss.sgi.com/archives/xfs/2005-11/msg00376.html and this FAQ: http://linux.math.tifr.res.in/programming-doc/xfs/faq.html#xfsmountfail when I run xfs_repair -n /dev/sda or /dev/sdd (-n = no modify mode) it yields the following message: -- Sorry, could not find valid secondary superblock Exiting now. -- So... my questions are: how destructive can a xfs_repair be in terms of destroying all the data (disk image is already made) be? and is there any way to access those devices?? I first asked this questions on the SuSE lists and I've been redirected here ;-) TIA, Martin From sandeen@sandeen.net Mon Feb 9 11:09: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.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 n19H9GTm258636 for ; Mon, 9 Feb 2009 11:09:16 -0600 X-ASG-Debug-ID: 1234199318-2743020e0000-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 AC181FF5D3 for ; Mon, 9 Feb 2009 09:08:38 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id mEtYXFhdoLONsVwF for ; Mon, 09 Feb 2009 09:08:38 -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 n19H8brx005662; Mon, 9 Feb 2009 12:08:37 -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 n19H8bsl009971; Mon, 9 Feb 2009 12:08:37 -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 n19H8arH005987; Mon, 9 Feb 2009 12:08:37 -0500 Message-ID: <49906313.9060501@sandeen.net> Date: Mon, 09 Feb 2009 11:08:35 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Martin Mielke CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Accesing data on (old) XFS devices Subject: Re: Accesing data on (old) XFS devices References: <54506.39868.qm@web34506.mail.mud.yahoo.com> In-Reply-To: <54506.39868.qm@web34506.mail.mud.yahoo.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: 1234199319 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.17389 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 Martin Mielke wrote: > Hi all, > > I have 2 SCSI disks which were used on an (old) Silicon Graphics running on IRIX 6.5.x > I need to recover the data from those disks, dump them somewhere else and forget about the SGI disks... > > OpenSUSE 11 sees the devices correctly and with fdisk I can see the partitions: > > -- > # fdisk -l /dev/sda > > Disk /dev/sda (SGI disk label): 255 heads, 63 sectors, 4865 cylinders > Units = cylinders of 16065 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 1: /dev/sda1 boot 66 2213 34510368 a SGI xfs > 2: /dev/sda2 swap 1 65 1048576 3 SGI raw > 9: /dev/sda3 0 0 4096 0 SGI volhdr > 11: /dev/sda4 0 2213 35563040 6 SGI volume > ----- Bootinfo ----- > Bootfile: /unix > ----- Directory Entries ----- > 0: sash sector 2 size 273408 > 1: ide sector 536 size 249856 > 2: symmon sector 1024 size 1113600 > > > # fdisk -l /dev/sdd > > Disk /dev/sdd (SGI disk label): 255 heads, 63 sectors, 9729 cylinders > Units = cylinders of 16065 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 3: /dev/sdd1 1 16 262144 3 SGI raw > 4: /dev/sdd2 17 32 262144 3 SGI raw > 5: /dev/sdd3 33 293 4194304 3 SGI raw > 6: /dev/sdd4 294 555 4194304 3 SGI raw > 7: /dev/sdd5 556 816 4194304 3 SGI raw > 8: /dev/sdd6 817 1077 4194304 3 SGI raw > 9: /dev/sdd7 0 0 4096 0 SGI volhdr > 11: /dev/sdd8 0 2213 35563040 6 SGI volume > ----- Bootinfo ----- > Bootfile: /unix > ----- Directory Entries ----- > > -- > > I added the following to /etc/raw: > -- > raw1:sdd1 > raw2:sdd2 > raw3:sdd3 > raw4:sdd4 > raw5:sdd5 > raw6:sdd6 > -- You shouldn't need to play games w/ raw devices, I think. I'd try: # file -s /dev/sdd? # file -s /dev/sda? and see which partitions claim to hold xfs filesystems (I can't recall offhand how the sgi partitioning works...) Those *should* just mount right up. If they have dirty irix-format logs, you'll need to either mount (to replay the log) & unmount cleanly under irix, or zap it with xfs_repair -L -Eric From mkl@pengutronix.de Mon Feb 9 11:39:35 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 n19HdYs7259800 for ; Mon, 9 Feb 2009 11:39:35 -0600 X-ASG-Debug-ID: 1234201135-031f03040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from metis.ext.pengutronix.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9795118F7BA4 for ; Mon, 9 Feb 2009 09:38:56 -0800 (PST) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [92.198.50.35]) by cuda.sgi.com with ESMTP id uBavEepZOENykVVz for ; Mon, 09 Feb 2009 09:38:56 -0800 (PST) Received: from themisto.ext.pengutronix.de ([92.198.50.58] helo=[127.0.0.1]) by metis.ext.pengutronix.de with esmtp (Exim 4.63) (envelope-from ) id 1LWa5r-0006fH-MT for xfs@oss.sgi.com; Mon, 09 Feb 2009 18:38:54 +0100 Message-ID: <49906A23.2010504@pengutronix.de> Date: Mon, 09 Feb 2009 18:38:43 +0100 From: Marc Kleine-Budde Organization: Pengutronix User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: xfs@oss.sgi.com X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7478F03FDF2667322631E678" X-SA-Exim-Connect-IP: 92.198.50.58 X-SA-Exim-Mail-From: mkl@pengutronix.de X-ASG-Orig-Subj: download of attr_2.4.43-1.tar.gz Subject: download of attr_2.4.43-1.tar.gz X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on metis.ext.pengutronix.de) X-PTX-Original-Recipient: xfs@oss.sgi.com X-Barracuda-Connect: metis.ext.pengutronix.de[92.198.50.35] X-Barracuda-Start-Time: 1234201136 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.17391 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7478F03FDF2667322631E678 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, is ftp://oss.sgi.com/projects/xfs/cmd_tars/ still the valid download location for the "attr" package? The permissions on the ftp server on ftp://oss.sgi.com/projects/xfs/cmd_tars/ are mixed up, so that download isn't possible anymore. ncftp /projects/xfs/cmd_tars > pwd ftp://oss.sgi.com/projects/xfs/cmd_tars/ ncftp /projects/xfs/cmd_tars > dir attr_2.4.43-1.tar.gz -rw-rw---- 116991 Jul 3 2008 attr_2.4.43-1.tar.gz ncftp /projects/xfs/cmd_tars > get attr_2.4.43-1.tar.gz get attr_2.4.43-1.tar.gz: server said: Can't open attr_2.4.43-1.tar.gz: P= ermission denied cheers, Marc --=20 Pengutronix e.K. | Marc Kleine-Budde | Linux Solutions for Science and Industry | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | --------------enig7478F03FDF2667322631E678 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmQaisACgkQjTAFq1RaXHMkEACeKnj3FnbKcbN8CfiM3XgvQ91w tXYAn2B9bAen3e/zZgzs+53eFuuiluz/ =jm49 -----END PGP SIGNATURE----- --------------enig7478F03FDF2667322631E678-- From felixb@oss.sgi.com Mon Feb 9 11:55:10 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 n19HtA6E260724 for ; Mon, 9 Feb 2009 11:55:10 -0600 Received: (from felixb@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id n19Ht7wX260658; Mon, 9 Feb 2009 11:55:07 -0600 Date: Mon, 9 Feb 2009 11:55:07 -0600 Message-Id: <200902091755.n19Ht7wX260658@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-12809-g8e08f6e X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 9483c89eae58bee79b0280c625ca35a7b78fa300 X-Git-Newrev: 8e08f6eb34af13b78d379a025e4c9f8612b47b95 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 fcafb71 xfs: get rid of indirections in the quotaops implementation c9a192d xfs: sanitize qh_lock wrappers 7201813 xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED e249458 xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE 517b5e8 xfs: merge xfs_mkdir into xfs_create a568778 xfs: remove uchar_t/ushort_t/uint_t/ulong_t types 0d87e65 xfs: remove superflous inobt macros 7153f8b xfs: remove iclog calculation special cases from 9483c89eae58bee79b0280c625ca35a7b78fa300 (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 fcafb71b57a039f2113b0321b3b5535fea3a0aca Author: Christoph Hellwig Date: Mon Feb 9 08:47:34 2009 +0100 xfs: get rid of indirections in the quotaops implementation Currently we call from the nicely abstracted linux quotaops into a ugly multiplexer just to split the calls out at the same boundary again. Rewrite the quota ops handling to remove that obfucation. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit c9a192dcf906a33f59c555924e7796a4b9454217 Author: Christoph Hellwig Date: Mon Feb 9 08:47:22 2009 +0100 xfs: sanitize qh_lock wrappers Get rid of various obsfucating wrappers for accessing the quota hash lock, we only keep the accessors for accessing the mplist and freelist locks as they encode a multi-level datastructure walk. But make sure all of them are defined in the same way as simple macros. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 7201813bf55cc06e6a7405831f63df96ee7842e7 Author: Christoph Hellwig Date: Mon Feb 9 08:39:24 2009 +0100 xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED Now that we have a helper to test if a mutex is held use it instead of our own little hacks. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit e249458220c9799fe94573abd341d29c83579671 Author: Christoph Hellwig Date: Mon Feb 9 08:38:39 2009 +0100 xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE Remove these macros which only obsfucated the code in rather nast ways. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 517b5e8c8516a25a0df3b530fd183eb493a96698 Author: Christoph Hellwig Date: Mon Feb 9 08:38:02 2009 +0100 xfs: merge xfs_mkdir into xfs_create xfs_create and xfs_mkdir only have minor differences, so merge both of them into a sigle function. While we're at it also make the error handling code more straight-forward. Signed-off-by: Christoph Hellwig Dave Chinner commit a568778739030fb68805dda1af2f4ebbc3adad7d Author: Christoph Hellwig Date: Mon Feb 9 08:37:39 2009 +0100 xfs: remove uchar_t/ushort_t/uint_t/ulong_t types Just another set of types obsfucating the code, remove them. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 0d87e656dd961145f47ede5e37eceecfdc7d8197 Author: Christoph Hellwig Date: Mon Feb 9 08:37:14 2009 +0100 xfs: remove superflous inobt macros xfs_ialloc_btree.h has a a cuple of macros that only obsfucate the code but don't provide any abstraction benefits. This patches removes those and cleans up the reamaining defintions up a little. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner commit 7153f8ba2b18f18f661d5cb172782bcae2eadce9 Author: Christoph Hellwig Date: Mon Feb 9 08:36:46 2009 +0100 xfs: remove iclog calculation special cases Our default has been to always use 8 32KB log buffers for a while now, so remove the special casing for larger block size filesystem to use the same or even lower number of buffers. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner ----------------------------------------------------------------------- Summary of changes: fs/xfs/Makefile | 1 + fs/xfs/linux-2.6/xfs_iops.c | 30 +--- fs/xfs/linux-2.6/xfs_linux.h | 11 -- fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++++ fs/xfs/linux-2.6/xfs_super.c | 64 +------- fs/xfs/linux-2.6/xfs_super.h | 1 + fs/xfs/linux-2.6/xfs_sync.h | 1 + fs/xfs/quota/xfs_dquot.c | 28 ++-- fs/xfs/quota/xfs_dquot.h | 14 +-- fs/xfs/quota/xfs_qm.c | 62 ++------ fs/xfs/quota/xfs_qm.h | 20 +- fs/xfs/quota/xfs_qm_bhv.c | 1 - fs/xfs/quota/xfs_qm_syscalls.c | 188 +-------------------- fs/xfs/quota/xfs_quota_priv.h | 38 ++--- fs/xfs/xfs_ag.h | 4 +- fs/xfs/xfs_da_btree.c | 2 +- fs/xfs/xfs_da_btree.h | 6 +- fs/xfs/xfs_ialloc.c | 10 +- fs/xfs/xfs_ialloc_btree.h | 22 +-- fs/xfs/xfs_log.c | 28 +--- fs/xfs/xfs_log_priv.h | 2 +- fs/xfs/xfs_log_recover.c | 4 +- fs/xfs/xfs_mount.h | 6 +- fs/xfs/xfs_qmops.c | 1 - fs/xfs/xfs_quota.h | 2 + fs/xfs/xfs_trans.h | 12 +- fs/xfs/xfs_trans_space.h | 2 +- fs/xfs/xfs_types.h | 8 - fs/xfs/xfs_vnodeops.c | 351 +++++++++----------------------------- fs/xfs/xfs_vnodeops.h | 2 - 30 files changed, 345 insertions(+), 733 deletions(-) create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c hooks/post-receive -- XFS development tree From SRS0+baec9931e3585034ca2c+1996+infradead.org+hch@bombadil.srs.infradead.org Mon Feb 9 12:13: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.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 n19IDZFP261311 for ; Mon, 9 Feb 2009 12:13:36 -0600 X-ASG-Debug-ID: 1234203179-030a01ce0000-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 78362FFD3B for ; Mon, 9 Feb 2009 10:12:59 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id yvOdvfKEKvPmNCJO for ; Mon, 09 Feb 2009 10:12:59 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWacr-0004tf-8j; Mon, 09 Feb 2009 18:12:57 +0000 Date: Mon, 9 Feb 2009 13:12:57 -0500 From: Christoph Hellwig To: Andreas Gruenbacher Cc: Brandon Philips , Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Message-ID: <20090209181257.GA18112@infradead.org> References: <20090108021947.404730068@ifup.org> <20090108165820.GA3832@jenkins> <20090207091033.GO29636@jenkins.ifup.org> <200902090000.00162.agruen@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902090000.00162.agruen@suse.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234203179 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 08, 2009 at 11:59:59PM +0100, Andreas Gruenbacher wrote: > > > > http://ifup.org/git/?p=acl-attr-dev.git;a=summary > > git clone git://ifup.org/philips/acl-attr-dev.git > > > > What do you think? > > I believe it's a good start; we probably want to merge the trees eventually. > The way how you have moved libmisc breaks the tarballs though; I have fixed > it. Also, I was surprised that your repository has all the history rewritten > instead of merging Christoph's trees, so I redid the merge. I think the merge is a bad idea. attr and acl serve quite different purposes and have been different source and binary packages in distros forever. I'd rather keep it as it was for now and maybe find some way libacl could pick up libmisc from libattr. There's a reason we split up xfs-cmds into more manageable repositories. From sandeen@sandeen.net Mon Feb 9 12:47: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.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 n19Ilwqi001042 for ; Mon, 9 Feb 2009 12:47:58 -0600 X-ASG-Debug-ID: 1234205239-5b0400d80000-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 A2F3618F8A63 for ; Mon, 9 Feb 2009 10:47:20 -0800 (PST) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by cuda.sgi.com with ESMTP id HEe7RezpC8CVQxtO for ; Mon, 09 Feb 2009 10:47:20 -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 n19HnleQ014499; Mon, 9 Feb 2009 12:49:47 -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 n19Hnl6D020480; Mon, 9 Feb 2009 12:49:47 -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 n19HnaX8017677; Mon, 9 Feb 2009 12:49:36 -0500 Message-ID: <49906CAE.60209@sandeen.net> Date: Mon, 09 Feb 2009 11:49:34 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Marc Kleine-Budde CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: download of attr_2.4.43-1.tar.gz Subject: Re: download of attr_2.4.43-1.tar.gz References: <49906A23.2010504@pengutronix.de> In-Reply-To: <49906A23.2010504@pengutronix.de> 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: 1234205241 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.17395 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 Marc Kleine-Budde wrote: > Hello, > > is ftp://oss.sgi.com/projects/xfs/cmd_tars/ still the valid download > location for the "attr" package? > > The permissions on the ftp server on > ftp://oss.sgi.com/projects/xfs/cmd_tars/ are mixed up, so that download > isn't possible anymore. > > ncftp /projects/xfs/cmd_tars > pwd > ftp://oss.sgi.com/projects/xfs/cmd_tars/ > ncftp /projects/xfs/cmd_tars > dir attr_2.4.43-1.tar.gz > -rw-rw---- 116991 Jul 3 2008 attr_2.4.43-1.tar.gz > ncftp /projects/xfs/cmd_tars > get attr_2.4.43-1.tar.gz > get attr_2.4.43-1.tar.gz: server said: Can't open attr_2.4.43-1.tar.gz: Permission denied > > cheers, Marc Should be fixed up now, sorry for the trouble! -Eric From agruen@suse.de Mon Feb 9 13:07:58 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.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 n19J7vmJ002018 for ; Mon, 9 Feb 2009 13:07:57 -0600 X-ASG-Debug-ID: 1234206439-3f6f018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1F03100372 for ; Mon, 9 Feb 2009 11:07:20 -0800 (PST) Received: from mx1.suse.de (mail.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id tUWFLEbtbvW1aJIJ for ; Mon, 09 Feb 2009 11:07:20 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6052044968; Mon, 9 Feb 2009 20:07:19 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: Christoph Hellwig X-ASG-Orig-Subj: Re: [patch 0/4] attr: test/ improvements and integrate with make Subject: Re: [patch 0/4] attr: test/ improvements and integrate with make Date: Mon, 9 Feb 2009 20:06:47 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-4-pae; KDE/4.1.3; i686; ; ) Cc: Brandon Philips , xfs@oss.sgi.com References: <20090108021947.404730068@ifup.org> <200902090000.00162.agruen@suse.de> <20090209181257.GA18112@infradead.org> In-Reply-To: <20090209181257.GA18112@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902092006.48035.agruen@suse.de> X-Barracuda-Connect: mail.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1234206440 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 Monday 09 February 2009 19:12:57 Christoph Hellwig wrote: > [...] maybe find some way libacl could pick up libmisc from libattr. Yes, that might work. Thanks, Andreas From brandon@ifup.org Mon Feb 9 13:19: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 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 n19JJ5jW002839 for ; Mon, 9 Feb 2009 13:19:05 -0600 X-ASG-Debug-ID: 1234207107-3f70018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A0FA3100466 for ; Mon, 9 Feb 2009 11:18:27 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by cuda.sgi.com with ESMTP id 7w6ACRyrFgJK89DU for ; Mon, 09 Feb 2009 11:18:27 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1145871waf.4 for ; Mon, 09 Feb 2009 11:18:27 -0800 (PST) Received: by 10.114.148.2 with SMTP id v2mr3884655wad.26.1234206627427; Mon, 09 Feb 2009 11:10:27 -0800 (PST) Received: from localhost (c-76-105-255-252.hsd1.or.comcast.net [76.105.255.252]) by mx.google.com with ESMTPS id m28sm11501816poh.25.2009.02.09.11.10.26 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Feb 2009 11:10:26 -0800 (PST) Date: Mon, 9 Feb 2009 11:09:50 -0800 From: Brandon Philips To: Christoph Hellwig Cc: Andreas Gruenbacher , xfs@oss.sgi.com X-ASG-Orig-Subj: merging acl-dev and attr-dev [was: Re: [patch 0/4] attr: test/ improvements and integrate with make] Subject: merging acl-dev and attr-dev [was: Re: [patch 0/4] attr: test/ improvements and integrate with make] Message-ID: <20090209190950.GF21254@jenkins.ifup.org> References: <20090108021947.404730068@ifup.org> <20090108165820.GA3832@jenkins> <20090207091033.GO29636@jenkins.ifup.org> <200902090000.00162.agruen@suse.de> <20090209181257.GA18112@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090209181257.GA18112@infradead.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.176] X-Barracuda-Start-Time: 1234207108 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.17397 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 13:12 Mon 09 Feb 2009, Christoph Hellwig wrote: > On Sun, Feb 08, 2009 at 11:59:59PM +0100, Andreas Gruenbacher wrote: > > > > > > http://ifup.org/git/?p=acl-attr-dev.git;a=summary > > > git clone git://ifup.org/philips/acl-attr-dev.git > > > > > > What do you think? > > > > I believe it's a good start; we probably want to merge the trees eventually. > > The way how you have moved libmisc breaks the tarballs though; I have fixed > > it. Also, I was surprised that your repository has all the history rewritten > > instead of merging Christoph's trees, so I redid the merge. > > I think the merge is a bad idea. attr and acl serve quite > different purposes and have been different source and binary packages in > distros forever. They can remain different binary packages after merging the source code repos to share libmisc. > I'd rather keep it as it was for now and maybe find > some way libacl could pick up libmisc from libattr. > > There's a reason we split up xfs-cmds into more manageable > repositories. What was the reason for splitting these two packages from each other? >From looking at the shortlogs it looks like a lot of the bug fixes are made against attr then copied over to acl: http://ifup.org/git/?p=acl-attr-dev.git;a=shortlog > I'd rather keep it as it was for now and maybe find > some way libacl could pick up libmisc from libattr. Perhaps. Although, it doesn't seem right making walk_tree or the quoting code available to applications through libacl. Cheers, Brandon From me@localhost.com Mon Feb 9 15:50:44 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=BAYES_50,SUBJ_ALL_CAPS 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 n19LohKs010027 for ; Mon, 9 Feb 2009 15:50:43 -0600 X-ASG-Debug-ID: 1234216188-476c00400000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtpsmart3.aruba.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id A99DB100FCD for ; Mon, 9 Feb 2009 13:49:48 -0800 (PST) Received: from smtpsmart3.aruba.it (smtpweb101.aruba.it [62.149.158.101]) by cuda.sgi.com with SMTP id UAWOT8sTcU8e6qXY for ; Mon, 09 Feb 2009 13:49:48 -0800 (PST) Received: (qmail 20705 invoked by uid 89); 9 Feb 2009 21:43:04 -0000 Received: by simscan 1.2.0 ppid: 16242, pid: 20328, t: 4.9286s scanners: clamav: 0.88.4/m:40/d:1945 spam: 3.1.4 Received: from unknown (HELO webs235.aruba.it) (62.149.130.245) by smtpsmart3.fe.aruba.it with SMTP; 9 Feb 2009 21:42:59 -0000 Received: from WEBS235 ([127.0.0.1]) by webs235.aruba.it with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 22:42:16 +0100 Date: Mon, 09 Feb 2009 22:42:16 +0100 X-ASG-Orig-Subj: HOTEL TOURIST PROJECT.... Subject: HOTEL TOURIST PROJECT.... To: linux-xfs@oss.sgi.com From: GOVERNOR SIR EVERLYN BARING Reply-To: sir.e.b.gov1@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-ID: X-OriginalArrivalTime: 09 Feb 2009 21:42:16.0119 (UTC) FILETIME=[46851470:01C98AFF] X-Barracuda-Connect: smtpweb101.aruba.it[62.149.158.101] X-Barracuda-Start-Time: 1234216189 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6956 1.0000 1.3360 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.34 X-Barracuda-Spam-Status: No, SCORE=1.34 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ADVANCE_FEE_1 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.17405 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 ADVANCE_FEE_1 Appears to be advance fee fraud (Nigerian 419) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Good day, I am looking for your cooperation in building a Tourist Hotel or Real Estate in your country. I am sorry if this is not in line with your business. I need an experienced person like you to assist me to set up, develop the project. On the resumption of the project, you will be made a Director for the role and the assistance you rendered. You will also be entitled to a percentage agreed upon between me (Sir.E.B.Governor) and you before the commencement of the project. However, I got your email information on your Hotel contact list. Your immediate reply will be highly appreciated and I shall give you more information on this project. Please contact me at my private. e-mail address sir.e.b.gov1@gmail.com Thanks and God bless. Sir Everlyn Baring Declared Governor From lachlan@sgi.com Mon Feb 9 19:23:41 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 (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 n1A1NeMF019069 for ; Mon, 9 Feb 2009 19:23:41 -0600 Received: from [134.14.52.238] (unknown [134.14.52.238]) by relay1.corp.sgi.com (Postfix) with ESMTP id 47C558F80DE for ; Mon, 9 Feb 2009 17:23:00 -0800 (PST) Message-ID: <4990D7EA.7020902@sgi.com> Date: Tue, 10 Feb 2009 12:27:06 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] Check if AIL has been started before stopping it 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 A failure during mount can result in shutting down the AIL when it may not have been started up yet. Index: xfs-patch/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- xfs-patch.orig/fs/xfs/linux-2.6/xfs_super.c +++ xfs-patch/fs/xfs/linux-2.6/xfs_super.c @@ -913,7 +913,8 @@ void xfsaild_stop( struct xfs_ail *ailp) { - kthread_stop(ailp->xa_task); + if (ailp->xa_task) + kthread_stop(ailp->xa_task); } Index: xfs-patch/fs/xfs/xfs_trans_ail.c =================================================================== --- xfs-patch.orig/fs/xfs/xfs_trans_ail.c +++ xfs-patch/fs/xfs/xfs_trans_ail.c @@ -598,8 +598,10 @@ xfs_trans_ail_destroy( { struct xfs_ail *ailp = mp->m_ail; - xfsaild_stop(ailp); - kmem_free(ailp); + if (ailp) { + xfsaild_stop(ailp); + kmem_free(ailp); + } } /* From lachlan@sgi.com Mon Feb 9 19:49: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 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 n1A1nq9U020193 for ; Mon, 9 Feb 2009 19:49:53 -0600 Received: from [134.14.52.238] (unknown [134.14.52.238]) by relay3.corp.sgi.com (Postfix) with ESMTP id C05CAAC07C for ; Mon, 9 Feb 2009 17:49:12 -0800 (PST) Message-ID: <4990DCF6.5000900@sgi.com> Date: Tue, 10 Feb 2009 12:48:38 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH] Re-dirty pages on I/O error 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 [This patch seems to have slipped through the proverbial crack.] If we get an error in xfs_page_state_convert() - and it's not EAGAIN - then we throw away the dirty page without converting the delayed allocation. This leaves delayed allocations that can never be removed and confuses code that expects a flush of the file to clear them. We need to re-dirty the page on error so we can try again later or report that the flush failed. Index: xfs-fixes/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs-fixes.orig/fs/xfs/linux-2.6/xfs_aops.c +++ xfs-fixes/fs/xfs/linux-2.6/xfs_aops.c @@ -1185,16 +1185,6 @@ error: if (iohead) xfs_cancel_ioend(iohead); - /* - * If it's delalloc and we have nowhere to put it, - * throw it away, unless the lower layers told - * us to try again. - */ - if (err != -EAGAIN) { - if (!unmapped) - block_invalidatepage(page, 0); - ClearPageUptodate(page); - } return err; } @@ -1223,7 +1213,7 @@ xfs_vm_writepage( struct page *page, struct writeback_control *wbc) { - int error; + int error = 0; int need_trans; int delalloc, unmapped, unwritten; struct inode *inode = page->mapping->host; @@ -1269,19 +1259,16 @@ xfs_vm_writepage( * to real space and flush out to disk. */ error = xfs_page_state_convert(inode, page, wbc, 1, unmapped); - if (error == -EAGAIN) - goto out_fail; if (unlikely(error < 0)) - goto out_unlock; + goto out_fail; return 0; out_fail: redirty_page_for_writepage(wbc, page); unlock_page(page); - return 0; -out_unlock: - unlock_page(page); + if (error == -EAGAIN) + error = 0; return error; } From lachlan@sgi.com Mon Feb 9 20:49: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44 autolearn=no 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 n1A2n0Zs023102 for ; Mon, 9 Feb 2009 20:49:00 -0600 Received: from [134.14.52.238] (unknown [134.14.52.238]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7E2F5AC30D for ; Mon, 9 Feb 2009 18:48:20 -0800 (PST) Message-ID: <4990EAF9.9010607@sgi.com> Date: Tue, 10 Feb 2009 13:48:25 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH] Prevent lookup from finding bad buffers 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 There's a bug in _xfs_buf_find() that will cause it to return buffers that failed to be initialised. If a thread has a buffer locked and is waiting for I/O to initialise it and another thread wants the same buffer the second thread will wait on the buffer lock in _xfs_buf_find(). If the initial thread gets an I/O error it marks the buffer in error and releases the buffer lock. The second thread gets the buffer lock, assumes the buffer has been successfully initialised, and then tries to use it. Some callers of xfs_buf_get_flags() will check for B_DONE, and if it's not set then re-issue the I/O, bust most callers assume the buffer and it's contents are good and then use the uninitialised data. The solution I've come up with is if we lookup a buffer and find it's got b_error set or has been marked stale then unhash it from the buffer hashtable and retry the lookup. Also if we fail to setup the buffer correctly in xfs_buf_get_flags() then mark the buffer in error and unhash it. If the buffer is marked stale then in xfs_buf_free() inform the page cache that the contents of the pages are no longer valid. Index: xfs-patch/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- xfs-patch.orig/fs/xfs/linux-2.6/xfs_buf.c +++ xfs-patch/fs/xfs/linux-2.6/xfs_buf.c @@ -271,6 +271,8 @@ xfs_buf_free( if (bp->b_flags & _XBF_PAGE_CACHE) ASSERT(!PagePrivate(page)); + if (XFS_BUF_ISSTALE(bp)) + ClearPageUptodate(page); page_cache_release(page); } _xfs_buf_free_pages(bp); @@ -430,7 +432,7 @@ _xfs_buf_find( ASSERT(!(range_base & (xfs_off_t)btp->bt_smask)); hash = &btp->bt_hash[hash_long((unsigned long)ioff, btp->bt_hashshift)]; - +retry: spin_lock(&hash->bh_lock); list_for_each_entry_safe(bp, n, &hash->bh_list, b_hash_list) { @@ -489,9 +491,12 @@ found: XB_SET_OWNER(bp); } - if (bp->b_flags & XBF_STALE) { + if (bp->b_error || XFS_BUF_ISSTALE(bp)) { ASSERT((bp->b_flags & _XBF_DELWRI_Q) == 0); - bp->b_flags &= XBF_MAPPED; + xfs_buf_unhash(bp); + xfs_buf_unlock(bp); + xfs_buf_rele(bp); + goto retry; } XB_TRACE(bp, "got_lock", 0); XFS_STATS_INC(xb_get_locked); @@ -553,6 +558,10 @@ xfs_buf_get_flags( return bp; no_buffer: + if (error) { + xfs_buf_ioerror(bp, -error); + xfs_buf_unhash(bp); + } if (flags & (XBF_LOCK | XBF_TRYLOCK)) xfs_buf_unlock(bp); xfs_buf_rele(bp); @@ -771,6 +780,20 @@ xfs_buf_hold( XB_TRACE(bp, "hold", 0); } +void +xfs_buf_unhash( + xfs_buf_t *bp) +{ + xfs_bufhash_t *hash = bp->b_hash; + + if (hash) { + spin_lock(&hash->bh_lock); + bp->b_hash = 0; + list_del_init(&bp->b_hash_list); + spin_unlock(&hash->bh_lock); + } +} + /* * Releases a hold on the specified buffer. If the * the hold count is 1, calls xfs_buf_free. Index: xfs-patch/fs/xfs/linux-2.6/xfs_buf.h =================================================================== --- xfs-patch.orig/fs/xfs/linux-2.6/xfs_buf.h +++ xfs-patch/fs/xfs/linux-2.6/xfs_buf.h @@ -206,6 +206,7 @@ extern void xfs_buf_readahead(xfs_buftar /* Releasing Buffers */ extern void xfs_buf_free(xfs_buf_t *); extern void xfs_buf_rele(xfs_buf_t *); +extern void xfs_buf_unhash(xfs_buf_t *); /* Locking and Unlocking Buffers */ extern int xfs_buf_cond_lock(xfs_buf_t *); From SRS0+4da8ea89c817d6ecb95d+1997+infradead.org+hch@bombadil.srs.infradead.org Tue Feb 10 01:56: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,UPPERCASE_50_75 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 n1A7u8Bw037447 for ; Tue, 10 Feb 2009 01:56:09 -0600 X-ASG-Debug-ID: 1234252527-0a3b003c0000-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 22A031906E47 for ; Mon, 9 Feb 2009 23:55:27 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ExWxqyA3TVQtvC5x for ; Mon, 09 Feb 2009 23:55:27 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1LWnSJ-00074I-Py; Tue, 10 Feb 2009 07:54:55 +0000 Date: Tue, 10 Feb 2009 02:54:55 -0500 From: Christoph Hellwig To: Nick Piggin Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: reproducible xfs/vmap oops Subject: Re: reproducible xfs/vmap oops Message-ID: <20090210075455.GA27111@infradead.org> References: <20090201081224.GA22398@infradead.org> <200902042027.40762.nickpiggin@yahoo.com.au> <20090204193846.GA26436@infradead.org> <200902101543.15988.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <200902101543.15988.nickpiggin@yahoo.com.au> User-Agent: Mutt/1.5.18 (2008-05-17) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1234252532 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 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 10, 2009 at 03:43:15PM +1100, Nick Piggin wrote: > I managed to get this to build (hacking out the DMAPI parts of the > make process), and ./check -g auto runs 32 tests for me. But no luck > with reproducing the problem so far. > > I just created and mounted default xfs filesystems. Do I need to > create ones with large directory block size or any special mount > options? My setup are two simple partitions around 10GB, no special mkfs options to trigger it. What might be important is that CONFIG_XFS_DEBUG and quite a few other _DEBUG options are one. My .config is attached. --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29-rc4 # Mon Feb 9 19:20:21 2009 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-xfs" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=y # CONFIG_OPROFILE_IBS is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLK_DEV_INTEGRITY=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_FREEZER is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_SPARSE_IRQ is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_VSMP is not set # CONFIG_X86_RDC321X is not set # CONFIG_SCHED_OMIT_FRAME_POINTER is not set CONFIG_PARAVIRT_GUEST=y # CONFIG_VMI is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y # CONFIG_LGUEST_GUEST is not set CONFIG_PARAVIRT=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_PARAVIRT_DEBUG is not set # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_GENERIC=y CONFIG_X86_CPU=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_X86_DEBUGCTLMSR=y # CONFIG_PROCESSOR_SELECT is not set CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_CYRIX_32=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR_32=y CONFIG_CPU_SUP_TRANSMETA_32=y CONFIG_CPU_SUP_UMC_32=y CONFIG_X86_DS=y CONFIG_X86_PTRACE_BTS=y CONFIG_HPET_TIMER=y CONFIG_DMI=y # CONFIG_IOMMU_HELPER is not set # CONFIG_IOMMU_API is not set CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_2G_OPT is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 # CONFIG_X86_PAE is not set # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y CONFIG_MMU_NOTIFIER=y # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW_64K=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 # CONFIG_X86_PAT is not set CONFIG_EFI=y CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y # CONFIG_CMDLINE_BOOL is not set # # Power management and ACPI options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SUSPEND is not set # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y # CONFIG_ACPI_PROC_EVENT is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=2000 # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_SBS=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=y # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_E_POWERSAVER is not set # # shared options # CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set # CONFIG_PCI_GOOLPC is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y # CONFIG_PCIEAER is not set # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_OLPC is not set CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=y # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_HAVE_AOUT=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y CONFIG_HAVE_ATOMIC_IOMAP=y CONFIG_NET=y # # Networking options # CONFIG_COMPAT_NET_DEV_OPS=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=y CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y # CONFIG_IP_ROUTE_MULTIPATH is not set # CONFIG_IP_ROUTE_VERBOSE is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET