Re: [PATCH 1/6] ext4: cache extent hole in extent status tree for ext4_da_map_blocks()

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

 



On Mon 24-11-14 10:34:34, Jan Kara wrote:
> On Sun 23-11-14 00:43:35, Ted Tso wrote:
> > On Fri, Nov 14, 2014 at 11:45:52AM +0100, Jan Kara wrote:
> > > From: Zheng Liu <wenqing.lz@xxxxxxxxxx>
> > > 
> > > Currently extent status tree doesn't cache extent hole when a write
> > > looks up in extent tree to make sure whether a block has been allocated
> > > or not.  In this case, we don't put extent hole in extent cache because
> > > later this extent might be removed and a new delayed extent might be
> > > added back.  But it will cause a defect when we do a lot of writes.  If
> > > we don't put extent hole in extent cache, the following writes also need
> > > to access extent tree to look at whether or not a block has been
> > > allocated.  It brings a cache miss.  This commit fixes this defect.
> > > Also if the inode doesn't have any extent, this extent hole will be
> > > cached as well.
> > > 
> > > Cc: "Theodore Ts'o" <tytso@xxxxxxx>
> > > Cc: Andreas Dilger <adilger.kernel@xxxxxxxxx>
> > > Signed-off-by: Zheng Liu <wenqing.lz@xxxxxxxxxx>
> > > Signed-off-by: Jan Kara <jack@xxxxxxx>
> > 
> > This patch (either when applied alone, or as part of the entire patch
> > series) is causing an xfstests regression test failure:
>   I saw this in my testing as well but when investigating I somehow decided
> it wasn't my bug and then forgot about it. Anyway, I'll check again and
> resolve it either way.
  So it really wasn't my bug but a problem in ext4_da_map_blocks() which
was made much more visible by this patch. Anyway, I've fixed it and
resubmitted the series.

								Honza

> > FSTYP         -- ext4
> > PLATFORM      -- Linux/i686 kvm-xfstests 3.18.0-rc3-00537-g932e3f9
> > MKFS_OPTIONS  -- -q /dev/vdc
> > MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc
> > 
> > ext4/003 4s ...	[00:14:39] [00:14:48] - output mismatch (see /results/results-4k/ext4/003.out.bad)
> >     --- tests/ext4/003.out	2014-10-31 10:13:03.000000000 -0400
> >     +++ /results/results-4k/ext4/003.out.bad	2014-11-23 00:14:48.935587897 -0500
> >     @@ -1,3 +1,3 @@
> >      QA output created by 003
> >     -wrote 268435456/268435456 bytes at offset 0
> >     +wrote 241762304/268435456 bytes at offset 0
> >      XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> >     ...
> >     (Run 'diff -u tests/ext4/003.out /results/results-4k/ext4/003.out.bad'  to see the entire diff)
> > 
> > 				- Ted
> -- 
> Jan Kara <jack@xxxxxxx>
> SUSE Labs, CR
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
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