From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D362A7CA2 for ; Thu, 31 Mar 2016 17:01:13 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8B29C304048 for ; Thu, 31 Mar 2016 15:01:10 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id A6ug4RrBKVyeViH9 for ; Thu, 31 Mar 2016 15:01:08 -0700 (PDT) Date: Fri, 1 Apr 2016 09:01:05 +1100 From: Dave Chinner Subject: Re: Internal error at xfs_trans_cancel Message-ID: <20160331220105.GQ11812@dastard> References: <56FD513B.40805@scylladb.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <56FD513B.40805@scylladb.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Avi Kivity Cc: xfs@oss.sgi.com On Thu, Mar 31, 2016 at 07:32:59PM +0300, Avi Kivity wrote: > Saw this nice gift this morning: > > [2121372.825904] XFS (dm-10): Internal error xfs_trans_cancel at > line 1007 of file fs/xfs/xfs_trans.c. Caller xfs_create+0x40e/0x710 > [xfs] > [2121372.827209] CPU: 0 PID: 32020 Comm: java Tainted: G W > ------------ 3.10.0-327.10.1.el7.x86_64 #1 > [2121372.828529] Hardware name: /DH77EB, BIOS > EBH7710H.86A.0099.2013.0125.1400 01/25/2013 > [2121372.829873] ffff8807b2b11e80 00000000470753cc ffff88031058bb48 > ffffffff816352cc > [2121372.831232] ffff88031058bb60 ffffffffa084be5b ffffffffa085b7ee > ffff88031058bb88 > [2121372.832542] ffffffffa0866909 ffff88014a2f3b80 ffff8807f29a2800 > 0000000000000000 > [2121372.833850] Call Trace: > [2121372.835125] [] dump_stack+0x19/0x1b > [2121372.836397] [] xfs_error_report+0x3b/0x40 [xfs] > [2121372.837654] [] ? xfs_create+0x40e/0x710 [xfs] > [2121372.838915] [] xfs_trans_cancel+0xd9/0x100 [xfs] > [2121372.840178] [] xfs_create+0x40e/0x710 [xfs] > [2121372.841444] [] xfs_vn_mknod+0xbb/0x250 [xfs] > [2121372.842683] [] xfs_vn_create+0x13/0x20 [xfs] > [2121372.843887] [] vfs_create+0xcd/0x130 > [2121372.845103] [] do_last+0xbef/0x1270 > [2121372.846324] [] path_openat+0xc2/0x490 > [2121372.847538] [] ? user_path_at_empty+0x72/0xc0 > [2121372.848746] [] do_filp_open+0x4b/0xb0 > [2121372.849917] [] ? __alloc_fd+0xa7/0x130 > [2121372.851090] [] do_sys_open+0xf3/0x1f0 > [2121372.852227] [] SyS_open+0x1e/0x20 > [2121372.853356] [] system_call_fastpath+0x16/0x1b > [2121372.854486] XFS (dm-10): xfs_do_force_shutdown(0x8) called from > line 1008 of file fs/xfs/xfs_trans.c. Return address = > 0xffffffffa0866922 > > Filesystem appeared full, ISTR there was a bug inthe inode allocation code that could lead to multiple AGFs being dirtied (via AGFL fixups) and then not having enough contiguous freee space to allocate a new inode chuck. I think it was also a potential deadlock vector. Yeah: e480a72 xfs: avoid AGI/AGF deadlock scenario for inode chunk allocation Fixed in 3.15. > but after a reboot (critical server) it > went back down to 420GB free. Lots of open unlinked (or O_TMPFILE) files, I'd guess. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs