From patchwork Thu Mar 14 21:28:54 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 10853695 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C285817E6 for ; Thu, 14 Mar 2019 21:28:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A0CD42A78B for ; Thu, 14 Mar 2019 21:28:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 931952A78E; Thu, 14 Mar 2019 21:28:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 37C252A78B for ; Thu, 14 Mar 2019 21:28:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727003AbfCNV25 (ORCPT ); Thu, 14 Mar 2019 17:28:57 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:47936 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726856AbfCNV24 (ORCPT ); Thu, 14 Mar 2019 17:28:56 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2ELStxI118195 for ; Thu, 14 Mar 2019 21:28:55 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-2018-07-02; bh=cWt42cHaaQBOsw/n3cZrLTROyQjOQu+3ffVQ9ISIBFU=; b=O7dBYNUM5wgplM7tTnEFPotbPlixtd9HKprAVJnz/h6QneL8adbKl1ydH87TW4QMd9uZ 3qbhn3UqZlYOjD9VSF2ozxKIiyc/fVaRWok3gKVSq1mJTHDw9dhiZQdsozKgXc/YBDpp j89ECpxu2CVKdpV38EqipL2+U7qu+dMO2HjyNpKCCGNyIMBNW3scSin06XDkwGEjTAd+ d1wfpLMOHZKaR6Fn1agSgJ8+lGZl2ifu3lwCt73II9AMdJtZG1FYcaOsL5FzcGA5eMy/ Ea9GjK/UMf1AIR1pdCJmY21kIpf6T+GlCu0l8oKeQPRcl8V5H3FJvXIymDhCNz+X8BZ6 Yw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2r44wukj8p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 14 Mar 2019 21:28:55 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2ELStp4006135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 14 Mar 2019 21:28:55 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x2ELSsOH031853 for ; Thu, 14 Mar 2019 21:28:54 GMT Received: from localhost (/10.145.178.102) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2019 21:28:54 +0000 Subject: [PATCH 0/4] xfs: various rough fixes From: "Darrick J. Wong" To: darrick.wong@oracle.com Cc: linux-xfs@vger.kernel.org Date: Thu, 14 Mar 2019 14:28:54 -0700 Message-ID: <155259893433.30230.6566995969675098053.stgit@magnolia> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9195 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=793 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903140145 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, Here's a bunch of crazy fixes that I've been working on. The first one tries to solve the fragmentation problems that Dave reported[1] in the stupidest way possible. Namely, we only ever trim post-eof speculative preallocations the /first/ time that we close a file, regardless of the dirty state. The second patch tries to fix a stale data exposure bug revealed by generic/042. It does this by changing xfs to convert delalloc extents to unwritten extents and only converting those into real extents once the data write succeeds. We already do this for the cow fork, so it seems pretty straightforward to do the same for the data fork. The third patch adds instrumentation to make it easier to detect when we roll a transaction beyond the initial logcount, and therefore are having to reserve more log space. The fourth patch effectively increases the number of times we can roll an end_cow transaction without having to go back for more reservation. This is intended to fix the problem outlined in [2] which will fix the periodic xfs/347 deadlocks. [1] https://marc.info/?l=linux-xfs&m=154951612101291&w=2 [2] https://marc.info/?l=linux-xfs&m=155241472431249&w=2 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=rough-fixes