Re: Bug with "fix partial page writes" [3.2-rc regression]

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

 



On Mon, 5 Dec 2011, Allison Henderson wrote:
> On 12/05/2011 04:38 PM, Hugh Dickins wrote:
> > 
> > This has been outstanding for a month now, and we've heard no progress:
> > please revert commit 02fac1297eb3 "ext4: fix partial page writes" for rc5.
> > 
> > The problems appear on a 1k-blocksize filesystem under memory pressure:
> > the hunk in ext4_da_write_end() causes oops, because it's playing with
> > a page after generic_write_end() dropped our last reference to it; and
> > backing out the hunk in ext4_da_write_begin() is then found to stop
> > rare data corruption seen when kbuilding.
> > 
> > Although I earlier reported that backing out the patch caused an fsx
> > test to fail earlier, I've since found great variation in how soon it
> > fails, and seen it fail just as quickly with 02fac1297eb3 still in.
> > I also reported that I had to go back to 2.6.38 for fsx not to fail
> > under memory pressure: you won't be surprised that that turned out to
> > be because 2.6.38 defaults nomblk_io_submit but 2.6.39 mblk_io_submit.
> 
> Have you tried Yongqiang's patch "[PATCH 1/2] ext4: let mpage_submit_io
> works well when blocksize < pagesize" ?  I have tried it and it does seem to
> help, but I am still running into some failures that I am trying to debug,
> but let please let us know if it helps the issues that you are seeing.  Thx!

That 1/2, or the 2/2 "ext4: let ext4_discard_partial_buffers handle
pages without buffers correctly"?  The latter is mostly a reversion
of your 02fac1297eb3, so that's the one I need to fix the oops and
rare data corruption.  Perhaps you're suggesting 1/2 for fsx failures
under memory pressure?

I've now tried the fsx test on three machines, with both 1/2 and 2/2
applied to 3.2-rc4.  On one machine, with ext2 on loop on tmpfs, the
fsx test failed in a couple of minutes with those patches; on another
machine, with ext2 on loop on tmpfs, it failed after about 40 minutes
with  the patches; on this laptop, with ext2 on SSD, it's just now
failed after 35 minutes with the patches.

That's not to say that Yongqiang's patches aren't good; but I cannot
detect whether they make any improvement or not, since lasting for 2 or
40 minutes is typical for fsx under memory pressure with recent kernels.

Hugh
--
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