From patchwork Wed Jan 1 01:07:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 11314667 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9566F109A for ; Wed, 1 Jan 2020 01:07:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7427520718 for ; Wed, 1 Jan 2020 01:07:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="JSztcUbn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727134AbgAABHT (ORCPT ); Tue, 31 Dec 2019 20:07:19 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:50924 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727133AbgAABHS (ORCPT ); Tue, 31 Dec 2019 20:07:18 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00115IlQ086713 for ; Wed, 1 Jan 2020 01:07:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : date : message-id : mime-version : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=m9llSfWvZMInDZGRMcymYi+yEnIkDvgoCDZH73sOKFg=; b=JSztcUbni7BSTO7nNZPyxcIIwyDQqIlanNU9ZamiPeWaqx3YLxzYBYqxJZZn9lLalgfW MQA3O2Eg9UxlB57J2Yuufm61jnsRkFRheXfW7vyrJeLr9mpQogKl4srO+YiOcc4KQWlH MbHDPNyg28KNxzjUeLhGPknshAD+sAT2tU5LIjFM+D684pyui5Gqlu6aRpXHAs6vdtJD 2Hjt3ahXuPwI0b+JROA0xavDSj92o0bgHn9aFD3JTknHMc+rsvJ1ii08hSeFa553KZ6C 7sXkabEGIjj653NWnVOcebtZN0hVTh8PKwrkQxo0mSzy6+osM/h0a3I0hzEiKjP4Ia4z YA== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2x5y0pjxs3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 01 Jan 2020 01:07:17 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00115FvB165849 for ; Wed, 1 Jan 2020 01:07:16 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2x8gj914wd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 01 Jan 2020 01:07:16 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 00117FUa005145 for ; Wed, 1 Jan 2020 01:07:15 GMT Received: from localhost (/10.159.150.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 31 Dec 2019 17:07:15 -0800 Subject: [PATCH v2 0/6] xfs: try harder to reclaim space when we run out From: "Darrick J. Wong" To: darrick.wong@oracle.com Cc: linux-xfs@vger.kernel.org Date: Tue, 31 Dec 2019 17:07:13 -0800 Message-ID: <157784083298.1361522.7064886067520069080.stgit@magnolia> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9487 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=756 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001010008 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9487 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=814 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001010008 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org Hi all, Historically, when users ran out of space or quota when trying to write to the filesystem, XFS didn't try very hard to reclaim space that it might have been hanging onto for the purpose of speeding up front-end filesystem operations (appending writes, cow staging). The upcoming deferred inactivation series will greatly increase the amount of allocated space that isn't actively being used to store user data. Therefore, try to reduce the circumstances where we return EDQUOT or ENOSPC to userspace by teaching the write paths to try to clear space and retry the operation one time before giving up. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This is an extraordinary way to destroy everything. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=reclaim-space-harder