public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs: use per-AG reservations for the finobt
Date: Tue, 24 Jan 2017 12:05:05 -0800	[thread overview]
Message-ID: <20170124200505.GL4780@birch.djwong.org> (raw)
In-Reply-To: <20170124195050.GA1025@lst.de>

On Tue, Jan 24, 2017 at 08:50:50PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 24, 2017 at 08:48:37AM -0800, Darrick J. Wong wrote:
> > I'd just print out:
> > 
> > "Per-AG reservation for AG ${agno} failed.  Filesystem may run out of space."
> 
> Sure, I can do that.
> 
> > 
> > if any of the (now three) invocations of __xfs_ag_resv_init() returns
> > ENOSPC, since the AG is more than 98% full.  Some day, a sysadmin could
> > then use the fsmap data to identify which inodes are using the most
> > space in that AG and arrange to migrate/remove/etc the data to another
> > AG.
> 
> But for all but the reflink one this can't happen as the reservations
> have been there since the beginning.  And if they fail neverless we fail
> the mount.  Or am I missing something here?

The code I wrote doesn't fail the mount (or remount) on ENOSPC so that
it's still possible to delete files off the fs even when space is low.

In theory it wasn't possible to run out, but I've been thinking that
it's better to warn noisily just in case we /do/ run out of space later,
since it's not entirely obvious when the fs goes offline because we
tried to expand a btree and hit ENOSPC.

(Also if people perform underhanded "upgrades" then they can hit this
problem, but maybe that was just me. :P)

--D

  reply	other threads:[~2017-01-24 20:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-23 18:05 [PATCH v2] xfs: use per-AG reservations for the finobt Christoph Hellwig
2017-01-23 19:28 ` Darrick J. Wong
2017-01-24 14:02   ` Christoph Hellwig
2017-01-24 16:48     ` Darrick J. Wong
2017-01-24 19:50       ` Christoph Hellwig
2017-01-24 20:05         ` Darrick J. Wong [this message]
2017-01-24 14:06 ` Brian Foster
2017-01-24 14:49   ` Christoph Hellwig
2017-01-24 16:19     ` Brian Foster
2017-01-24 18:27       ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170124200505.GL4780@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox