From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 30 Aug 2017 16:21:34 +0200 From: Christoph Hellwig To: Amir Goldstein Cc: Christoph Hellwig , "Darrick J . Wong" , Dave Chinner , linux-xfs , linux-fsdevel , Josef Bacik , stable Subject: Re: [PATCH] xfs: fix incorrect log_flushed on fsync Message-ID: <20170830142134.GA650@lst.de> References: <1504100302-3297-1-git-send-email-amir73il@gmail.com> <20170830134629.GA32355@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Aug 30, 2017 at 05:12:10PM +0300, Amir Goldstein wrote: > On Wed, Aug 30, 2017 at 4:46 PM, Christoph Hellwig wrote: > > Oops. > > > > Yes, except for the case of calling xlog_state_release_iclog > > ourselves we can't claim that the cache has been flushed. In > > fact I'm not even sure that is save, if ic_refcnt makes > > xlog_state_release_iclog exit early, so we might have to > > pass additional information around there. > > With this change, for the multiple fsyncing tasks workload, the majority won't > be optimized, so the remaining code is only really optimizing the single > process doing seldom fsync case. > > I wonder if it's worth keeping the optimization around at all? I think it is. And we should get back to optimizing the multi-threaded cases soon using something like a sequence counter that checks if we issued a log sync after finishing the data writeback.