[PATCH] ext4: correctly calculate number of blocks for fiemap

Andy Whitcroft apw at canonical.com
Thu Apr 8 17:57:39 UTC 2010


On Fri, Apr 02, 2010 at 01:44:41AM +0300, Surbhi Palande wrote:
> On Thu, 2010-04-01 at 07:53 -0700, Brad Figg wrote:
> > On 04/01/2010 02:37 AM, Stefan Bader wrote:
> > > Ok, looks good to me now.
> > >
> > > Surbhi Palande wrote:
> > >> The following cherry-picked patch fixes the calculation of extents in fiemap.
> > >> Without this patch a user of fiemap could be misled into thinking that there
> > >> are no extents in a file when actually there are. This patch is necessary for
> > >> code such as ureadahead which uses fiemap to find out if the file extents have
> > >> increased.
> > >>
> > >> The commit id in the upstream code is: aca92ff6f57c000d1b4523e383c8bd6b8269b8b1
> > >> This patch fixes bug 474597 on LP. Do consider merging this in Lucid.
> > >>
> > >>  From dfaa33f0502a8bf9dff0e596783a40ce330c7a9b Mon Sep 17 00:00:00 2001
> > >> From: Leonard Michlmayr<leonard.michlmayr at gmail.com>
> > >> Date: Thu, 4 Mar 2010 17:07:28 -0500
> > >> Subject: [PATCH] ext4: correctly calculate number of blocks for fiemap
> > >>
> > >> ext4_fiemap() rounds the length of the requested range down to
> > >> blocksize, which is is not the true number of blocks that cover the
> > >> requested region.  This problem is especially impressive if the user
> > >> requests only the first byte of a file: not a single extent will be
> > >> reported.
> > >>
> > >> We fix this by calculating the last block of the region and then
> > >> subtract to find the number of blocks in the extents.
> > >>
> > >> Signed-off-by: Leonard Michlmayr<leonard.michlmayr at gmail.com>
> > >> Signed-off-by: "Theodore Ts'o"<tytso at mit.edu>
> > >> (cherry picked from commit aca92ff6f57c000d1b4523e383c8bd6b8269b8b1 upstream)
> > >>
> > >> BugLink: http://launchpad.net/bugs/474597
> > >> Signed-off-by: Surbhi Palande<surbhi.palande at canonical.com>
> > > Acked-by: Stefan Bader<stefan.bader at canonical.com>
> > >> ---
> > >>   fs/ext4/extents.c |    9 +++++++--
> > >>   1 files changed, 7 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> > >> index 8b8bae4..f199d20 100644
> > >> --- a/fs/ext4/extents.c
> > >> +++ b/fs/ext4/extents.c
> > >> @@ -3711,7 +3711,6 @@ int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> > >>   		__u64 start, __u64 len)
> > >>   {
> > >>   	ext4_lblk_t start_blk;
> > >> -	ext4_lblk_t len_blks;
> > >>   	int error = 0;
> > >>
> > >>   	/* fallback to generic here if not in extents fmt */
> > >> @@ -3725,8 +3724,14 @@ int ext4_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> > >>   	if (fieinfo->fi_flags&  FIEMAP_FLAG_XATTR) {
> > >>   		error = ext4_xattr_fiemap(inode, fieinfo);
> > >>   	} else {
> > >> +		ext4_lblk_t len_blks;
> > >> +		__u64 last_blk;
> > >> +
> > >>   		start_blk = start>>  inode->i_sb->s_blocksize_bits;
> > >> -		len_blks = len>>  inode->i_sb->s_blocksize_bits;
> > >> +		last_blk = (start + len - 1)>>  inode->i_sb->s_blocksize_bits;
> > >> +		if (last_blk>= EXT_MAX_BLOCK)
> > >> +			last_blk = EXT_MAX_BLOCK-1;
> > >> +		len_blks = ((ext4_lblk_t) last_blk) - start_blk + 1;
> > >>
> > >>   		/*
> > >>   		 * Walk the extent tree gathering extent information.
> > >
> > >
> > 
> > Maybe I'm misreading this bug according to
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/474597/comments/7
> > ted applied a different patch to fix this issue.
> > 
> Brad, thanks for pointing this out. 
> 
> The patch that actually got into the linux kernel does seem to have the
> additional check (missing from whats on launchpad)
> +if (last_blk>= EXT_MAX_BLOCK)
> +	last_blk = EXT_MAX_BLOCK-1;
> This check seems necessary for the corner case.
> 
> I have pointed the difference out on the buglink too.

That implies that there is a better patch out there.  Am I expecting
that patch to be posted instead here?

-apw




More information about the kernel-team mailing list