On Wed, Apr 08, 2015 at 08:24:50PM +0100, Al Viro wrote:
> In other words, after short write done by ->direct_IO(), we end up incrementing
> position by *twice* the amount written by it. And if it's short, but not
> empty, we appear to be buggered...
>
> Unless I hear "Al, you idiot, it's doing the right thing, here's what you've
> missed: ...", I'm going to take that increment in ocfs2_file_write_iter()
> out, and send it to Linus for 4.0 - it's post-3.19 regression.
... and having looked through old mail, there's _another_ breakage that
might have inspired that one; this one is mine - "ocfs2 syncs the wrong range".
It was syncing the wrong range with O_APPEND, all right, but after that
patch it was syncing the wrong range in _all_ cases. What it should've
been doing instead is
ret = filemap_fdatawrite_range(file->f_mapping,
iocb->ki_pos - written,
iocb->ki_pos - 1);
...
ret = filemap_fdatawait_range(file->f_mapping,
iocb->ki_pos - written,
iocb->ki_pos - 1);
Joseph, my apologies for missing your mail back in January - you are absolutely
correct, *ppos (aka iocb->ki_pos) _is_ changed. Unlike pos, it can be used
to get the right range reliably (as above; pos, back when it existed,
hadn't been affected by generic_write_checks() call in what used to be
ocfs2_file_aio_write()), but the actual calculation had been completely
wrong.
If that had contributed to confusion, my deep apologies...
Another fun issue in there: ocfs2_is_io_unaligned() is called before we
get around to checking rlimit and possibly truncating the range being
written. IOW, result of that check is unreliable.
At which point in that function do we get the file size stabilized?
After ocfs2_rw_lock()?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
