Am Mittwoch, den 05.12.2012, 17:20 +0100 schrieb Bernd Walter:
> On Wed, Dec 05, 2012 at 05:00:46PM +0100, Marc Santhoff wrote:
> > Am Mittwoch, den 05.12.2012, 13:19 +0100 schrieb Bernd Walter:
> > > On Wed, Dec 05, 2012 at 11:17:04AM +0100, Lars Engels wrote:
> > > > On Wed, Dec 05, 2012 at 09:49:10AM +0100, Marc Santhoff wrote:
> > Ich kann den gern mal leeren und neu formatieren, ggf. auch mit dd
> > ausnullen, fragt sich nur, wie das Management der defekten Blöcke darauf
> > regiert. Eigentlich sollte das doch unbeeinträchtigt bleiben? Oder Müllt
> > DOSen-Formatierung bzuw. "dd of=/dev/da0s1 ..." dem gleich die Tabellen
> > weg?
>
> Neh - das muss mit Spezialbefehlen passieren.
> Die sind Standardisiert, aber ich weiß nicht welche Tools es dafür
> gibt.
> Hintergrund ist folgender (vereinfacht):
[ ... lesenswerte Erklärung des Belegungsschemas ...]
> Wenn du so ein Medium voll schreibst belegt das Medium wenigstens so
> viele physikalische Blöcke, wie das Medium logisch nach außen anbietet.
> Das bleibt auch, wenn die Dateien gelöscht werden, weil nur dem
> Filesystem bekannt ist, dass der Inhalt der Blöcke nicht mehr interessiert.
Das ist der springende Punkt, klar.
> Der Effekt, dass Blöcke zunehmend als defekt markiert werden wird auch
> dadurch beschleunigt, dass man auf einem einmal voll geschriebenen
> Medium nur noch Winzmengen schreibt, wie in deinem Fall, weil die
> vom Filesystem ungenutzten Blöcke physikalische Blöcke zugewiesen haben,
> die nicht mehr in der Rotation sind, d.h. der Verscheiß konzentriert sich
> auf die wenigen verbliebenen.
Dann kann man diesem Stöpsel zumindest fragwürdige Datensicherheit
attestieren.
> Wenn du mit dd nullen schreibst wird einmal rotiert und du hast für den
> Verschleiss etwas gutes getan, aber der Pool gelöschter bleibt klein.
Im Prinzip ja, aber bei den Preisen trenne ich mich lieber davon und
ersetze ihn. Danke für die Warnung.
-- Marc Santhoff <M.Santhoff(at)web.de> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Wed 05 Dec 2012 - 17:31:49 CET