From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:46588 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751003AbdHXAr6 (ORCPT ); Wed, 23 Aug 2017 20:47:58 -0400 Date: Thu, 24 Aug 2017 10:47:55 +1000 From: Dave Chinner Subject: Re: [PATCH] xfs: remove "no-allocation" reservations for file creations Message-ID: <20170824004755.GC21024@dastard> References: <20170821082404.3387-1-hch@lst.de> <20170823202213.GA4796@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170823202213.GA4796@magnolia> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: "Darrick J. Wong" Cc: Christoph Hellwig , linux-xfs@vger.kernel.org On Wed, Aug 23, 2017 at 01:22:13PM -0700, Darrick J. Wong wrote: > On Mon, Aug 21, 2017 at 10:24:04AM +0200, Christoph Hellwig wrote: > > If we create a new file we will need an inode, and usually some metadata > > in the parent direction. Aiming for everything to go well despite the > > lack of a reservation leads to dirty transactions cancelled under a heavy > > create/delete load. This patch removes those nospace transactions, which > > will lead to slightly earlier ENOSPC on some workloads, but instead > > prevent file system shutdowns due to cancelling dirty transactions for > > others. > > > > A customer could observe assertations failures and shutdowns due to > > cancelation of dirty transactions during heavy NFS workloads as shown > > below: > > Looks ok... but is there a xfstest somewhere that can be coaxed into > reproducing this? I'm looking at what this code does and have been > wondering why it even tries this weird workaround in the first place? Because back in 1997 SGI had a customer that didn't like getting ENOSPC being reported trying to rename file near ENOSPC when df said the filesystem had of space available and the directory blocks weren't full: commit f5029ed542697e8daf728b57d8fec0d9f1abc66c Author: Doug Doucette Date: Tue Jul 15 17:54:13 1997 +0000 Add xfs_dir_canenter to check for entering name in a directory with no space allocation. Initialize new da_arg field justcheck, use it in xfs_dir_node_addname. commit 9b9c81137b07d40d864e468cf3168f1b55d83c13 Author: Doug Doucette Date: Fri Jul 11 16:33:02 1997 +0000 Make xfs_dir_createname fail gracefully if the total argument is 0 and we actually need space. Same treatment for xfs_dir_node_addname. Part of making rename work sometimes with 0 space reservation. > IOWS, the weirdness removed by this patch didn't quite smell right, but > at the same time I want to know more about why the smelly weirdness was > there at all before I rip it out. Context, anyone? :) It's always been a crufty corner case. xfs_rename and xfs_remove need to be able to operate at ENOSPC where reservations may not be possible so they can free up space. However, create/symlink/link don't really need to work when so close to ENOSPC we can't get a reservation of a few blocks, so I don't see a huge problem with this. Cheers, Dave. -- Dave Chinner david@fromorbit.com