All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valerie Clement <valerie.clement@bull.net>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] fix file system corruption [ was Re: mballoc errors ]
Date: Tue, 01 Apr 2008 10:38:50 +0200	[thread overview]
Message-ID: <47F1F49A.7020102@bull.net> (raw)
In-Reply-To: <20080331205030.GB30646@skywalker>

Aneesh Kumar K.V wrote:
> I found one case where it could fail. We are returning total extent size
> in case of converting from uninitialized extent to initialized one. 
> Now if we have the below layout
> 
> [p --------x--------]
> 
> where p is the start block and x is the location where we intent to
> write. If converting the above uninit extent resulted in 
> 
> [p zeroed-out][uninit].
> 
> We should not be returning the size of
> zeroed-out-extent. That is because in ext4_ext_get_blocks we cache
> the extent information as below
> 
> out_new:
> 		....
> /* Cache only when it is _not_ an uninitialized extent */
> if (create != EXT4_CREATE_UNINITIALIZED_EXT)
> 	ext4_ext_put_in_cache(inode, iblock, allocated, newblock,
> 						EXT4_EXT_CACHE_EXTENT);
> out:
> 
> 
> That would mean we are caching an extent starting from newblock of
> size allocated where allocated would be the size of zeroout extent,
> which is actually wrong.
> 
> I am yet to test the patch. If you have time can you test the below
> change

Hi Aneesh,
I tested your patch but unfortunately I still reproduced the problem with it:
EXT4-fs error (device sdc1): ext4_valid_block_bitmap: Invalid block bitmap - 
block_group = 6233, block = 51060737

Is there another thing I could do to help debugging the problem?
   Valerie

> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 964d2c1..91f8f72 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2264,7 +2264,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
>  		ex->ee_len   = orig_ex.ee_len;
>  		ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
>  		ext4_ext_dirty(handle, inode, path + depth);
> -		return le16_to_cpu(ex->ee_len);
> +		/* zeroed the full extent */
> +		return allocated;
>  	}
>  
>  	/* ex1: ee_block to iblock - 1 : uninitialized */
> @@ -2309,11 +2310,13 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
>  				ex->ee_len   = orig_ex.ee_len;
>  				ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
>  				ext4_ext_dirty(handle, inode, path + depth);
> -				return le16_to_cpu(ex->ee_len);
> +				/* zeroed the full extent */
> +				return allocated;
>  
>  			} else if (err)
>  				goto fix_extent_len;
>  
> +			/* zeroed the second half */
>  			return allocated;
>  		}
>  		ex3 = &newex;
> @@ -2331,7 +2334,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
>  			ex->ee_len   = orig_ex.ee_len;
>  			ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
>  			ext4_ext_dirty(handle, inode, path + depth);
> -			return le16_to_cpu(ex->ee_len);
> +			/* zeroed the full extent */
> +			return allocated;
>  
>  		} else if (err)
>  			goto fix_extent_len;
> @@ -2379,7 +2383,8 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
>  			ex->ee_len   = orig_ex.ee_len;
>  			ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
>  			ext4_ext_dirty(handle, inode, path + depth);
> -			return le16_to_cpu(ex->ee_len);
> +			/* zero out the first half */
> +			return allocated;
>  		}
>  	}
>  	/*
> @@ -2446,7 +2451,8 @@ insert:
>  		ex->ee_len   = orig_ex.ee_len;
>  		ext4_ext_store_pblock(ex, ext_pblock(&orig_ex));
>  		ext4_ext_dirty(handle, inode, path + depth);
> -		return le16_to_cpu(ex->ee_len);
> +		/* zero out the first half */
> +		return allocated;
>  	} else if (err)
>  		goto fix_extent_len;
>  out:
> 
> 


  reply	other threads:[~2008-04-01  8:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-26 21:41 mballoc errors Eric Sandeen
2008-03-26 23:23 ` Bernd Schubert
2008-03-26 23:31 ` Mingming Cao
2008-03-27  3:48 ` Aneesh Kumar K.V
2008-03-27  7:53 ` Solofo.Ramangalahy
2008-03-28 14:03 ` Valerie Clement
     [not found]   ` <20080331065802.GA19456@skywalker>
     [not found]     ` <47F0FBFE.7060404@bull.net>
2008-03-31 20:18       ` Aneesh Kumar K.V
2008-03-31 20:50         ` [PATCH] fix file system corruption [ was Re: mballoc errors ] Aneesh Kumar K.V
2008-04-01  8:38           ` Valerie Clement [this message]
2008-04-01  9:01             ` Aneesh Kumar K.V
2008-04-01  9:46               ` Valerie Clement

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=47F1F49A.7020102@bull.net \
    --to=valerie.clement@bull.net \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.