Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Feb 2003 12:57:16 +1030
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Steve Byan <stephen_byan@maxtor.com>
Cc:        phk@freebsd.org, freebsd-fs@freebsd.org, tech-kern@netbsd.org
Subject:   Track buffering (was: DEV_B_SIZE)
Message-ID:  <20030201022716.GO92530@wantadilla.lemis.com>
In-Reply-To: <F4D99E08-353D-11D7-B26B-00306548867E@maxtor.com>
References:  <2639.1044031853@critter.freebsd.dk> <F4D99E08-353D-11D7-B26B-00306548867E@maxtor.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 31 January 2003 at 12:03:44 -0500, Steve Byan wrote:
>
> On Friday, January 31, 2003, at 11:50  AM, phk@freebsd.org wrote:
>> It was my impression that already many drives write entire tracks
>> as atomic units, at least we have had plenty of anecdotal evidence
>> to this effect ?
>
> I'm not aware of any SCSI or ATA disks which do this; certainly no
> Maxtor disk does. Count-key-data mainframe disks can be formatted to do
> so, but such disks probably don't run Unix. Caching in ATA disks might
> lead one to believe that the disk could corrupt an entire track, in the
> sense that a panic ( aka bluescreen) or a power-failure would cause all
> pending writes in its buffer to be lost, but even in ATA-land I don't
> believe a power failure would result in more than one disk block
> returning an uncorrectable read error.

A couple of years back I did some power fail testing on IBM IDE
drives.  On one occasion I managed to blow out a whole range of
sectors (about 80), which I attributed to trashing a track buffer.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030201022716.GO92530>