linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6/6] btrfs: Simplify code flow in btrfs_delayed_inode_reserve_metadata
Date: Mon, 1 Mar 2021 19:54:52 +0100	[thread overview]
Message-ID: <20210301185452.GA7604@twin.jikos.cz> (raw)
In-Reply-To: <7129f1a4-ba72-c35e-7a77-0ead54f7fede@suse.com>

On Mon, Mar 01, 2021 at 06:20:29PM +0200, Nikolay Borisov wrote:
> 
> 
> On 1.03.21 г. 18:15 ч., David Sterba wrote:
> > On Mon, Feb 22, 2021 at 06:40:47PM +0200, Nikolay Borisov wrote:
> >> btrfs_block_rsv_add can return only ENOSPC since it's called with
> >> NO_FLUSH modifier. This so simplify the logic in
> >> btrfs_delayed_inode_reserve_metadata to exploit this invariant.
> > 
> > This seems quite fragile, it's not straightforward to see from the
> > context that the NO_FLUSH code will always return ENOSPC. I followed a
> > few calls down from btrfs_block_rsv_add and it's well hidden inside
> > __reserve_bytes. So in case it's an invariant I'd rather add an
> > assertion, ie. ASSERT(ret == 0 || ret == -ENOSPC) so at least we know
> > when this gets broken. Otherwise looks ok.
> 
> Fair enough, I'm fine with it. In any case we no longer return eagain
> when reserving. either we succeed or we return ENOSPC - either because
> we don't have space and we can't flush or because even after the
> flushing machinery did its work a ticket still couldn't be satisfied, in
> which case we failed it hence ENOSPC got returned.

Yeah but this is a precaution when somebody reworks the flushing logic
yet another time and suddenly EAGAIN or whatever else can become the
return code again. Hunting such bugs can be quite difficult as it
depends on the runtime state and the space stat on disk etc.

  reply	other threads:[~2021-03-01 19:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 16:40 [PATCH 0/6] Qgroup/delayed node related fixes Nikolay Borisov
2021-02-22 16:40 ` [PATCH 1/6] btrfs: Free correct amount of space in btrfs_delayed_inode_reserve_metadata Nikolay Borisov
2021-02-22 23:41   ` Qu Wenruo
2021-02-22 16:40 ` [PATCH 2/6] btrfs: Export qgroup_reserve_meta Nikolay Borisov
2021-02-22 23:42   ` Qu Wenruo
2021-02-25 16:27     ` David Sterba
2021-02-22 16:40 ` [PATCH 3/6] btrfs: Don't flush from btrfs_delayed_inode_reserve_metadata Nikolay Borisov
2021-02-22 23:45   ` Qu Wenruo
2021-02-22 16:40 ` [PATCH 4/6] btrfs: Cleanup try_flush_qgroup Nikolay Borisov
2021-02-22 23:46   ` Qu Wenruo
2021-02-22 16:40 ` [PATCH 5/6] btrfs: Remove btrfs_inode from btrfs_delayed_inode_reserve_metadata Nikolay Borisov
2021-02-22 23:53   ` Qu Wenruo
2021-02-22 16:40 ` [PATCH 6/6] btrfs: Simplify code flow in btrfs_delayed_inode_reserve_metadata Nikolay Borisov
2021-03-01 16:15   ` David Sterba
2021-03-01 16:20     ` Nikolay Borisov
2021-03-01 18:54       ` David Sterba [this message]
2021-03-01 18:55 ` [PATCH 0/6] Qgroup/delayed node related fixes David Sterba

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=20210301185452.GA7604@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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;
as well as URLs for NNTP newsgroup(s).