public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH 2/4] libxfs: buffers aren't stale once written
Date: Tue,  1 Jul 2014 22:54:54 +1000	[thread overview]
Message-ID: <1404219296-29302-3-git-send-email-david@fromorbit.com> (raw)
In-Reply-To: <1404219296-29302-1-git-send-email-david@fromorbit.com>

From: Dave Chinner <dchinner@redhat.com>

When rebuilding a bad directory, repair first truncates away all the
blocks in the directory. This removes blocks from the bmap btree,
and when those blocks are freed the bmap btree code invalidates
them. This marks the buffers LIBXFS_B_STALE so that we don't try to
write stale data from that buffer at a later time.

However, when rebuilding the directory, the block gets reallocated
and new metadata gets written into it. however, it is still marked
stale and hence the new, corrected metadata is never written. Hence
if we write new metadata to a stale buffer, we have to clear the
LIBXFS_B_STALE flag to ensure that the new data gets written.

Note that this can affect more than just bmap btree buffers - there
are several different places in the libxfs code that mark buffers
stale via xfs_trans_binval() during repair operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 libxfs/rdwr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
index 981f2ba..28f8f36 100644
--- a/libxfs/rdwr.c
+++ b/libxfs/rdwr.c
@@ -928,6 +928,7 @@ libxfs_writebuf_int(xfs_buf_t *bp, int flags)
 	 * subsequent reads after this write from seeing stale errors.
 	 */
 	bp->b_error = 0;
+	bp->b_flags &= ~LIBXFS_B_STALE;
 	bp->b_flags |= (LIBXFS_B_DIRTY | flags);
 	return 0;
 }
@@ -946,6 +947,7 @@ libxfs_writebuf(xfs_buf_t *bp, int flags)
 	 * subsequent reads after this write from seeing stale errors.
 	 */
 	bp->b_error = 0;
+	bp->b_flags &= ~LIBXFS_B_STALE;
 	bp->b_flags |= (LIBXFS_B_DIRTY | flags);
 	libxfs_putbuf(bp);
 	return 0;
-- 
2.0.0

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

  parent reply	other threads:[~2014-07-01 12:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 12:54 [PATCH 0/4] repair: fixes for 3.2 Dave Chinner
2014-07-01 12:54 ` [PATCH 1/4] repair: handle directory block corruption in phase 6 Dave Chinner
2014-07-01 12:54 ` Dave Chinner [this message]
2014-07-01 12:54 ` [PATCH 3/4] repair: fix quota inode handling in secondary superblocks Dave Chinner
2014-07-01 12:54 ` [PATCH 4/4] repair: get rid of BADFSINO Dave Chinner
2014-07-01 13:43   ` Arkadiusz Miśkiewicz
2014-07-01 13:40 ` [PATCH 0/4] repair: fixes for 3.2 Arkadiusz Miśkiewicz
2014-07-01 20:03   ` Dave Chinner

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=1404219296-29302-3-git-send-email-david@fromorbit.com \
    --to=david@fromorbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox