From mboxrd@z Thu Jan  1 00:00:00 1970
From: Junxiao Bi <junxiao.bi@oracle.com>
Subject: Re: [RFC] write(2) semantics wrt return values and current position
Date: Fri, 10 Apr 2015 22:31:02 +0800
Message-ID: <5527DEA6.2070309@oracle.com>
References: <20150406153641.GL889@ZenIV.linux.org.uk> <20150408192450.GQ889@ZenIV.linux.org.uk> <20150408205737.GR889@ZenIV.linux.org.uk> <20150408212026.GS889@ZenIV.linux.org.uk> <552604AC.8030704@oracle.com> <20150409112333.GT889@ZenIV.linux.org.uk> <20150409114232.GU889@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 7bit
Cc: linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Oleg Drokin <oleg.drokin@intel.com>,
	Joseph Qi <joseph.qi@huawei.com>,
	Joel Becker <jlbec@evilplan.org>,
	Mark Fasheh <mfasheh@suse.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from userp1040.oracle.com ([156.151.31.81]:28419 "EHLO
	userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756098AbbDJOcl (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 10 Apr 2015 10:32:41 -0400
In-Reply-To: <20150409114232.GU889@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 04/09/2015 07:42 PM, Al Viro wrote:
> On Thu, Apr 09, 2015 at 12:23:33PM +0100, Al Viro wrote:
>> On Thu, Apr 09, 2015 at 12:48:44PM +0800, Junxiao Bi wrote:
>>
>>> Looks like if generic_file_direct_write() return -EIOCBQUEUED and
>>> IS_SYNC(inode) is true, the sync range is also wrong.
>> *blink*
>>
>> But in that case it shouldn't do any syncing at all...  Oh, right.
>> Unlike generic_file_write_iter(), if goes into the sync pathway
>> in that case (which was another long-standing bug there)...
>>
>> Fixed and force-pushed.
> 	BTW, what about the locks needed to stabilize the file size?
> generic_write_checks() in there looks like it's called too late - we
> can't tell a damn thing about alignment until we do it, so at the very
> least we might need to recheck that.
>
> 	Can we move it _before_ ocfs2_prepare_inode_for_write()?
> Having it done twice in case we end up on "can't really do O_DIRECT, unlock
> and redo everything without asking for direct IO" path is not a problem -
> we just need to save the original count and restore it before that
> goto relock in there.
>
> 	Do we hold enough locks to make sure that file size won't change
> under us?
I think holding ocfs2_rw_lock() for cluster and i_mutex for local will 
stop file size changing under us. So looks safe to do your changes there.

Thanks,
Junxiao.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html