From patchwork Tue Apr 12 16:42:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 8813991 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1BEA3C0553 for ; Tue, 12 Apr 2016 18:22:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 120E020375 for ; Tue, 12 Apr 2016 18:22:16 +0000 (UTC) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 160BE202D1 for ; Tue, 12 Apr 2016 18:22:15 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u3CIJg1R026290; Tue, 12 Apr 2016 14:19:42 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u3CGgtcH005733 for ; Tue, 12 Apr 2016 12:42:55 -0400 Received: from bfoster.bfoster (dhcp-41-153.bos.redhat.com [10.18.41.153]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3CGgsYG012795; Tue, 12 Apr 2016 12:42:55 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 9764012547B; Tue, 12 Apr 2016 12:42:53 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Date: Tue, 12 Apr 2016 12:42:51 -0400 Message-Id: <1460479373-63317-9-git-send-email-bfoster@redhat.com> In-Reply-To: <1460479373-63317-1-git-send-email-bfoster@redhat.com> References: <1460479373-63317-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-loop: dm-devel@redhat.com X-Mailman-Approved-At: Tue, 12 Apr 2016 14:18:51 -0400 Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, dm-devel@redhat.com Subject: [dm-devel] [RFC v2 PATCH 08/10] xfs: handle bdev reservation ENOSPC correctly from XFS reserved pool X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The XFS reserved block pool holds blocks from general allocation for internal purposes. When enabled, these blocks shall also carry a reservation from the block device to guarantee they are usable. The reserved pool allocation code currently uses a retry algorithm based on the available space estimation. It assumes that an inability to allocate blocks based on the estimation is a transient problem. Now that block allocation attempts bdev reservation, however, an ENOSPC could originate from the block device and might not be transient. Because the retry algorithm cannot distinguish between fs block allocation and bdev reservation, separate the two operations in this particular case. If the bdev reservation fails, back off the reservation delta until something can be reserved or return ENOSPC to the caller. Once a bdev reservation is made, attempt to allocate blocks from the fs and return to the original retry algorithm based on the free space estimation. This prevents infinite retries in the event of a reserved pool allocation request that cannot be satisfied from a bdev that supports reservation. Signed-off-by: Brian Foster --- fs/xfs/xfs_fsops.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c index 87d4b1b..79ae408 100644 --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -40,6 +40,7 @@ #include "xfs_trace.h" #include "xfs_log.h" #include "xfs_filestream.h" +#include "xfs_thin.h" /* * File system operations @@ -676,6 +677,7 @@ xfs_reserve_blocks( __uint64_t request; __int64_t free; int error = 0; + sector_t res = 0; /* If inval is null, report current values and return */ if (inval == (__uint64_t *)NULL) { @@ -743,6 +745,28 @@ xfs_reserve_blocks( fdblks_delta = delta; /* + * Reserve pool blocks must carry a block device reservation (if + * enabled). The block device could be much closer to ENOSPC + * than the fs (i.e., a thin or snap device), so try to reserve + * the bdev space first. + */ + spin_unlock(&mp->m_sb_lock); + if (mp->m_thin_reserve) { + while (fdblks_delta) { + res = xfs_fsb_res(mp, fdblks_delta, false); + error = xfs_thin_reserve(mp, res); + if (error != -ENOSPC) + break; + + fdblks_delta >>= 1; + } + if (!fdblks_delta || error) { + spin_lock(&mp->m_sb_lock); + break; + } + } + + /* * We'll either succeed in getting space from the free block * count or we'll get an ENOSPC. If we get a ENOSPC, it means * things changed while we were calculating fdblks_delta and so @@ -752,8 +776,9 @@ xfs_reserve_blocks( * Don't set the reserved flag here - we don't want to reserve * the extra reserve blocks from the reserve..... */ - spin_unlock(&mp->m_sb_lock); - error = xfs_mod_fdblocks(mp, -fdblks_delta, 0); + error = __xfs_mod_fdblocks(mp, -fdblks_delta, 0); + if (error && mp->m_thin_reserve) + xfs_thin_unreserve(mp, res); spin_lock(&mp->m_sb_lock); }