From: Josef Bacik <jbacik@fb.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: <linux-btrfs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<dm-devel@redhat.com>, <zab@redhat.com>,
<fstests@vger.kernel.org>
Subject: Re: [dm-devel] [PATCH 1/3] dm: log writes target
Date: Tue, 7 Apr 2015 10:45:52 -0400 [thread overview]
Message-ID: <5523EDA0.9080504@fb.com> (raw)
In-Reply-To: <20150323180245.GE3172@redhat.com>
On 03/23/2015 02:02 PM, Vivek Goyal wrote:
> On Thu, Mar 19, 2015 at 04:31:08PM -0400, Josef Bacik wrote:
>
> [..]
>> + * We log writes only after they have been flushed, this makes the log describe
>> + * close to the order in which the data hits the actual disk, not its cache. So
>> + * for example the following sequence (W means write, C means complete)
>> + *
>> + * Wa,Wb,Wc,Cc,Ca,FLUSH,FUAd,Cb,CFLUSH,CFUAd
>> + *
>> + * Would result in the log looking like this
>> + *
>> + * c,a,flush,fuad,b,<other writes>,<next flush>
>> + *
>
> A minor nit, Should this sequence be following.
>
> c,a,b, flush,fuad,<other writes>,<next flush>
>
> when flush completed by that time write of b has completed too. So it
> should be written first?
>
So we want to catch file systems behaving badly by not waiting for the
IO they care about to complete before issuing their flush, so we take
the super pessimistic view that only IO that has completed by FLUSH
issue time can truly be safe. For all we know the flush could have
happened first and we just happen to get the endio called for b first
instead of the flush, so to make it mostly likely that we catch fs bugs
we enforce this idea that only completed IO can be sure to have been
flushed at flush submit time. Thanks,
Josef
next prev parent reply other threads:[~2015-04-07 14:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 20:31 [PATCH 0/3] Device mapper log writes patches Josef Bacik
2015-03-19 20:31 ` [PATCH 1/3] dm: log writes target Josef Bacik
2015-03-19 23:16 ` Zach Brown
2015-03-20 14:50 ` [PATCH 1/3] dm: log writes target V2 Josef Bacik
2015-03-20 16:31 ` Zach Brown
2015-03-24 15:33 ` Mike Snitzer
2015-04-07 14:41 ` Josef Bacik
2015-03-21 21:50 ` [PATCH 1/3] dm: log writes target Dave Chinner
2015-04-07 14:43 ` Josef Bacik
2015-03-23 18:02 ` [dm-devel] " Vivek Goyal
2015-04-07 14:45 ` Josef Bacik [this message]
2015-03-19 20:31 ` [PATCH 2/3] fstests: add dm-log-writes test and supporting code Josef Bacik
2015-03-19 20:31 ` [PATCH 3/3] fstests: btrfs balance with dm log writes test Josef Bacik
2015-03-25 10:35 ` Filipe David Manana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5523EDA0.9080504@fb.com \
--to=jbacik@fb.com \
--cc=dm-devel@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=zab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).