[lkml]   [2001]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 64 bit scsi read/write
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.167 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site