From: Chris Mason <clm@fb.com>
To: Josef Bacik <jbacik@fb.com>
Cc: Zach Brown <zab@redhat.com>,
linux-btrfs@vger.kernel.org, david@fromorbit.com,
sandeen@redhat.com, dm-devel@redhat.com, hch@infradead.org,
linux-fsdevel@vger.kernel.org, tytso@mit.edu
Subject: Re: [RFC][PATCH] dm: add dm-power-fail target
Date: Mon, 24 Nov 2014 15:18:50 -0500 [thread overview]
Message-ID: <1416860330.3019.7@mail.thefacebook.com> (raw)
In-Reply-To: <547391DD.30406@fb.com>
On Mon, Nov 24, 2014 at 3:15 PM, Josef Bacik <jbacik@fb.com> wrote:
> On 11/24/2014 02:57 PM, Zach Brown wrote:
>
> That is way complicated, I was just going to take two devices, one
> that's a linear mapping and the other that's the log, and then write
> to the log the sector+data that was written in order that it
> completes, and then have userspace do the replay. So basically do
> the flush tracking like I am, then write out chunks to the log device
> to keep a semblance of how the flushing would have affected stuff,
> something like this
>
> write a, write b, a complete, flush, b complete, flush complete
>
> would log out
>
> wrote a, flush, write b, <other writes>, <next flush>
>
> and then we have a userspace thing that could do something like
> replay all writes to a flush, do fs consistency and data consistency
> checks, walk to the next flush, rinse repeat, and that way we could
> be sure that we always have a consistent fs. This would make it
> easier to check complex fs operations (like btrfs's balance) without
> having to come up with special hacks in those operations to check
> them. I like this better because it's less DM code which means less
> swearing printks, but whichever we think will be the best thing for
> this sort of testing. Thanks,
I vote for whatever is the easiest to fit in our little programmer
brains. The more complex the tool, the less we'll trust it.
-chris
WARNING: multiple messages have this Message-ID (diff)
From: Chris Mason <clm@fb.com>
To: Josef Bacik <jbacik@fb.com>
Cc: Zach Brown <zab@redhat.com>, <linux-btrfs@vger.kernel.org>,
<david@fromorbit.com>, <sandeen@redhat.com>,
<dm-devel@redhat.com>, <hch@infradead.org>,
<linux-fsdevel@vger.kernel.org>, <tytso@mit.edu>
Subject: Re: [RFC][PATCH] dm: add dm-power-fail target
Date: Mon, 24 Nov 2014 15:18:50 -0500 [thread overview]
Message-ID: <1416860330.3019.7@mail.thefacebook.com> (raw)
In-Reply-To: <547391DD.30406@fb.com>
On Mon, Nov 24, 2014 at 3:15 PM, Josef Bacik <jbacik@fb.com> wrote:
> On 11/24/2014 02:57 PM, Zach Brown wrote:
>
> That is way complicated, I was just going to take two devices, one
> that's a linear mapping and the other that's the log, and then write
> to the log the sector+data that was written in order that it
> completes, and then have userspace do the replay. So basically do
> the flush tracking like I am, then write out chunks to the log device
> to keep a semblance of how the flushing would have affected stuff,
> something like this
>
> write a, write b, a complete, flush, b complete, flush complete
>
> would log out
>
> wrote a, flush, write b, <other writes>, <next flush>
>
> and then we have a userspace thing that could do something like
> replay all writes to a flush, do fs consistency and data consistency
> checks, walk to the next flush, rinse repeat, and that way we could
> be sure that we always have a consistent fs. This would make it
> easier to check complex fs operations (like btrfs's balance) without
> having to come up with special hacks in those operations to check
> them. I like this better because it's less DM code which means less
> swearing printks, but whichever we think will be the best thing for
> this sort of testing. Thanks,
I vote for whatever is the easiest to fit in our little programmer
brains. The more complex the tool, the less we'll trust it.
-chris
next prev parent reply other threads:[~2014-11-24 20:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 22:00 [RFC][PATCH] dm: add dm-power-fail target Josef Bacik
2014-11-21 22:00 ` Josef Bacik
2014-11-24 18:45 ` Zach Brown
2014-11-24 19:04 ` Josef Bacik
2014-11-24 19:04 ` Josef Bacik
2014-11-24 19:57 ` Zach Brown
2014-11-24 20:15 ` Josef Bacik
2014-11-24 20:15 ` Josef Bacik
2014-11-24 20:18 ` Chris Mason [this message]
2014-11-24 20:18 ` Chris Mason
2014-11-24 22:10 ` Zach Brown
2014-11-24 22:21 ` Josef Bacik
2014-11-24 22:21 ` Josef Bacik
2014-11-24 22:35 ` Zach Brown
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=1416860330.3019.7@mail.thefacebook.com \
--to=clm@fb.com \
--cc=david@fromorbit.com \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.