Re: [PATCH] xfs: remove "no-allocation" reservations for file creations

[Dave Chinner <david@fromorbit.com>]

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 <some tiny amount> of space available and the
directory blocks weren't full:

commit f5029ed542697e8daf728b57d8fec0d9f1abc66c
Author: Doug Doucette <doucette@engr.sgi.com>
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 <doucette@engr.sgi.com>
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