linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ric Wheeler <ric@emc.com>
To: Guy Watkins <linux-raid@watkins-home.com>
Cc: Valdis.Kletnieks@vt.edu, "'Tejun Heo'" <htejun@gmail.com>,
	david@lang.hm, "'Stefan Bader'" <Stefan.Bader@de.ibm.com>,
	"'Phillip Susi'" <psusi@cfl.rr.com>,
	"'device-mapper development'" <dm-devel@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-raid@vger.kernel.org,
	"'Jens Axboe'" <jens.axboe@oracle.com>,
	"'David Chinner'" <dgc@sgi.com>,
	"'Andreas Dilger'" <adilger@clusterfs.com>
Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Date: Fri, 13 Jul 2007 07:30:09 -0400	[thread overview]
Message-ID: <46976241.6040800@emc.com> (raw)
In-Reply-To: <200707122310.l6CNAoo08224@www.watkins-home.com>



Guy Watkins wrote:
> } -----Original Message-----
> } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> } owner@vger.kernel.org] On Behalf Of Valdis.Kletnieks@vt.edu
> } Sent: Thursday, July 12, 2007 1:35 PM
> } To: ric@emc.com
> } Cc: Tejun Heo; david@lang.hm; Stefan Bader; Phillip Susi; device-mapper
> } development; linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org;
> } linux-raid@vger.kernel.org; Jens Axboe; David Chinner; Andreas Dilger
> } Subject: Re: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for
> } devices, filesystems, and dm/md.
> } 
> } On Wed, 11 Jul 2007 18:44:21 EDT, Ric Wheeler said:
> } > Valdis.Kletnieks@vt.edu wrote:
> } > > On Tue, 10 Jul 2007 14:39:41 EDT, Ric Wheeler said:
> } > >
> } > >> All of the high end arrays have non-volatile cache (read, on power
> } loss, it is a
> } > >> promise that it will get all of your data out to permanent storage).
> } You don't
> } > >> need to ask this kind of array to drain the cache. In fact, it might
> } just ignore
> } > >> you if you send it that kind of request ;-)
> } > >
> } > > OK, I'll bite - how does the kernel know whether the other end of that
> } > > fiberchannel cable is attached to a DMX-3 or to some no-name product
> } that
> } > > may not have the same assurances?  Is there a "I'm a high-end array"
> } bit
> } > > in the sense data that I'm unaware of?
> } > >
> } >
> } > There are ways to query devices (think of hdparm -I in S-ATA/P-ATA
> } drives, SCSI
> } > has similar queries) to see what kind of device you are talking to. I am
> } not
> } > sure it is worth the trouble to do any automatic detection/handling of
> } this.
> } >
> } > In this specific case, it is more a case of when you attach a high end
> } (or
> } > mid-tier) device to a server, you should configure it without barriers
> } for its
> } > exported LUNs.
> } 
> } I don't have a problem with the sysadmin *telling* the system "the other
> } end of
> } that fiber cable has characteristics X, Y and Z".  What worried me was
> } that it
> } looked like conflating "device reported writeback cache" with "device
> } actually
> } has enough battery/hamster/whatever backup to flush everything on a power
> } loss".
> } (My back-of-envelope calculation shows for a worst-case of needing a 1ms
> } seek
> } for each 4K block, a 1G cache can take up to 4 1/2 minutes to sync.
> } That's
> } a lot of battery..)
> 
> Most hardware RAID devices I know of use the battery to save the cache while
> the power is off.  When the power is restored it flushes the cache to disk.
> If the power failure lasts longer than the batteries then the cache data is
> lost, but the batteries last 24+ hours I beleve.

Most mid-range and high end arrays actually use that battery to insure that data 
is all written out to permanent media when the power is lost. I won't go into 
how that is done, but it clearly would not be a safe assumption to assume that 
your power outage is only going to be a certain length of time (and if not, you 
would lose data).

> 
> A big EMC array we had had enough battery power to power about 400 disks
> while the 16 Gig of cache was flushed.  I think EMC told me the batteries
> would last about 20 minutes.  I don't recall if the array was usable during
> the 20 minutes.  We never tested a power failure.
> 
> Guy

I worked on the team that designed that big array.

At one point, we had an array on loan to a partner who tried to put it in a very 
small data center. A few weeks later, they brought in an electrician who needed 
to run more power into the center.  It was pretty funny - he tried to find a 
power button to turn it off and then just walked over and dropped power trying 
to get the Symm to turn off.  When that didn't work, he was really, really 
confused ;-)

