Re: Some O_DIRECT vs. block_truncate_page problems

[Andrew Morton <akpm@digeo.com>]

Eric Sandeen wrote:
> 
> I'm trying to track down a bug I'm seeing after I run xfs's
> defragmenter, where data is present past EOF in the last block.
> 
> xfs_fsr does this (essentially):
> 
> o allocate some contiguous space with an xfs-specific ioctl
> o copy the fragmented file into the new file with O_DIRECT
> o truncate() the new file back to the correct size (since it's currently
>   a multiple of the block size)
> o sync the new file
> o do "xfs_inval_cached_pages", which is essentially:
>     - filemap_fdatasync(ip->i_mapping);
>     - fsync_inode_data_buffers(ip);
>     - filemap_fdatawait(ip->i_mapping);
>     - truncate_inode_pages(ip->i_mapping, first);

What is "first"?  It should be i_size.  If it's zero then
yes, you lost the dirty pagecache and dirty buffer.

> ...
> 
> --- linux/fs/buffer.c_1.109     Mon Sep 23 13:10:56 2002
> +++ linux/fs/buffer.c   Mon Sep 23 13:04:44 2002
> @@ -2028,7 +2028,12 @@
>         flush_dcache_page(page);
>         kunmap(page);
> 
> -       __mark_buffer_dirty(bh);
> +       if (!atomic_set_buffer_dirty(bh)) {
> +               __mark_dirty(bh);
> +               buffer_insert_inode_data_queue(bh, inode);
> +               balance_dirty();
> +       }
> +
>         err = 0;

Makes sense I guess.  I'd be inclined to leave the balance_dirty()
out of there, just because it does add a tiny little more risk.

> On a related note, while testing some O_DIRECT cases on ext2, I found
> another, possibly related, bug.
> 
> If you O_DIRECT write 2 blocks into a new file, truncate() the file to
> 1.5 blocks, then do an O_DIRECT read of the last block, you get
> incorrect data.  Rather than 1/2 data, 1/2 zeroes, I get all zeroes.

Does this still happen with your patch?  I'd expect that with
your patch, you would see all data, not all zeroes.

What blocksize and pagesize are you using, btw?