AFAIR, this behavior has been there since day 1 and changing it will impact performance negatively. I would recommend against making this change for one app.
On Wed, Jun 26, 2013 at 6:50 PM, shencanquan <shencanq...@huawei.com> wrote: > On 2013/6/27 9:25, Andrew Morton wrote: > > > On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan <shencanq...@huawei.com> > wrote: > > > >> On 2013/6/27 5:18, Andrew Morton wrote: > >> > >>> > >>> My guess is that there is some other code path which is modifying > >>> inode->i_size without holding inode->i_mutex, and while holding > >>> ocfs2_inode_lock(). If so, that code is surely wrong - it should hold > >>> i_mutex while modifying i_size. > >> > >> > >> inode->i_mutex lock only protect the inode size on the same machine. > > > > ah ;) > > > >>> And all this is only really applicable to 32-bit CPUs, which you > >>> probably aren't using. > >> > >> I don't understand this. > > > > The i_size_read/i_size_write infrastructure is designed to efficiently > > handle the situation where a 32-bit machine reads a 64-bit number which > > might be undergoing modification on another CPU. We don't want the > > reading CPU to see an invalid number when the writing CPU is in the > > middle of modifying the two 32-bit words. > > > > > > > > ok. thanks. > > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel >
_______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel