From: Chris Mason <chris.mason@oracle.com>
To: Mike Fedyk <mfedyk@mikefedyk.com>
Cc: Bill Pemberton <wfp5p@viridian.itc.virginia.edu>,
linux-btrfs@vger.kernel.org
Subject: Re: assertion failures
Date: Fri, 26 Feb 2010 14:15:44 -0500 [thread overview]
Message-ID: <20100226191544.GK12841@think> (raw)
In-Reply-To: <93cdabd21002261111v211e77e6ic789a2487461a420@mail.gmail.com>
On Fri, Feb 26, 2010 at 11:11:07AM -0800, Mike Fedyk wrote:
> On Fri, Feb 26, 2010 at 10:11 AM, Bill Pemberton
> <wfp5p@viridian.itc.virginia.edu> wrote:
> >>
> >> Does the array have any kind of writeback cache?
> >>
> >
> > Yes, the array has a writeback cache.
> >
> >>
> >> Are all of the filesystems spread across all of the drives? =A0Or =
do some
> >> filesystems use some drives only?
> >>
> >
> > In all cases the array is presenting 1 physical volume to the host
> > system (which is RAID 6 on the array itself). =A0That physical volu=
me is
> > made into a volume group and the filesystems are on logical volumes=
in
> > that volume group.
> >
>=20
> I wonder if the barrier messages are making it to this write back
> cache. Do you see any messages about barriers in your kernel logs?
Most drives with writeback caches will honor the barriers. Most arrays
with writeback caches will ignore them. Usually they also have their
own battery backup, which should be safe enough to continue using the
writeback cache.
But, that depends on the array.
Bill, I've got a great little application that you can use to test the
safety of the array against power failures. You'll have to pull the
plug on the poor machine about 10 times to be sure, just let me know if
you're interested.
If the raid array works, the power failure test won't hurt any of the
existing filesystems. If not, it's possible they will all get
corrupted, so I wouldn't blame you for not wanting to run it.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-02-26 19:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-24 13:45 assertion failures Bill Pemberton
2010-02-25 0:40 ` Chris Mason
2010-02-25 14:04 ` Bill Pemberton
2010-02-25 18:28 ` Gustavo Alves
2010-02-26 16:13 ` Chris Mason
2010-02-26 16:15 ` Chris Mason
2010-02-26 19:57 ` Gustavo Alves
2010-02-26 21:10 ` Chris Mason
2010-02-26 21:26 ` Gustavo Alves
2010-02-26 16:17 ` Chris Mason
2010-02-26 16:41 ` Bill Pemberton
2010-02-26 17:59 ` Chris Mason
2010-02-26 18:11 ` Bill Pemberton
2010-02-26 19:09 ` Chris Mason
2010-02-26 20:43 ` Bill Pemberton
2010-02-26 20:49 ` Diego Calleja
2010-02-26 21:08 ` Chris Mason
2010-02-28 3:05 ` Cláudio Martins
2010-02-26 19:11 ` Mike Fedyk
2010-02-26 19:15 ` Chris Mason [this message]
2010-02-26 20:45 ` Bill Pemberton
2010-02-26 20:53 ` Chris Mason
2010-02-27 22:56 ` Bill Pemberton
2010-02-26 20:44 ` Bill Pemberton
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=20100226191544.GK12841@think \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mfedyk@mikefedyk.com \
--cc=wfp5p@viridian.itc.virginia.edu \
/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