Re: [3/3] libext2fs: pick out UNINIT-EXTENT block

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 29, 2011 at 08:28:34PM -0000, Robin Dong wrote:
> From: Robin Dong <sanbai@xxxxxxxxxx>
> 
> for display UNINIT-EXTENT block usage in dumpe2fs, modify 
> ext2fs_block_iterate3 to distinguish between uninitial extent
> block and normal extent block
> 
> Signed-off-by: Robing Dong <sanbai@xxxxxxxxxx>
> 
> ---
> lib/ext2fs/block.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/ext2fs/block.c b/lib/ext2fs/block.c
> index 0e4ec77..c7a60da 100644
> --- a/lib/ext2fs/block.c
> +++ b/lib/ext2fs/block.c
> @@ -458,7 +458,7 @@ errcode_t ext2fs_block_iterate3(ext2_filsys fs,
>  			     blk++, blockcnt++, j++) {
>  				new_blk = blk;
>  				r = (*ctx.func)(fs, &new_blk, blockcnt,
> -						0, 0, priv_data);
> +						extent.e_flags, 0, priv_data);

Apologies for not getting back to this earlier, but I don't want to
overload the ref_blk field, since it will have a very different
meaning for extent-mapped and files mapped using the traditional
indirect block scheme.  This could potentially confuse callers who
don't know about extents.

Programs that want to find out about the uninitialized extent flag,
should use the extent iterator functions.

As far as the other patches in this series, I'm concerned that
dumpe2fs -s is going to confuse users more than anything else.

	       	     		      	   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux