All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Paulo Alcantara <pcacjr@zytor.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: refactor xfs_reserve_blocks() to handle ENOSPC correctly
Date: Tue, 14 Jun 2016 09:37:22 -0400	[thread overview]
Message-ID: <20160614133721.GD32443@bfoster.bfoster> (raw)
In-Reply-To: <B68205CB-0E29-4BB5-BB2A-C41CB2F1C32E@zytor.com>

On Tue, Jun 14, 2016 at 10:32:57AM -0300, Paulo Alcantara wrote:
> 
> 
> On June 14, 2016 9:58:59 AM GMT-03:00, Brian Foster <bfoster@redhat.com> wrote:
...
> >
> >Signed-off-by: Brian Foster <bfoster@redhat.com>
> >---
> >
> >This is something I had laying around from the thin block device
> >reservation stuff. That work introduced a more common
> >xfs_mod_fdblocks()
> >failure scenario that isn't as much of a problem with the current code,
> >but the current xfs_reserve_blocks() retry code is clearly broken and
> >so
> >should probably be fixed up.
> >
> >Brian
> >
> >fs/xfs/xfs_fsops.c | 105
> >++++++++++++++++++++++++++++++-----------------------
> > 1 file changed, 60 insertions(+), 45 deletions(-)
> >
> >diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> >index b4d7582..003d180 100644
> >--- a/fs/xfs/xfs_fsops.c
> >+++ b/fs/xfs/xfs_fsops.c
...
> >@@ -707,54 +709,67 @@ retry:
> > 			mp->m_resblks_avail -= lcounter;
> > 		}
> > 		mp->m_resblks = request;
> >-	} else {
> >-		__int64_t	free;
> >+		if (fdblks_delta) {
> >+			spin_unlock(&mp->m_sb_lock);
> >+			error = xfs_mod_fdblocks(mp, fdblks_delta, 0);
> >+			spin_lock(&mp->m_sb_lock);
> >+		}
> >+
> >+		goto out;
> >+	}
> > 
> >+	/*
> >+	 * If the request is larger than the current reservation, reserve the
> >+	 * blocks before we update the reserve counters. Sample m_fdblocks
> >and
> >+	 * perform a partial reservation if the request exceeds free space.
> >+	 */
> >+	error = -ENOSPC;
> >+	while (error == -ENOSPC) {
> 
> Why don't you make this a "do { } while (error == -ENOSPC)"? xfs_mod_fdblocks() will already set the error at the end of that loop.
> 

Sure, I can clean that up. Thanks.

Brian

> Paulo
> 
> -- 
> Paulo Alcantara, HP
> Speaking for myself only.
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2016-06-14 13:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 12:58 [PATCH] xfs: refactor xfs_reserve_blocks() to handle ENOSPC correctly Brian Foster
2016-06-14 13:32 ` Paulo Alcantara
2016-06-14 13:37   ` Brian Foster [this message]

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=20160614133721.GD32443@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=pcacjr@zytor.com \
    --cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.