From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH] exofs: exofs_file_fsync correctness Date: Tue, 01 Jun 2010 19:10:00 +0300 Message-ID: <4C0530D8.8010401@panasas.com> References: <20100531100927.GA11149@lst.de> <4C0527AF.6090502@panasas.com> <20100601153414.GA15889@lst.de> <4C0529FE.6030901@panasas.com> <20100601154718.GA16412@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, open-osd To: Christoph Hellwig Return-path: Received: from daytona.panasas.com ([67.152.220.89]:54765 "EHLO daytona.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756063Ab0FAQKD (ORCPT ); Tue, 1 Jun 2010 12:10:03 -0400 In-Reply-To: <20100601154718.GA16412@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 06/01/2010 06:47 PM, Christoph Hellwig wrote: > On Tue, Jun 01, 2010 at 06:40:46PM +0300, Boaz Harrosh wrote: >>>> + struct writeback_control wbc = { >>>> + .sync_mode = WB_SYNC_ALL, >>>> + .nr_to_write = LONG_MAX, >>> >>> By setting a nr_to_write you still write out data (at least in theory). >>> >> >> So when do I also sync the data? is that done for me at the VFS layer? > > You never have to. vfs_fsync_range does the data writeout for you. > >>> I'd recommend just copying the code from generic_file_fsync.. >>> >> >> I was actually mimicking the code from nfs/write.c which has similar >> semantics as mine. > > nfs code has no good reason to do that, at least when called from > ->fsync. > >> And if so then I'll need to not reuse the above in .flush > > I would recommend keeping the ->flush code separate. OK, ... I think I got it this time. (I hope) And you are totally right. The ->flush code is called without any locks and the ->fsync is called with i_mutex held. So the previous code was totally racy for ->flush. Boaz