From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 04/11] xfs: ensure EFD trans aborts on log recovery extent free failure
Date: Mon, 10 Aug 2015 09:39:39 -0400 [thread overview]
Message-ID: <20150810133939.GA33960@bfoster.bfoster> (raw)
In-Reply-To: <20150810123803.GC18933@bfoster.bfoster>
On Mon, Aug 10, 2015 at 08:38:04AM -0400, Brian Foster wrote:
> On Sun, Aug 09, 2015 at 12:53:11AM -0700, Christoph Hellwig wrote:
> > > + /*
> > > + * Log the EFD before error handling to ensure the EFD aborts
> > > + * (and releases the EFI) on error.
> > > + */
> > > error = xfs_free_extent(tp, extp->ext_start, extp->ext_len);
> > > xfs_trans_log_efd_extent(tp, efdp, extp->ext_start,
> > > extp->ext_len);
> >
> > Given that we now always need to log the extents in the EFD even on
> > error maybe it's time to move the call to xfs_free_extent into
> > xfs_trans_log_efd_extent and rename it to xfs_trans_free_extent?
> >
> > Or even better convert xfs_bmap_finish to also walk the extents in the
> > EFI instead of xfs_bmap_free list and have a xfs_trans_free_extents helper
> > ala:
> >
>
> Good idea, I'll incorporate something like this.
>
> Brian
>
After taking a closer look at this, I think I'll go with the first idea
to push down xfs_free_extent(). The code below to iterate based on the
EFI, while a nice cleanup, complicates handling the free list on error.
E.g., we currently remove each bmap_free_item as it is successfully
processed so the resulting list is consistent with the items that were
not processed before the error.
It might not matter functionally at the moment since the caller probably
cancels the free list, but I consider that a landmine should we decide
to do something more with the unprocessed entries down the road.
Brian
> > int
> > xfs_trans_free_extents(
> > struct xfs_trans *tp,
> > struct xfs_efi_log_item *efip)
> > {
> > struct xfs_efd_log_item *efdp;
> > int error = 0, i;
> >
> > efdp = xfs_trans_get_efd(tp, efip, efip->efi_format.efi_nextents);
> > for (i = 0; i < efip->efi_format.efi_nextents; i++) {
> > struct xfs_extent *extp = &efip->efi_format.efi_extents[i];
> >
> > error = xfs_free_extent(tp, extp->ext_start, extp->ext_len);
> > xfs_trans_log_efd_extent(tp, efdp, extp->ext_start,
> > extp->ext_len);
> >
> > if (error)
> > break;
> > }
> >
> > return error;
> > }
> >
> > _______________________________________________
> > 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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-10 13:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 17:44 [PATCH 00/11] xfs: miscellaneous logging, recovery, umount fixes Brian Foster
2015-08-06 17:44 ` [PATCH 01/11] xfs: disentagle EFI release from the extent count Brian Foster
2015-08-09 7:36 ` Christoph Hellwig
2015-08-10 12:37 ` Brian Foster
2015-08-12 7:15 ` Christoph Hellwig
2015-08-12 12:47 ` Brian Foster
2015-08-06 17:44 ` [PATCH 02/11] xfs: return committed status from xfs_trans_roll() Brian Foster
2015-08-09 7:37 ` Christoph Hellwig
2015-08-06 17:44 ` [PATCH 03/11] xfs: fix efi/efd error handling to avoid fs shutdown hangs Brian Foster
2015-08-07 0:41 ` Dave Chinner
2015-08-07 12:09 ` Brian Foster
2015-08-07 22:45 ` Dave Chinner
2015-08-09 7:46 ` Christoph Hellwig
2015-08-06 17:44 ` [PATCH 04/11] xfs: ensure EFD trans aborts on log recovery extent free failure Brian Foster
2015-08-09 7:53 ` Christoph Hellwig
2015-08-10 12:38 ` Brian Foster
2015-08-10 13:39 ` Brian Foster [this message]
2015-08-06 17:44 ` [PATCH 05/11] xfs: use EFI refcount consistently in log recovery Brian Foster
2015-08-07 1:51 ` Dave Chinner
2015-08-07 12:09 ` Brian Foster
2015-08-09 7:56 ` Christoph Hellwig
2015-08-10 12:37 ` Brian Foster
2015-08-06 17:44 ` [PATCH 06/11] xfs: don't leave EFIs on AIL on mount failure Brian Foster
2015-08-07 2:23 ` Dave Chinner
2015-08-07 12:10 ` Brian Foster
2015-08-09 8:01 ` Christoph Hellwig
2015-08-10 12:38 ` Brian Foster
2015-08-06 17:44 ` [PATCH 07/11] xfs: icreate log item recovery and cancellation tracepoints Brian Foster
2015-08-09 8:02 ` Christoph Hellwig
2015-08-06 17:44 ` [PATCH 08/11] xfs: fix broken icreate log item cancellation Brian Foster
2015-08-06 17:44 ` [PATCH 09/11] xfs: checksum log record ext headers based on record size Brian Foster
2015-08-06 17:44 ` [PATCH 10/11] xfs: clean up root inode properly on mount failure Brian Foster
2015-08-09 8:03 ` Christoph Hellwig
2015-08-06 17:44 ` [PATCH 11/11] xfs: fix btree cursor error cleanups Brian Foster
2015-08-09 8:03 ` Christoph Hellwig
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=20150810133939.GA33960@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox