All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Libor Klepáč" <libor.klepac@bcom.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs_repair: junk leaf attribute if count == 0
Date: Tue, 13 Dec 2016 11:52:44 +0100	[thread overview]
Message-ID: <2626665.Hsx8YazNWY@libor-nb> (raw)
In-Reply-To: <725190d9-6db0-4f6c-628b-76f2dca3071f@redhat.com>

Hello,
should this patch possibly fix errors i reported in this thread?
https://www.spinics.net/lists/linux-xfs/msg01728.html

Is it safe to test it? (i do have backups)

Thanks,
Libor

On čtvrtek 8. prosince 2016 12:06:03 CET Eric Sandeen wrote:
> We have recently seen a case where, during log replay, the
> attr3 leaf verifier reported corruption when encountering a
> leaf attribute with a count of 0 in the header.
> 
> We chalked this up to a transient state when a shortform leaf
> was created, the attribute didn't fit, and we promoted the
> (empty) attribute to the larger leaf form.
> 
> I've recently been given a metadump of unknown provenance which actually
> contains a leaf attribute with count 0 on disk.  This causes the
> verifier to fire every time xfs_repair is run:
> 
>  Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
> 
> If this 0-count state is detected, we should just junk the leaf, same
> as we would do if the count was too high.  With this change, we now
> remedy the problem:
> 
>  Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
>  bad attribute count 0 in attr block 0, inode 12587828
>  problem with attribute contents in inode 12587828
>  clearing inode 12587828 attributes
>  correcting nblocks for inode 12587828, was 2 - counted 1
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> diff --git a/repair/attr_repair.c b/repair/attr_repair.c
> index 40cb5f7..b855a10 100644
> --- a/repair/attr_repair.c
> +++ b/repair/attr_repair.c
> @@ -593,7 +593,8 @@ process_leaf_attr_block(
>  	stop = xfs_attr3_leaf_hdr_size(leaf);
>  
>  	/* does the count look sorta valid? */
> -	if (leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop >
> +	if (!leafhdr.count ||
> +	    leafhdr.count * sizeof(xfs_attr_leaf_entry_t) + stop >
>  						mp->m_sb.sb_blocksize) {
>  		do_warn(
>  	_("bad attribute count %d in attr block %u, inode %" PRIu64 "\n"),
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



  parent reply	other threads:[~2016-12-13 10:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-08 18:06 [PATCH] xfs_repair: junk leaf attribute if count == 0 Eric Sandeen
2016-12-12 18:36 ` Brian Foster
2016-12-13 10:52 ` Libor Klepáč [this message]
2016-12-13 16:04   ` Eric Sandeen
2016-12-15 20:48     ` Libor Klepáč
2016-12-21  8:25     ` Libor Klepáč
2016-12-24 17:50       ` Eric Sandeen
2017-01-31  8:03     ` Libor Klepáč
2017-03-13 13:48       ` Libor Klepáč
2017-03-13 14:14         ` Eric Sandeen
2017-03-14  8:15           ` Libor Klepáč
2017-03-14 16:54             ` Eric Sandeen
2017-03-14 18:51               ` Eric Sandeen
2017-03-15 10:07               ` Libor Klepáč
2017-03-15 15:22                 ` Eric Sandeen
2017-03-16  8:58                   ` Libor Klepáč
2017-03-16 15:21                     ` Eric Sandeen
2017-03-29 13:33                       ` Libor Klepáč
2017-04-11 11:23                         ` Libor Klepáč
2017-05-24 11:18                       ` Libor Klepáč
2017-05-24 12:24                         ` Libor Klepáč
2017-02-01 12:48     ` Libor Klepáč
2017-02-01 22:49       ` Eric Sandeen
2017-02-02  8:35         ` Libor Klepáč
2017-02-22 11:42       ` Libor Klepáč
2017-02-22 13:45         ` Eric Sandeen
2017-02-22 14:19           ` Libor Klepáč
2017-02-23  9:05           ` Libor Klepáč

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=2626665.Hsx8YazNWY@libor-nb \
    --to=libor.klepac@bcom.cz \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.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.