Re: [PATCH 0/9 v3] ext4: Punch hole and DAX fixes

[Jan Kara <jack@suse.cz>]

On Mon 09-11-15 17:22:56, Jan Kara wrote:
>   Hi,
> 
> On Fri 06-11-15 17:57:04, Boylston, Brian wrote:
> > I've written a test tool (included below) that exercises page faults on
> > hole-y portions of an mmapped file.  The file is created, sized using
> > various methods, mmapped, and then two threads race to write a marker to
> > different offsets within each mapped page.  Once the threads have
> > finished marking each page, the pages are checked for the presence of
> > the markers.
> > 
> > With vanilla 4.2 and 4.3 kernels, this test easily exposes corruption on
> > pmem-backed, DAX-mounted xfs and ext4 file systems.
> > 
> > With 4.3 and this ext4 patch set, the data corruption is still seen:
> > 
> > $ ./holetest -f /pmem1/brian/holetest 1000
> > holetest r207
> 
> Thanks for the test. I'll try to reproduce locally and have a look why
> my block zeroing patch didn't work as expected.

Ah, OK, I see what's going on. So ext4 with my patches still returns
buffer_new buffer even though it is zeroed out and thus generic DAX code
still tries to zero out the buffer again which indeed causes the corrution
(will test everything tomorrow with that code disabled).  Now I have
decided that block mapping function should return buffer_new buffer even
though it is zeroed out because e.g. if block zeroing was used for page
cache writes, we'd still need code in fs/buffer.c to do proper zeroing of
parts of the block that are not written. And that happens based on
buffer_new flag.

The zeroing code in __dax_fault() needs to go away anyway so whether we
return buffer_new buffer is not really substantial but I'd like to get some
agreement and consistency among filesystems in with which flags zeroed
blocks are returned. Thoughts?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR