From: Chris Mason <chris.mason@fusionio.com>
To: Chris Mason <clmason@fusionio.com>
Cc: "Richard W.M. Jones" <rjones@redhat.com>,
Josef Bacik <JBacik@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: What can I do to make btrfs work?
Date: Fri, 15 Feb 2013 13:38:11 -0500 [thread overview]
Message-ID: <20130215183811.GB28851@shiny.masoncoding.com> (raw)
In-Reply-To: <20130213133137.GA21623@shiny.masoncoding.com>
On Wed, Feb 13, 2013 at 06:31:37AM -0700, Chris Mason wrote:
> On Wed, Feb 13, 2013 at 06:10:44AM -0700, Richard W.M. Jones wrote:
> > On Wed, Feb 13, 2013 at 11:00:33AM +0000, Richard W.M. Jones wrote:
> > > Will try the btrfsprogs patch next.
> >
> > I applied this patch:
> >
> > https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=commitdiff_plain;h=8fe354744cd7b5c4f7a3314dcdbb5095192a032f
> >
> > to the version of btrfs-progs in Fedora Rawhide (currently
> > "0.20.rc1.20121017git91d9eec"). Then I ran the simple reproducer, and
> > the full libguestfs test suite on two machines.
> >
> > This does appear to fix the problem for me, but only on Rawhide.
> >
> > On Fedora 18 which has an older kernel, the patch does not fix the
> > problem (same errors as before).
> >
> > Rawhide kernel: kernel-3.8.0-0.rc7.git0.1.fc19.x86_64
> >
> > Fedora 18 kernel: kernel-3.7.6-201.fc18.x86_64
> >
> > Anyway, it's an improvement so I'll make sure the patch is added to
> > the Rawhide btrfs-progs package.
>
> Ok, the patch is more of a bandaid, but between running my vtest program
> and the patch helping, we're clearly not clearing caches properly
> (somehow). I'll take another stab at fixing this on the kernel side.
Looks like the real problem is the udev event to register a new btrfs
filesystem is racing in while we are still in mkfs. If you disable the
udev rule, the problem goes away (at least for me).
It's not a udev bug though, our btrfs scanning function is improperly
calling set_blocksize during a simple scan. That's only legal when we
are in mount and can't be racing with writes to the device.
Dave Sterba cooked up a fix for that, I'm testing it here.
-chris
next prev parent reply other threads:[~2013-02-15 18:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 18:54 What can I do to make btrfs work? Richard W.M. Jones
2013-02-12 19:02 ` Chris Mason
2013-02-12 19:16 ` Josef Bacik
2013-02-12 21:05 ` Richard W.M. Jones
2013-02-12 21:42 ` Chris Mason
2013-02-13 11:00 ` Richard W.M. Jones
2013-02-13 13:10 ` Richard W.M. Jones
2013-02-13 13:31 ` Chris Mason
2013-02-15 18:38 ` Chris Mason [this message]
2013-02-12 19:44 ` Zach Brown
2013-02-12 21:06 ` Richard W.M. Jones
2013-02-12 20:08 ` Roman Mamedov
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=20130215183811.GB28851@shiny.masoncoding.com \
--to=chris.mason@fusionio.com \
--cc=JBacik@fusionio.com \
--cc=clmason@fusionio.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rjones@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.