All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <ric@emc.com>
To: Molle Bestefich <molle.bestefich@gmail.com>
Cc: NeilBrown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: [PATCH 003 of 5] md: Change ENOTSUPP to EOPNOTSUPP
Date: Fri, 28 Apr 2006 12:48:37 -0400	[thread overview]
Message-ID: <44524765.6070703@emc.com> (raw)
In-Reply-To: <62b0912f0604280634x7df2a8a5m9022826876446cb6@mail.gmail.com>



Molle Bestefich wrote:

> NeilBrown wrote:
>
>> Change ENOTSUPP to EOPNOTSUPP
>> Because that is what you get if a BIO_RW_BARRIER isn't supported !
>
>
> Dumb question, hope someone can answer it :).
>
> Does this mean that any version of MD up till now won't know that SATA
> disks does not support barriers, and therefore won't flush SATA disks
> and therefore I need to disable the disks's write cache if I want to
> be 100% sure that raid arrays are not corrupted?
>
> Or am I way off :-).
>
You are absolutely right - if you do not have a validated, working 
barrier for your low level devices (or a high end, battery backed array 
or JBOD), you should disable the write cache on your RAIDed partitions 
and on your normal file systems ;-)

There is working support for SCSI (or libata S-ATA) barrier operations 
in mainline, but they conflict with queue enable targets which ends up 
leaving queuing on and disabling the barriers.

ric


  reply	other threads:[~2006-04-28 16:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-28  2:51 [PATCH 000 of 5] md: Introduction - assorted raid10/raid1 fixes NeilBrown
2006-04-28  2:50 ` [PATCH 001 of 5] md: Avoid oops when attempting to fix read errors on raid10 NeilBrown
2006-05-01 21:52   ` [stable] " Greg KH
2006-04-28  2:51 ` [PATCH 002 of 5] md: Fixed refcounting/locking when attempting read error correction in raid10 NeilBrown
2006-04-28  2:51 ` [PATCH 003 of 5] md: Change ENOTSUPP to EOPNOTSUPP NeilBrown
2006-04-28 13:34   ` Molle Bestefich
2006-04-28 16:48     ` Ric Wheeler [this message]
2006-04-29 13:50       ` Molle Bestefich
2006-04-29 20:23         ` Ric Wheeler
2006-05-01 16:14           ` Gil
2006-05-02  1:54             ` Paul Clements
2006-05-02  2:17               ` Mike Hardy
2006-05-02 11:37               ` Ric Wheeler
2006-04-30  4:13     ` [PATCH 003 of 5] " Neil Brown
2006-04-30  5:33       ` Guy
2006-04-30  6:00         ` Neil Brown
2006-04-28  2:51 ` [PATCH 004 of 5] md: Improve detection of lack of barrier support in raid1 NeilBrown
2006-04-28  2:51 ` [PATCH 005 of 5] md: Fix 'rdev->nr_pending' count when retrying barrier requests NeilBrown

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=44524765.6070703@emc.com \
    --to=ric@emc.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=molle.bestefich@gmail.com \
    --cc=neilb@suse.de \
    /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.