All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Josef Bacik <josef@redhat.com>
Cc: Paul Schroeder <prq@safe-mail.net>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: How to know whether disks "handle flush requests correctly"
Date: Fri, 06 May 2011 09:48:32 -0400	[thread overview]
Message-ID: <1304688928-sup-8382@think> (raw)
In-Reply-To: <4DC3F33F.80309@redhat.com>

Excerpts from Josef Bacik's message of 2011-05-06 09:10:23 -0400:
> On 05/06/2011 05:13 AM, Paul Schroeder wrote:
> > The btrfs wiki Main Page warns that "it is currently possible to corrupt
> > a filesystem irrecoverably if your machine crashes or loses power on disks
> > that don't handle flush requests correctly."
> >
> > How do you know if this applies to your drives? Is there a way to test it,
> > or a model list, or are newer SATA drives (magnetic, not SSDs) always ok?
> > Does it depend on the controller? (I have a SiI 3114, latest BIOS.)
> >
> > I would also be using btrfs on top of dm-crypt (with the latest release
> > kernel). Some kernel versions ago, the message that write barriers aren't
> > supported disappeared; can I assume the device mapper / dm-crypt is not a
> > problem with regards to flushing?
> >
> 
> Yeah if you don't see those messages you can be fairly certain you are 
> ok.  Thanks,

The easiest way to tell for sure is to do two tests:

dd if=/dev/zero of=/mnt/foo bs=4K count=10000
dd if=/dev/zero of=/mnt/foo bs=4K count=10000 oflag=sync

Run this with the filesystem mounted normally and again with the
filesystem mounted -o nobarrier.  -o nobarrier should be dramatically
and hugely faster, almost like we're not writing to the disk at all.

-chris

      reply	other threads:[~2011-05-06 13:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-06  9:13 How to know whether disks "handle flush requests correctly" Paul Schroeder
2011-05-06 13:10 ` Josef Bacik
2011-05-06 13:48   ` Chris Mason [this message]

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=1304688928-sup-8382@think \
    --to=chris.mason@oracle.com \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=prq@safe-mail.net \
    /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.