From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dkim1.fusionio.com ([66.114.96.53]:48704 "EHLO dkim1.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756548Ab3I3Urk (ORCPT ); Mon, 30 Sep 2013 16:47:40 -0400 Received: from mx2.fusionio.com (unknown [10.101.1.160]) by dkim1.fusionio.com (Postfix) with ESMTP id 5D8A47C0445 for ; Mon, 30 Sep 2013 14:47:40 -0600 (MDT) Date: Mon, 30 Sep 2013 16:47:38 -0400 From: Josef Bacik To: Aastha Mehta CC: Josef Bacik , linux-btrfs Subject: Re: Questions regarding logging upon fsync in btrfs Message-ID: <20130930204738.GB27490@localhost.localdomain> References: <20130929004252.GL18681@localhost.localdomain> <20130929131224.GM18681@localhost.localdomain> <20130930201125.GA27490@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Mon, Sep 30, 2013 at 10:30:59PM +0200, Aastha Mehta wrote: > On 30 September 2013 22:11, Josef Bacik wrote: > > On Mon, Sep 30, 2013 at 09:32:54PM +0200, Aastha Mehta wrote: > >> On 29 September 2013 15:12, Josef Bacik wrote: > >> > On Sun, Sep 29, 2013 at 11:22:36AM +0200, Aastha Mehta wrote: > >> >> Thank you very much for the reply. That clarifies a lot of things. > >> >> > >> >> I was trying a small test case that opens a file, writes a block of > >> >> data, calls fsync and then closes the file. If I understand correctly, > >> >> fsync would return only after all in-memory buffers have been > >> >> committed to disk. I have added few print statements in the > >> >> __extent_writepage function, and I notice that the function gets > >> >> called a bit later after fsync returns. It seems that I am not > >> >> guaranteed to see the data going to disk by the time fsync returns. > >> >> > >> >> Am I doing something wrong, or am I looking at the wrong place for > >> >> disk write? This happens both with tree logging enabled as well as > >> >> with notreelog. > >> >> > >> > > >> > So 3.1 was a long time ago and to be sure it had issues I don't think it was > >> > _that_ broken. You are probably better off instrumenting a recent kernel, 3.11 > >> > or just build btrfs-next from git. But if I were to make a guess I'd say that > >> > __extent_writepage was how both data and metadata was written out at the time (I > >> > don't think I changed it until 3.2 or something later) so what you are likely > >> > seeing is the normal transaction commit after the fsync. In the case of > >> > notreelog we are likely starting another transaction and you are seeing that > >> > commit (at the time the transaction kthread would start a transaction even if > >> > none had been started yet.) Thanks, > >> > > >> > Josef > >> > >> Is there any special handling for very small file write, less than 4K? As > >> I understand there is an optimization to inline the first extent in a file if > >> it is smaller than 4K, does it affect the writeback on fsync as well? I did > >> set the max_inline mount option to 0, but even then it seems there is > >> some difference in fsync behaviour for writing first extent of less than 4K > >> size and writing 4K or more. > >> > > > > Yeah if the file is an inline extent then it will be copied into the log > > directly and the log will be written out, no going through the data write path > > at all. Max inline == 0 should make it so we don't inline, so if it isn't > > honoring that then that may be a bug. Thanks, > > > > Josef > > I tried it on 3.12-rc2 release, and it seems there is a bug then. > Please find attached logs to confirm. > Also, probably on the older release. > Oooh ok I understand, you have your printk's in the wrong place ;). do_writepages doesn't necessarily mean you are writing something. If you want to see if stuff got written to the disk I'd put a printk at run_delalloc_range and have it spit out the range it is writing out since thats what we think is actually dirty. Thanks, Josef