ric

  reply	other threads:[~2007-07-13 11:30 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-25  7:58 [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md Neil Brown
2007-05-25 11:15 ` David Chinner
2007-05-25 11:49   ` Jens Axboe
2007-05-25 14:49     ` Phillip Susi
2007-05-28 18:32       ` [dm-devel] " Jens Axboe
2007-05-25 13:52 ` Stefan Bader
2007-05-28  1:37   ` Neil Brown
2007-05-29  9:12     ` Stefan Bader
2007-05-25 15:11 ` Phillip Susi
2007-05-26  1:03 ` Andreas Dilger
2007-05-26 10:27 ` Tejun Heo
2007-05-28  1:30 ` Neil Brown
2007-05-28  2:45   ` David Chinner
2007-05-28  2:57     ` Neil Brown
2007-05-28  4:29       ` David Chinner
2007-05-31  0:46         ` Neil Brown
2007-05-31  0:57           ` Alasdair G Kergon
2007-05-31  1:07           ` Alasdair G Kergon
2007-05-31  1:11             ` David Chinner
2007-05-28  4:48     ` Timothy Shimmin
2007-05-29  6:45       ` Jeremy Higdon
2007-05-29 20:03     ` Phillip Susi
2007-05-29 23:48       ` David Chinner
2007-05-30  0:01         ` david
2007-05-30  6:17           ` David Chinner
2007-05-30  8:55             ` Stefan Bader
2007-05-30 16:52             ` david
2007-05-31  0:20               ` David Chinner
2007-05-31  6:26                 ` Jens Axboe
2007-05-31  7:03                   ` David Chinner
2007-05-31  7:06                     ` Jens Axboe
2007-05-31 13:30                       ` Bill Davidsen
2007-05-31 13:36                         ` Jens Axboe
2007-06-01 16:04                           ` Bill Davidsen
2007-06-02 14:51                             ` Jens Axboe
2007-06-02 19:55                               ` Bill Davidsen
2007-06-01  3:16                       ` Tejun Heo
2007-06-01  8:21                         ` Jens Axboe
2007-06-02  9:20                           ` Tejun Heo
2007-06-02 14:34                             ` Jens Axboe
2007-06-02 22:57                               ` Guy Watkins
2007-06-04  7:39                               ` Tejun Heo
2007-05-31 18:31                     ` Phillip Susi
2007-05-31 19:00                       ` Jens Axboe
2007-05-31 19:21                         ` david
2007-05-31 19:40                           ` Jens Axboe
2007-05-31 23:34                       ` David Chinner
2007-06-01  5:59                         ` Neil Brown
2007-06-01  6:11                           ` Jens Axboe
2007-06-01  7:53                           ` David Chinner
2007-06-01 23:56                           ` Bill Davidsen
2007-05-31 18:24                 ` Phillip Susi
2007-05-30 16:45         ` Phillip Susi
2007-05-30 20:27           ` [dm-devel] " Phillip Susi
2007-05-31  6:24             ` Jens Axboe
2007-05-31 18:37               ` [dm-devel] " Phillip Susi
2007-05-31 18:58                 ` Jens Axboe
2007-06-02  0:04                   ` Bill Davidsen
2007-05-28  9:29   ` Tejun Heo
2007-05-28  9:43   ` Alasdair G Kergon
2007-05-29  9:25     ` [dm-devel] " Stefan Bader
2007-05-29 22:05       ` Alasdair G Kergon
2007-05-30  9:12         ` [dm-devel] " Stefan Bader
2007-05-30 10:41           ` Alasdair G Kergon
2007-05-30 16:55           ` Phillip Susi
2007-05-31 11:14             ` [dm-devel] " Stefan Bader
2007-06-01  3:25               ` Tejun Heo
2007-06-01  5:55                 ` david
2007-06-01  7:16                   ` [dm-devel] " Tejun Heo
2007-06-01 17:07                     ` Valdis.Kletnieks
2007-06-01 18:09                       ` Tejun Heo
2007-07-10 18:39                     ` Ric Wheeler
2007-07-10 23:40                       ` Valdis.Kletnieks
2007-07-11  2:49                         ` Tejun Heo
2007-07-11 22:44                         ` Ric Wheeler
2007-07-12 17:34                           ` Valdis.Kletnieks
2007-07-12 19:43                             ` Ric Wheeler
2007-07-12 23:10                             ` Guy Watkins
2007-07-13 11:30                               ` Ric Wheeler [this message]
2007-07-11  2:51                       ` Tejun Heo
2007-05-29 19:59   ` Phillip Susi
2007-05-31  0:22     ` Neil Brown
2007-05-30  9:35   ` Jens Axboe
2007-07-05 12:28     ` Tejun Heo
2007-07-09 12:27       ` Jens Axboe
2007-07-18 10:56     ` [PATCH] block: cosmetic changes Tejun Heo
2007-07-18 10:59       ` [PATCH] block: factor out bio_check_eod() Tejun Heo
2007-07-18 11:06         ` Jens Axboe
2007-07-18 11:18           ` Tejun Heo
2007-07-18 11:31             ` Jens Axboe
2007-07-18 11:33               ` Tejun Heo
2007-07-18 11:34                 ` Jens Axboe
2007-07-18 11:41                   ` Tejun Heo
2007-07-18 11:45                     ` Jens Axboe
2007-07-18 11:49                       ` Jens Axboe
2007-07-18 12:34                         ` Tejun Heo
2007-07-18 12:31                       ` Jens Axboe
2007-05-28 11:17 ` [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md Nikita Danilov
2007-05-31  3:31   ` Neil Brown
2007-05-28 14:43 ` Bill Davidsen
2007-05-31  0:37   ` Neil Brown
2007-05-31 12:28     ` Bill Davidsen

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=46976241.6040800@emc.com \
    --to=ric@emc.com \
    --cc=Stefan.Bader@de.ibm.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=adilger@clusterfs.com \
    --cc=david@lang.hm \
    --cc=dgc@sgi.com \
    --cc=dm-devel@redhat.com \
    --cc=htejun@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-raid@watkins-home.com \
    --cc=psusi@cfl.rr.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).