[Graumagier]

Naja, das blocksize-Attribut bestimmt, wie viele Bytes sequenziell auf einmal geschrieben werden. Prinzipiell ist ein höherer Wert besser. Versuch's mal mit 1024 und entscheide selbst, ob dir die Performance reicht.

EDIT: Hm, wo kam denn die 0 her?

Dieser Beitrag wurde von Graumagier bearbeitet: 19. Dezember 2006 - 08:25

[Rika]

Dank dem Caching wirkt sich das aber nur darauf aus, mit welcher Granularität in den Puffer geschrieben wird. Ja, man kann das künstlich verlangsamen, indem man kleine Blöcke verwendet, aber bis zum Erreichen der CPU-Limitierung sollte sich das auf die Schreibgeschwindigkeit nicht auswirken.

Also 1M als Blocksize sollten defnitiv OK sein sind.

[ph030]

Vielleicht kann mir da grad mal einer was erklären, wenn wir schon dabei sind...

Habe gestern mal eine HDD (IDE alleine am Strang, 40GB, 2MB Cache, 5400rpm) gelöscht mit:

date > /test.txt && dd if=/dev/zero of=/dev/hdb && date >> /test.txt

Das dauerte knapp ~6h, was imho im normalen Bereich liegen dürfte.

Danach nocheinmal den selben Befehl, allerdings hab ich vorher die ganze HDD mit einer XFS-Partition belegt und gemounted:

date > /test2.txt && dd if=/dev/zero of=/mnt/test && date >> /test2.txt

Im Ergebnis machte das ~1h Unterschied.

Anschließen wurde die XFS-Partition via fdisk gelöscht, sollte also prinzipiell genauso effektiv sein, wie das vorherige - ausser, dass man ev noch den XFS-Header lesen könnte.

Wie kommt nun dieser doch relativ große Unterschied zu stande?

cheers,
ph

[Rika]

Zitat

Das dauerte knapp ~6h, was imho im normalen Bereich liegen dürfte.

Also ich hatte letztendlich eine 4200rpmer-Notebookfestplatte. Die schafft locker 40 MB/s, womit die 120 GB dann in knapp 'ner Stunde gelöscht waren.

Also letztendlich steht nur zur Diskussion, wie ineffektiv du das gemacht hast und warum Dateisystemtreiber diese Ineffektivität unerwarteterweise mildern können.

[ph030]

Zitat

Die schafft locker 40 MB/s, womit die 120 GB dann in knapp 'ner Stunde gelöscht waren.

Ahü, also meine 4.200er schafft

hdparm -tT /dev/hda sagte:

/dev/hda:
Timing cached reads: 1426 MB in 2.00 seconds = 712.89 MB/sec
Timing buffered disk reads: 64MB in 3.06 seconds = 20.90 MB/sec

, insofern würden mich deine Settings da schonmal interessieren.

Zitat

Also letztendlich steht nur zur Diskussion, wie ineffektiv du das gemacht hast und warum Dateisystemtreiber diese Ineffektivität unerwarteterweise mildern können.

Keine Ahnung zu ersterem und zu letzterem bin ich dezent überfragt

EDIT:
Zur Info:

hdparm -i /dev/hda sagte:

/dev/hda:

Model=TOSHIBA MK6006GAH, FwRev=BZ002A, SerialNo=95O65643S
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117210240
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

* signifies the current active mode

Dieser Beitrag wurde von ph030 bearbeitet: 19. Dezember 2006 - 16:46

[Rika]

Zitat

20.90 MB/sec

Wenn die Schreibgeschwindigkeit auch in dem Bereich ist, dann sind 40 GB sind knapp 'ner halben Stunde beschrieben.

Zitat

Keine Ahnung zu ersterem

Hä? Ist doch offensichtlich: Du hast bei 'dd' keine Blockgröße angegeben, also nimmt er Bytes. Dein Rechner war größtenteils damit beschäftigt, byteweise Nullen in einen Puffer zu schieben.

[ShadowHunter]

Also sinnvollerweise einfach noch die 1024 als Parameter beim dd aufruf mit übergeben?!

[Rika]

1024k! 1024, also 1k, wäre doch auch noch ziemlich unterdimensioniert, wie du trivialerweise messen kannst. Ab 32k gibt's kaum noch einen Unterschied, und mit 1m ist man auf der sicheren Seite.

[ShadowHunter]

Sollte das auch bei älteren Rechnern problemlos klappen?

[ShadowHunter]

Hab heute noch mit einem Kollegen geredet.
Er meinte, durch die Restmagnetisierung könnten nach 2 mal "dev/zero" doch noch im labor nach absehbarer Zeit Daten wiederhergestellt werden. Wie es genau funktioniert konnte er auch nicht erklären.
In der Bank nutzen die den Gutmann Algo.

Ist das richtig so?!

[stressfish]

Habe nun mal versucht zu formatieren, komme allerdings nicht sehr weit.
Wenn ich sage: "dd if=/dev/urandom of=/dev/hda" bekomme ich folgende Fehlermeldung:
"dd: opening `/dev/hda´: Permission denied

Woran liegt das? Kann es was damit zu tun haben dass die 3 Festplatten (3x Compaq Wide Ultra3 SCSI 18.2GB) im RAID sind?

Wenn ich "qtparted" ausführe, zeigt er mir bei Disks nur "/dev/hda/" an und in der rechten Spalte nur "Partition table" - Status "Empty".

Was ist da los?

MfG Stressfish

[ShadowHunter]

sollst es ja auch als root machen

schreib ein sudo davor

[Rika]

Zitat

Er meinte, durch die Restmagnetisierung könnten nach 2 mal

Was meinst du, warum ich zweimaliges statt einmaliges Überschreiben empfehle? Echt mal, wenn nach 12 db SNR immernoch statistisch signifikante Restsignale möglich wären, dann würde man die doch längst für eine Erhöhung der Datendichte verwenden.

Zitat

In der Bank nutzen die den Gutmann Algo.

Ja ja, wer gleich noch den Datenträger ruinieren möchte...

[ShadowHunter]

Zitat (Rika: 20.12.2006, 12:22)

Was meinst du, warum ich zweimaliges statt einmaliges Überschreiben empfehle? Echt mal, wenn nach 12 db SNR immernoch statistisch signifikante Restsignale möglich wären, dann würde man die doch längst für eine Erhöhung der Datendichte verwenden.

Naja angeblich ja auch noch nach wie gesagt 2mal innerhalb ner Woche machbar, naja ich frag ihn mal welche db SNR werte er so angedacht hat. thx

Zitat

Ja ja, wer gleich noch den Datenträger ruinieren möchte...

inwiefern?

[stressfish]

mit "sudo dd if=/dev/urandom of=/dev/hda" sagt er mir:
"dd: opening `/dev/hda´: Read-only file system"

... wah wieso funktioniert es nicht?

MfG Stressfish