On 04/09/2015 05:20 AM, Al Viro wrote:
> On Wed, Apr 08, 2015 at 09:57:37PM +0100, Al Viro wrote:
>> ... 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);
Looks like if generic_file_direct_write() return -EIOCBQUEUED and
IS_SYNC(inode) is true, the sync range is also wrong.
2385 if (direct_io) {
2386 loff_t endbyte;
2387 ssize_t written_buffered;
2388 written = generic_file_direct_write(iocb, from, *ppos);
2389 if (written < 0 || written == count) {
2390 ret = written;
2391 goto out_dio;
2392 }
2443 if (((file->f_flags & O_DSYNC) && !direct_io) ||
IS_SYNC(inode) ||
2444 ((file->f_flags & O_DIRECT) && !direct_io)) {
The other two patches looks good.
Thanks,
Junxiao.
>>
>> 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...
>
> Folks, could you please take a look through vfs.git#for-linus (the last
> three commits in there) and see if you are OK with those?
> --
> 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
>
--
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
