From: Josef Bacik <jbacik@fb.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"david@fromorbit.com" <david@fromorbit.com>,
"hch@lst.de" <hch@lst.de>
Subject: Re: Simulating disk failure with a writeback cache
Date: Mon, 19 Dec 2016 12:58:31 +0000 [thread overview]
Message-ID: <0B760184-EEEB-473C-8A97-54713BEA78CA@fb.com> (raw)
In-Reply-To: <20161219030725.3kmsfu23sjypcnek@kmo-pixel>
> On Dec 18, 2016, at 10:07 PM, Kent Overstreet <kent.overstreet@gmail.com> wrote:
>
>> On Sun, Dec 18, 2016 at 05:51:11PM -0900, Kent Overstreet wrote:
>>> On Sun, Dec 18, 2016 at 09:19:57PM +0000, Josef Bacik wrote:
>>> Eeesh these are older than I thought, I pushed to
>>> https://github.com/josefbacik/fstests.git. The fsx work is there and is
>>> generic, the fsstress one has some btrfs specific stuff but you can just pull
>>> that crap out and it'll work on anything. Let me know if you need anything
>>> else, thanks,
>>
>> Thanks
>>
>> I got your first fsx based test up and running, but - did you get it to pass
>> with any existing filesystems?
>>
>> I finally figured out what I'm seeing, in _check_files() where it's looping over
>> the mark: I changed it to so that it always checks the fsync marks in the order
>> where it was created, but when it goes to check the very first mark it's getting
>> the very last version of the file (at least, the file size is consistent with
>> that).
>>
>> I just pushed what I'm working off of, but I don't think it's anything I
>> broke...
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__evilpiepirate.org_git_xfstests.git&d=DgIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=sDzg6MvHymKOUgI8SFIm4Q&m=E_8Rycs0b-Vo8GLKPW3XOah6HMo1P1ixJKC56-np3BQ&s=xABKM88GhCUwdBnB8_7bzZM76O0U9tnQdK6p40kdXtU&e=
>
> Just figured it out - log replay doesn't touch anything that hadn't been written
> at that point in the log, so the newer journal entries were still there. fun...
>
> If I blow away the journal before replay, it works.
I'm confused, are you talking about the log writes log? Thanks,
Josef
next prev parent reply other threads:[~2016-12-19 12:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 2:26 Simulating disk failure with a writeback cache Kent Overstreet
2016-12-15 4:15 ` Josef Bacik
2016-12-18 20:12 ` Kent Overstreet
2016-12-18 20:38 ` Josef Bacik
2016-12-18 20:46 ` Kent Overstreet
2016-12-18 21:19 ` Josef Bacik
2016-12-19 2:51 ` Kent Overstreet
2016-12-19 3:07 ` Kent Overstreet
2016-12-19 12:58 ` Josef Bacik [this message]
2016-12-19 15:27 ` Josef Bacik
2016-12-19 20:55 ` Kent Overstreet
2016-12-19 21:00 ` Josef Bacik
2016-12-19 21:53 ` Kent Overstreet
2016-12-20 1:01 ` Josef Bacik
2016-12-20 1:30 ` Kent Overstreet
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=0B760184-EEEB-473C-8A97-54713BEA78CA@fb.com \
--to=jbacik@fb.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=kent.overstreet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
/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.