From: Ming Lin <mlin@kernel.org>
To: Dave Chinner <david@fromorbit.com>, Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org,
Ceph Development <ceph-devel@vger.kernel.org>,
"LIU, Fei" <james.liu@alibaba-inc.com>,
xiongwei.jiang@alibaba-inc.com, boqian.zy@alibaba-inc.com,
sheng.qiu@alibaba-inc.com, Sage Weil <sweil@redhat.com>
Subject: Re: xlog_write: reservation ran out
Date: Fri, 28 Apr 2017 13:56:30 -0700 [thread overview]
Message-ID: <CAF1ivSbEfhTYxcBx1dafK9TD3VdeXbJrNMzWJmXY8kyU0ibkUw@mail.gmail.com> (raw)
In-Reply-To: <CAF1ivSbjdixqDo663wvAEkzRk-ctOX+y5UYxq4UdPA-=JVufyw@mail.gmail.com>
On Fri, Apr 28, 2017 at 1:24 PM, Ming Lin <mlin@kernel.org> wrote:
> - xfs@oss.sgi.com
> + linux-xfs@vger.kernel.org
>
> On Fri, Apr 28, 2017 at 1:15 PM, Ming Lin <mlin@kernel.org> wrote:
>> Hi Dave & Christoph,
>>
>> I run into below error during a pre-production ceph cluster test with
>> xfs backend.
>> Kernel version: CentOS 7.2 3.10.0-327.el7.x86_64
>>
>> [146702.392840] XFS (nvme9n1p1): xlog_write: reservation summary:
>> trans type = INACTIVE (3)
>> unit res = 83812 bytes
>> current res = -9380 bytes
>> total reg = 0 bytes (o/flow = 0 bytes)
>> ophdrs = 0 (ophdr space = 0 bytes)
>> ophdr + reg = 0 bytes
>> num regions = 0
>> [146702.428729] XFS (nvme9n1p1): xlog_write: reservation ran out. Need
>> to up reservation
>> [146702.436917] XFS (nvme9n1p1): xfs_do_force_shutdown(0x2) called
>> from line 2070 of file fs/xfs/xfs_log.c. Return address =
>> 0xffffffffa0651738
>> [146702.449969] XFS (nvme9n1p1): Log I/O Error Detected. Shutting
>> down filesystem
>> [146702.457590] XFS (nvme9n1p1): Please umount the filesystem and
>> rectify the problem(s)
>> [146702.467903] XFS (nvme9n1p1): xfs_log_force: error -5 returned.
>> [146732.324308] XFS (nvme9n1p1): xfs_log_force: error -5 returned.
>> [146762.436923] XFS (nvme9n1p1): xfs_log_force: error -5 returned.
>> [146792.549545] XFS (nvme9n1p1): xfs_log_force: error -5 returned.
>>
>> Each XFS fs is 1.7T.
>> The cluster was written about 80% full then we delete the ceph rbd
>> image, which actually delete a lot of files in the backend xfs.
>>
>> I'm going to have a try below quick hack and see if it helps.
>>
>> diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
>> index 1b754cb..b2702f5 100644
>> --- a/fs/xfs/libxfs/xfs_trans_resv.c
>> +++ b/fs/xfs/libxfs/xfs_trans_resv.c
>> @@ -800,7 +800,7 @@ xfs_trans_resv_calc(
>> resp->tr_link.tr_logcount = XFS_LINK_LOG_COUNT;
>> resp->tr_link.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
>>
>> - resp->tr_remove.tr_logres = xfs_calc_remove_reservation(mp);
>> + resp->tr_remove.tr_logres = xfs_calc_remove_reservation(mp) * 2;
>> resp->tr_remove.tr_logcount = XFS_REMOVE_LOG_COUNT;
>> resp->tr_remove.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
>>
+ Sage
I'm new to xfs code.
Search XFS_TRANS_INACTIVE and the usage is like below,
xfs_trans_alloc(mp, XFS_TRANS_INACTIVE);
xfs_trans_reserve(tp, &M_RES(mp)->tr_itruncate, 0, 0);
xfs_trans_alloc(mp, XFS_TRANS_INACTIVE);
xfs_trans_reserve(tp, &M_RES(mp)->tr_ifree, XFS_IFREE_SPACE_RES(mp), 0);
seems tr_remove is not related.
I'll just try to enlarge the reservation for tr_itruncate and tr_ifree.
diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
index 1b754cb..4087c39 100644
--- a/fs/xfs/libxfs/xfs_trans_resv.c
+++ b/fs/xfs/libxfs/xfs_trans_resv.c
@@ -788,7 +788,7 @@ xfs_trans_resv_calc(
resp->tr_write.tr_logcount = XFS_WRITE_LOG_COUNT;
resp->tr_write.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
- resp->tr_itruncate.tr_logres = xfs_calc_itruncate_reservation(mp);
+ resp->tr_itruncate.tr_logres = xfs_calc_itruncate_reservation(mp) * 2;
resp->tr_itruncate.tr_logcount = XFS_ITRUNCATE_LOG_COUNT;
resp->tr_itruncate.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
@@ -821,7 +821,7 @@ xfs_trans_resv_calc(
resp->tr_mkdir.tr_logcount = XFS_MKDIR_LOG_COUNT;
resp->tr_mkdir.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
- resp->tr_ifree.tr_logres = xfs_calc_ifree_reservation(mp);
+ resp->tr_ifree.tr_logres = xfs_calc_ifree_reservation(mp) * 2;
resp->tr_ifree.tr_logcount = XFS_INACTIVE_LOG_COUNT;
resp->tr_ifree.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
next prev parent reply other threads:[~2017-04-28 20:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 20:15 xlog_write: reservation ran out Ming Lin
2017-04-28 20:24 ` Ming Lin
2017-04-28 20:56 ` Ming Lin [this message]
2017-05-01 6:10 ` Ming Lin
2017-05-01 13:12 ` Brian Foster
2017-05-01 17:41 ` Ming Lin
2017-05-01 18:48 ` Brian Foster
2017-05-01 20:18 ` Ming Lin
2017-05-02 23:51 ` Dave Chinner
2017-05-03 14:10 ` Brian Foster
2017-05-03 15:53 ` Darrick J. Wong
2017-05-03 16:15 ` Brian Foster
2017-05-04 0:37 ` Dave Chinner
2017-05-04 0:34 ` Dave Chinner
2017-05-04 11:51 ` Brian Foster
2017-05-05 3:16 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAF1ivSbEfhTYxcBx1dafK9TD3VdeXbJrNMzWJmXY8kyU0ibkUw@mail.gmail.com \
--to=mlin@kernel.org \
--cc=boqian.zy@alibaba-inc.com \
--cc=ceph-devel@vger.kernel.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=james.liu@alibaba-inc.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sheng.qiu@alibaba-inc.com \
--cc=sweil@redhat.com \
--cc=xiongwei.jiang@alibaba-inc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.