Re: Grown defects bei IDE / ATAPI

From: Sam van Ratt <sam.vanratt(at)gmx.net>
Date: Mon, 01 Sep 2003 19:31:55 +0200

Hallo Olli, hallo Bernd
es gibt immer gute und schlechte Serien, bei Dumping Herstellern
wie bei Namhaften. Die Spinpoint V (=7k2) ist auch in unseren FSC
PCs enthalten und die fallen schon recht gerne aus (~10% bei etwa
2k eingesetzten innerhalb eines Jahres). Persönlich habe ich die
P Serien eingesetzt in unserem Settop Box Projekt, da sie leiser
und weniger Energieverschwendend umgehen. Ich bevorzuge bei IDE
(habe ja mal einen NAS Server konstruiert) Seagate, die haben
recht stabile Produkte, aber ich kann mich auch da an schlechte
Zeiten erinnern. Da ich etwa 2/3 SCSI Platten habe aus zig Serien
einiger Hersteller kann ich da auch oft nur schlechtes sagen,
gerade die 36GB HDs von IBM habe ich (von 10) keine einzige mehr
ohne Rep. und jedesmal nach Holland ist auch nicht billig. Da
sind auch mehrere DMVS, DGHS, DRHS dabei und alle sind da wohl
gleich; bad sectors bis hin zum "Kann spur nicht mehr finden".
Ich habe hier auch eine 15k Seagate 36GB HD und eine 40GB Maxtor.
Die eine hörst du nur wenn sie hochtoured und zugreift die andere
immer. Auch hier war SCSI der Innovator für FDB da die Toleranzen
bei Kugellagern einfach zu groß wurde. Ich schließe mich leider
der Kommune an, daß die Ziele (schneller höher weiter) leider
nicht meine sind und viele Hersteller nur den Massenmarkt bedienen
siehe Stromverbrauch. Samsung macht da gerade eine Ausnahme, da
ihre HDs nur mit 8W sich begnügen, während Maxtor, Seagate, ...
alle bei rund 12W (full spin/seek/write) herumkrebsen.
Meine Arbeitsmaschinen habe ich deshalb mit 2,5" HDs ausgestattet
und einem einfachen IDE2SCSI Bridge versehen um bei meinen
SCSI Geräten zu bleiben (Q&D) [weil ich doch keine Lüfter im PC
mag]. SMART sorgt eigentlich in IDEs dafür, daß Bad Blocks re-
mapped werden, von außen nur durch SMART Agents zu sehen. SCSI
ist halt eine Industrienorm und dazu zählt halt auch Fehler-
protokolle und ein Handling desselbigen. Binb schon gespannt
wie's mit S-ATA da aussieht. Habe seit Monaten hier einige
Maxtors zum testen hier... Der Stromstecker ist aber endlich
durch bessere (+redundante) Kontakte ersetzt worden.
Gruß
Sam

Bernd Walter wrote:
>On Mon, Sep 01, 2003 at 05:30:04PM +0200, Oliver Fromme wrote:
> > Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > > Der Vorteil von Samsung ist zumindest, daß die nicht so hochgezüchtet
> > > sind, wie andere Hersteller.
> >
> > Nunja ...
> >
> > $ dmesg | grep ad0
> > ad0: 152627MB <SAMSUNG SV1604N> [310101/16/63] at ata0-master UDMA133
> > ad0s1a: hard error reading fsbn 93917055 of 46958496-46958751 (ad0s1 bn
> 93917055; cn 93171 tn 10 sn 57) trying PIO mode
> > ad0: DMA problem fallback to PIO mode
> > ad0s1a: hard error reading fsbn 93917071 of 46958496-46958751 (ad0s1 bn
> 93917071; cn 93171 tn 11 sn 10) status=59 error=01
> > ad0s1a: hard error reading fsbn 93917119 of 46958528-46958559 (ad0s1 bn
> 93917119; cn 93171 tn 11 sn 58) status=59 error=01
> > ..
>
>Auch Samsung ist letzlich nur IDE...
>
> > Man kann natürlich einfach nur Pech haben. Das kann wohl
> > bei jedem Hersteller mal passieren. In diesem speziellen
> > Fall hat ein dd-Schreiben über die ganze Platte, um ein
> > Remapping zu erzwingen, das Problem behoben (ja, ein Backup
> > hatte ich natürlich).
>
>Die Platte muss kein remapping gemacht haben.
>Read Error können auch zustanden kommen, wenn die Platte beim
>schreiben abgeschaltet wurde - da geht mitunter eine ganze
>physikalische Spur drauf - bei einigen Modellen sogar Spuren, die
>der Kopf beim Parken überschreitet.
>Moderne Platten können nämlich nur noch ganze Spuren schreiben.
>Der nicht mehr neu geschrieben Anteil der Spur ist verloren.
>Dann können sogar Blöcke draufgehen, die nicht verändert wurden.
>Beim Schreiben wird der Bereich halt einfach neu geschrieben und
>es gibt wieder eine gültige Prüfsumme.
>
> > Aber da man sich die Grown-defects nicht angucken kann,
> > kann man leider nicht wirklich beurteilen, wie gut (oder
> > schlecht) es um das Teil steht. Es kann sein, daß obige
> > Geschichte nur ein einmaliger Ausrutscher war, es kann aber
> > auch sein, daß gerade die Abriebspäne munter in der Platte
> > umherwirbeln und die Anzahl der (unbemerkten) Remappings
> > exponentiell steigt -- bis zum plötzlichen Herztod.
>
>Leider nur zu wahr.
>
>--
>B.Walter BWCT http://www.bwct.de
>ticso(at)bwct.de info(at)bwct.de
>
>
>To Unsubscribe: send mail to majordomo.FreeBSD.org
>with "unsubscribe de-bsd-questions" in the body of the message

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 01 Sep 2003 - 19:33:36 CEST

search this site