From: Daniel Phillips <phillips@bonn-fries.net>
To: Andrew Morton <andrewm@uow.edu.au>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-lvm@sistina.com
Subject: [linux-lvm] Re: [PATCH] 64 bit scsi read/write
Date: Sun, 15 Jul 2001 03:53:54 +0200 [thread overview]
Message-ID: <01071503535411.00409@starship> (raw)
In-Reply-To: <3B50F000.53EAB651@uow.edu.au>
On Sunday 15 July 2001 03:21, Andrew Morton wrote:
> Daniel Phillips wrote:
> > On Saturday 14 July 2001 16:50, Chris Wedgwood wrote:
> > > On Sat, Jul 14, 2001 at 09:45:44AM +0100, Alan Cox wrote:
> > >
> > > As far as I can tell none of them at least in the IDE world
> > >
> > > SCSI disk must, or at least some... if not, how to peopel like
> > > NetApp get these cool HA certifications?
> >
> > Atomic commit. The superblock, which references the updated
> > version of the filesystem, carries a sequence number and a
> > checksum. It is written to one of two alternating locations. On
> > restart, both locations are read and the highest numbered
> > superblock with a correct checksum is chosen as the new filesystem
> > root.
>
> But this assumes that it is the most-recently-written sector/block
> which gets lost in a power failure.
>
> The disk will be reordering writes - so when it fails it may have
> written the commit block but *not* the data which that block is
> committing.
>
> You need a barrier or a full synchronous flush prior to writing
> the commit block. A `don't-reorder-past-me' barrier is very much
> preferable, of course.
Oh yes, absolutely, that's very much part of the puzzle. Any disk
that doesn't support a real write barrier or write cache flush is
fundamentally broken as far as failsafe operation goes. A disk that
claims to provide such support and doesn't is an even worse offender.
I find Alan's comment there worrisome. We need to know which disks
devliver on this and which don't.
--
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Phillips <phillips@bonn-fries.net>
To: Andrew Morton <andrewm@uow.edu.au>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-lvm@sistina.com
Subject: Re: [PATCH] 64 bit scsi read/write
Date: Sun, 15 Jul 2001 03:53:54 +0200 [thread overview]
Message-ID: <01071503535411.00409@starship> (raw)
In-Reply-To: <E15LL3Y-0000yJ-00@the-village.bc.nu> <0107142211300W.00409@starship> <3B50F000.53EAB651@uow.edu.au>
In-Reply-To: <3B50F000.53EAB651@uow.edu.au>
On Sunday 15 July 2001 03:21, Andrew Morton wrote:
> Daniel Phillips wrote:
> > On Saturday 14 July 2001 16:50, Chris Wedgwood wrote:
> > > On Sat, Jul 14, 2001 at 09:45:44AM +0100, Alan Cox wrote:
> > >
> > > As far as I can tell none of them at least in the IDE world
> > >
> > > SCSI disk must, or at least some... if not, how to peopel like
> > > NetApp get these cool HA certifications?
> >
> > Atomic commit. The superblock, which references the updated
> > version of the filesystem, carries a sequence number and a
> > checksum. It is written to one of two alternating locations. On
> > restart, both locations are read and the highest numbered
> > superblock with a correct checksum is chosen as the new filesystem
> > root.
>
> But this assumes that it is the most-recently-written sector/block
> which gets lost in a power failure.
>
> The disk will be reordering writes - so when it fails it may have
> written the commit block but *not* the data which that block is
> committing.
>
> You need a barrier or a full synchronous flush prior to writing
> the commit block. A `don't-reorder-past-me' barrier is very much
> preferable, of course.
Oh yes, absolutely, that's very much part of the puzzle. Any disk
that doesn't support a real write barrier or write cache flush is
fundamentally broken as far as failsafe operation goes. A disk that
claims to provide such support and doesn't is an even worse offender.
I find Alan's comment there worrisome. We need to know which disks
devliver on this and which don't.
--
Daniel
next prev parent reply other threads:[~2001-07-15 1:53 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-01 4:53 [RFC][PATCH] first cut 64 bit block support Ben LaHaise
2001-07-03 4:53 ` Ragnar Kjørstad
2001-07-04 2:19 ` [PATCH] 64 bit scsi read/write Ben LaHaise
2001-07-04 7:11 ` Alan Cox
2001-07-05 6:34 ` [linux-lvm] " Ragnar Kjørstad
2001-07-05 6:34 ` Ragnar Kjørstad
2001-07-05 7:35 ` [linux-lvm] " Ben LaHaise
2001-07-05 7:35 ` Ben LaHaise
2001-07-05 16:46 ` [linux-lvm] " AJ Lewis
2001-07-05 17:09 ` Eric M. Hopper
2001-07-10 13:45 ` Heinz J. Mauelshagen
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 20:41 ` [linux-lvm] " Andreas Dilger
2001-07-13 20:41 ` Andreas Dilger
2001-07-13 21:07 ` Chris Wedgwood
2001-07-13 22:04 ` [linux-lvm] " Andreas Dilger
2001-07-13 22:04 ` Andreas Dilger
2001-07-14 0:49 ` [linux-lvm] " Jonathan Lundell
2001-07-14 0:49 ` Jonathan Lundell
2001-07-14 12:27 ` Paul Jakma
2001-07-14 14:48 ` Chris Wedgwood
2001-07-14 15:42 ` Paul Jakma
2001-07-14 17:18 ` Chris Wedgwood
2001-07-20 17:03 ` Stephen C. Tweedie
2001-07-16 18:53 ` Andreas Dilger
2001-07-16 19:13 ` Ragnar Kjørstad
2001-07-13 21:14 ` [linux-lvm] " Alan Cox
2001-07-13 21:14 ` Alan Cox
2001-07-14 3:23 ` [linux-lvm] " Andrew Morton
2001-07-14 3:23 ` Andrew Morton
2001-07-14 8:45 ` [linux-lvm] " Alan Cox
2001-07-14 8:45 ` Alan Cox
2001-07-14 13:54 ` [linux-lvm] " Steven Lembark
2001-07-14 14:50 ` Chris Wedgwood
2001-07-14 15:41 ` [linux-lvm] " Jonathan Lundell
2001-07-14 15:41 ` Jonathan Lundell
2001-07-14 17:00 ` Chris Wedgwood
2001-07-14 20:11 ` [linux-lvm] " Daniel Phillips
2001-07-14 20:11 ` Daniel Phillips
2001-07-15 1:21 ` [linux-lvm] " Andrew Morton
2001-07-15 1:21 ` Andrew Morton
2001-07-15 1:53 ` Daniel Phillips [this message]
2001-07-15 1:53 ` Daniel Phillips
2001-07-15 3:36 ` Chris Wedgwood
2001-07-15 6:05 ` [linux-lvm] " John Alvord
2001-07-15 6:05 ` John Alvord
2001-07-15 6:07 ` Chris Wedgwood
2001-07-15 13:16 ` [linux-lvm] " Ken Hirsch
2001-07-15 13:16 ` Ken Hirsch
2001-07-15 14:50 ` Chris Wedgwood
2001-07-15 22:14 ` [linux-lvm] " Daniel Phillips
2001-07-15 22:14 ` Daniel Phillips
2001-07-17 0:31 ` [linux-lvm] " Juan Quintela
2001-07-17 0:31 ` Juan Quintela
2001-07-15 13:44 ` [linux-lvm] " Daniel Phillips
2001-07-15 13:44 ` Daniel Phillips
2001-07-15 14:39 ` Chris Wedgwood
2001-07-15 15:06 ` [linux-lvm] " Jonathan Lundell
2001-07-15 15:06 ` Jonathan Lundell
2001-07-15 15:22 ` Chris Wedgwood
2001-07-15 17:44 ` [linux-lvm] " Jonathan Lundell
2001-07-15 17:44 ` Jonathan Lundell
2001-07-15 17:47 ` [linux-lvm] " Justin T. Gibbs
2001-07-15 17:47 ` Justin T. Gibbs
2001-07-15 23:14 ` [linux-lvm] " Rod Van Meter
2001-07-15 23:14 ` Rod Van Meter
2001-07-16 0:37 ` Jonathan Lundell
2001-07-16 15:11 ` Rod Van Meter
2001-07-16 8:56 ` Chris Wedgwood
2001-07-16 13:19 ` [linux-lvm] " Daniel Phillips
2001-07-16 13:19 ` Daniel Phillips
2001-07-16 14:26 ` [linux-lvm] " Heinz J. Mauelshagen
2001-07-15 15:32 ` Alan Cox
2001-07-15 15:32 ` Alan Cox
2001-07-15 15:33 ` Chris Wedgwood
2001-07-15 16:24 ` Chris Wedgwood
2001-07-16 1:08 ` Albert D. Cahalan
2001-07-16 8:49 ` Chris Wedgwood
2001-07-21 19:18 ` Alexander Griesser
2001-07-22 3:52 ` Albert D. Cahalan
2001-07-23 14:41 ` Daniel Phillips
2001-07-24 4:29 ` Albert D. Cahalan
2001-07-24 11:45 ` Daniel Phillips
2001-07-14 17:33 ` [linux-lvm] " Jonathan Lundell
2001-07-14 17:33 ` Jonathan Lundell
2001-07-15 4:02 ` Chris Wedgwood
2001-07-15 5:46 ` [linux-lvm] " Jonathan Lundell
2001-07-15 5:46 ` Jonathan Lundell
2001-07-15 17:10 ` Chris Wedgwood
2001-07-15 17:39 ` Jonathan Lundell
2001-07-26 2:18 ` Ragnar Kjørstad
2001-07-26 16:24 ` Andreas Dilger
2001-08-10 19:42 ` Ben LaHaise
2001-08-10 19:51 ` Ragnar Kjørstad
2001-08-10 20:02 ` Ben LaHaise
2001-08-11 0:18 ` Steve Lord
2001-08-11 21:44 ` Matti Aarnio
2001-07-04 10:16 ` [RFC][PATCH] first cut 64 bit block support Chris Wedgwood
2001-07-04 16:59 ` Ben LaHaise
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=01071503535411.00409@starship \
--to=phillips@bonn-fries.net \
--cc=andrewm@uow.edu.au \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@sistina.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.