Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 721256063A
Date:   Wed, 29 May 2019 09:37:58 +0530
From:   Sahitya Tummala <stummala@codeaurora.org>
To:     Theodore Ts'o <tytso@mit.edu>
Cc:     Andreas Dilger <adilger.kernel@dilger.ca>,
        linux-ext4@vger.kernel.org
Subject: Re: fsync_mode mount option for ext4
Message-ID: <20190529040757.GI10043@codeaurora.org>
References: <20190528032257.GF10043@codeaurora.org>
 <20190528034007.GA19149@mit.edu>
 <20190528034830.GH10043@codeaurora.org>
 <20190528131356.GB19149@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190528131356.GB19149@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Hi Ted,

On Tue, May 28, 2019 at 09:13:56AM -0400, Theodore Ts'o wrote:
> On Tue, May 28, 2019 at 09:18:30AM +0530, Sahitya Tummala wrote:
> > 
> > Yes, but fsync_mode=nobarrier is little different than
> > a general nobarrier option. The fsync_mode=nobarrier is
> > only controlling the flush policy for fsync() path, unlike
> > the nobarrier mount option which is applicable at all
> > places in the filesystem.
> 
> What are you really trying to accomplish with fsync_mode=nobarrier?
> And when does that distinction have a difference?
> 

Thanks for your time and reply on this.

Here is what I think on these mount options. Please correct me if my
understanding is wrong.

The nobarrier mount option poses risk even if there is a battery
protection against sudden power down, as it doesn't guarantee the ordering
of important data such as journal writes on the disk. On the storage
devices with internal cache, if the cache flush policy is out-of-order,
then the places where FS is trying to enforce barriers will be at risk,
causing FS to be inconsistent. 

But whereas with fsync_mode=nobarrier, FS is not trying to enforce
any ordering of data on the disk except to ensure the data is flushed
from the internal cache to non-volatile memory. Thus, I see this
fsync_mode=nobarrier is much better than a general nobarrier. And it
provides better performance too as with nobarrier but without
compromising much on FS consistency. 

I do agree with all your points below on sudden power down scenarios,
but if someone wants to take a risk, then I think fsync_mode=nobarrier
may be better to enable based on their need/perf requirements.

Thanks,

> What sort of guarantees are you trying to offer, given a particular
> hardware and software design?
> 
> I gather that fsync_mode=nobarrier means one of two things:
> 
>   * "screw you, application writer; your data consistency means nothing to me",
> 
> OR
> 
>   * "we have sufficient guarantees --- e.g., UPS/battery protection to
>     guarantee that even if we lose AC mains, or the user press and holds
>     the power button for eight seconds, we will give storage devices a
>     sufficient grace period to write everything to persistent storage.  We
>     also have the appropriate hardware to warn of an impending low-battery
>     shutdown and software to perform a graceful shutdown in that eventuality."
> 
> If it's the latter, then nobarrier works just as well --- even better.
> 
> If it's the former, *why* is it considered a good thing to ignore the
> requests of userspace?  And without any hardware assurances to provide
> a backstop against power drop, do you care or not care about file
> system consistency?
> 
> Why do you want the distinction between fsymc_mode=nobarrier and
> nobarrier?  When would this distinction be considered a good thing?
> 
> 	    	       	    		   - Ted
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.