# Kopieren und Performance?

## ChrisJumper

Sei gegrüßt lieber Gentooliebhaber,

vor kurzem habe ich mich beim Kopieren wieder gefragt, ob ich da vielleicht doch etwas unvorteilhaft mache, oder machen lasse.

Kopiere ich eine etwas größere Datei (z.B. eine aufgenommene Simpsons-Folge) von einer Partition der SATA-Festplatte auf die andere, landet meine CPU-Auslastung sofort bei 100 Prozent.

Zuerst dachte ich es sei normal. Dann hab ich festgestellt das Windows keine so hohe CPU-Last erzeugt.

Natürlich habe ich bei meinen IDE-Festplatten immer DMA-Aktiviert, und sollte ich mich recht entsinnen dient dies eben dazu Informationen an der CPU vorbei, mehr oder weniger direkt, in den Speicher oder an die andere Festplatte zu schieben.

Ich erinnere mich schwebend, das DMA-Aktivierung bei SATA-Platten nicht ganz so trivial war und ich mich damals noch nicht daran getraut habe, zumal im Gentoo-Wiki einige Warnschilder aufgestellt waren.

Habt ihr beim Kopieren einer Datei auch 100% CPU-Auslastung?

Liegt es vielleicht an der Verwendung des Komandozeilen-Programm cp?

Kennt ihr eine gute Alternative für cp?

Wie aktiviere ich DMA bei SATA?

So, jetzt versuche ich mal ein paar Informationen dazu zusammenzukratzen. Würde mich aber freuen wenn ihr euren Senf oder Cent dazugebt. :)

Mfg Chris

----------

## dakjo

Ich glaube dein Chipsatz wird nicht so hypsch unterstuetzt.

a) SATA hat DMA immer an.

b) Ist es die CPU Auslastung oder die Systemlast?

c) Welchen Chipsatz/SATA-Card verwendest du?

Just my 10 Cent.

----------

## ChrisJumper

 *Quote:*   

> b) Ist es die CPU Auslastung oder die Systemlast? 

 

Hmm. Interessant. Scheinbar hab ich da doch etwas falsch aufgegriffen.

Die CPU-Auslastung welche mir htop anzeigt ist ist nicht die selbe der Gnome-Systemüberwachung. Bei dieser bleibt der Graph im 40 Prozent bereich, während htop 100 Prozent wiedergibt.

Liegt es daran das htop die kernel Auslastung mit angibt während sich die Gnome-Systemüberwachung auf die Summe der User-Prozesse beschränkt?

Wie genau unterscheidet man eigentlich zwischen Systemlast und CPU-Auslastung?

Entspricht die Systemlast der Summe des Ressourcenverbrauchs (Arbeitsspeicher, SWAP,  CPU, Netzwerk...)?

 *Quote:*   

> c) Welchen Chipsatz/SATA-Card verwendest du?

 

```
 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)

```

```
CONFIG_SATA_VIA=y
```

Bis vor kurzem neigte mein PC beim kopieren noch zum "swapen" da er nur 512MB hatte.

Beim Test von eben (ich hab jetzt wieder 1536MB) funktionierte es dann doch ohne größere Probleme.  Ich vermute der wenige Arbeitsspeicher war die Ursache dafür das beim Kopiervorgang sogar die Maus ruckelte.

----------

## hoschi

Das sollte eigentlich mit wenig RAM nicht passieren, so ein idiomatisches Verhalten kenne ich ehrlich gesagt nur von Windows-XP (da schleift schnell viel in den Speicher, bis es nicht mehr weitergeht und fangt dann an Rumzukrebsen...).

Kopier mal eine Datei die weit groesser ist als dein jetztiger Speicher, sagen wir 3 GB.

btw. dein Chipsatz ist recht selten, ist kein normales Desktop-Board?

----------

## dakjo

Also entweder ist dann eine der Platten performancetechnisch für Popo,

du benutzt ein SW-Raid,

oder der HW-Treiber ist von der güte einer schnarchbremse.

Es sollte jedenfalls nie dazu kommen, das cp die sachen in den ram schiebt.

Jedenfalls nicht zu so grossen teilen.

Oder du verwendest irgendwelche dateisystem/io-scheduler (optionen) die fuern popo sind.

----------

## a.forlorn

VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt.

----------

## boris64

 *a.forlorn wrote:*   

> VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt.

 

Hm, also ich habe ein nVidia (nforce4) Sata Controller, und die Performance ist auch für 

den (Zitat) "Popo". Benutzter Scheduler ist zur Zeit der "cfq" IO scheduler

(habe die anderen allerdings auch schon durchprobiert) unter Kernel 2.6.22_rc5.

Und ja, das war schon immer so (unter alten/stabilen Kernelversionen).

Kopiert man mehrere Dateien gleichzeitig, kann es dann durchaus vorkommen,

dass X erstmal komplett stillsteht und lustige weisse/leere Fenster zeigt.

Das ist so unter "meinem" SpieleXP definitiv anders.

PS: Ich habe durchaus auch hohe Kopierraten (40MB/s etc.), doch 

blockiert dieser Kopiervorgang meist alles andere.

----------

## ChrisJumper

 *a.forlorn wrote:*   

> VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt.

 

Sehr interessant! Dann kann das durchaus sein.

Ich werde später nochmal mehrere Dateien größeren Umfangs kopieren. Ein möglicherweise schlechter Treiber erklärt mir vielleicht auch das Phänomen.. das beim brennen von der Platte via k3b mein X kurz einfriert. Bisher hat es dadurch aber noch keine CD verbrannt, oder die Tonausgabe via Amarok im Hintergrund gestoppt. :)  - Das mag ich an Linux!

Dieses Board war ein AS-ROCK Billigboard. Den Fehlkauf hab ich bestimmt nur einmal begangen, aber deswegen will ich es jetzt bestimmt nicht "Entsorgen".

Ich hab weder einen außergewöhnlichen Scheduler noch einen Software Raid. Ich benutze keinen Raid hab nur eine Platte.

Edit: Also eine SATA-Platte. ;)

----------

## UTgamer

 *boris64 wrote:*   

>  *a.forlorn wrote:*   VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt. 
> 
> Hm, also ich habe ein nVidia (nforce4) Sata Controller, und die Performance ist auch für 
> 
> den (Zitat) "Popo". Benutzter Scheduler ist zur Zeit der "cfq" IO scheduler
> ...

 

 :Rolling Eyes: 

Dann hast du irgend etwas falsch eingestellt bei deinem nForce4, wenn ich einen Ordner von 1,8 GB mit vielen Dateien von einer Partition zu einer Anderen auf der gleichen Festplatte kopiere fängt er mit 39 MB/s an und läuft bis auf 18 MB Übertragungsrate herunter, die CPU-Auslastung beträgt dabei zwischen 4 + 8 %.

Ich nutze gerade Kernel 2.6.19-gentoo-r5 und alles auf 64 Bit.

Also auf deinem Rechner verschenkst du viel Leistungspotential. Es steht auch überhaupt nichts still für einen kurzen Augenblick, da ich noch so rund 96% CPU-Zeit auf dieser CPU frei habe merke ich davon auch garnichts.

 *ChrisJumper wrote:*   

>  *Quote:*   c) Welchen Chipsatz/SATA-Card verwendest du? 
> 
> ```
>  RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
> 
> ...

 

Auf meinem Athlon 2400+ Rechner habe ich einen VIA VT82C586A Chipsatz, der ist sowas von instabil da kann ich bei größeren Kopieraktionen weder 3D Grafik noch Ton nebenbei haben ohne das das System so abstürzt das ich den Rechner nur noch über den Ausschalter neu starten kann.

(1* VIA und nie wieder!)

----------

## py-ro

Natürlich belegt der Kopiervorgang auf der gleichen Platte RAM, irgendwo müssen die daten ja zwischengespeichert werden und Linux neigt dazu dafür eine Menge RAM zu verwenden, wenn er dann Programme aus dem Speicher in den Swap schiebt wirds nochmal langsamer.

Das mit der CPU Last bei 40%beobachte ich bei meinem nforce Board übrigens auch, besserung würde ich auch gerne haben.

Py

----------

## misterjack

 *a.forlorn wrote:*   

> VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt.

 

In meinen Augen grober Unfug, um VIA mal in Schutz zu nehmen:

```
00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
```

Hab ich ebenfalls, so selten ist der nicht.

Mittels mc eine 1,5GB große Datei von einer Partition auf eine andere verschoben mit ~18,50 MB/s

```
Cpu(s):  6.0%us, 12.3%sy,  0.0%ni,  0.0%id, 80.1%wa,  0.3%hi,  1.3%si,  0.0%st
```

Mit cp sieht die Auslastung gleich aus. Meine Vermutung, dein System ist einfach falsch eingestellt  :Smile: 

@ChrisJumper, die üblichen Informationen bitte, wie emerge --info und deine Kernelconfig, wenns geht letztere in nopaste.info oder als Download.

EDIT:

 *UTgamer wrote:*   

> VIA VT82C586A

 

Den habe ich im Server, deine Probleme kenne ich ebenfalls nicht.

----------

## UTgamer

 *py-ro wrote:*   

> Das mit der CPU Last bei 40%beobachte ich bei meinem nforce Board übrigens auch, besserung würde ich auch gerne haben.
> 
> Py

 

Ebenfalls falsche Kerneleinstellungen und oder falsches Dateisystem.

Kerneleinstellungen für nForce 4 = 

Device drivers >> Serial ATA (...) >> ATA device support >> NVIDIA SATA support + AMD/NVIDIA PATA support (Experimental) + Generic ATA support.

+

Device drivers >> SCSI device support >> legacy /proc/scsi/ support + SCSI disk support  (+ SCSI CDROM support) + SCSI generic support (+ Verbose SCSI error reporting (kernel size +=12K))

Sind meine Kerneleinstellungen

Ihr habt wahrscheinlich viel zu viele negative Einstellungen unter euren CPU-Einstellungen, sowas wie die Timing Parameter.

Sowie ich auch reiserfs-v3.6 benutze.

Wen es interressiert wie ich auf nur 4-8% komme, kann gerne meine komplette Kernelkonfig haben, und wer es nicht glaubt der kann auch live über VNC auf meinen Rechner schauen.  :Wink: 

----------

## UTgamer

 *misterjack wrote:*   

> 
> 
> EDIT:
> 
>  *UTgamer wrote:*   VIA VT82C586A 
> ...

 

Auf einem Server laufen auch nicht gleichzeitig noch Sound und OpenGL, ansonsten ist der auch stabil. Sobald ich die nVidia-OpenGL-Treiber für meine Geforce 5900GT aktiviere wird er wieder instabil bei jedweder HD Aktion. Auch ist bekannt das er ein Problem auf dem PCE-Bus hat ganz speziel mit Soundblaster Karten, und ich habe eine Audigy mit da drauf.

Belege?

http://www.au-ja.org/index-u-05-01.phtml

http://www.tweakpc.de/berichte/tipps_tricks/via_686b_bug.htm

http://www.au-ja.de/review-kt133a-1.phtml

http://www.heise.de/newsticker/meldung/18368

Mein super teures Dual-BIOS Mainboard:

Gigabyte GA-7DXR, ich sag nur 1* VIA und nie wieder!

----------

## py-ro

@UTGamer

Verzeih mir aber Kerneloptionen hab ich in alle kombinationen durch, auf dem A8N-Sli war zumindest bis 2.6.16 nix zu machen unter 40% Last.

Bei meinem neuen hab ich ehrlichgesagt noch nicht drauf geachtet, aber der hat eh ne x2 Cpu, fällt also nicht wirklich auf.

----------

## UTgamer

 *py-ro wrote:*   

> @UTGamer
> 
> Verzeih mir aber Kerneloptionen hab ich in alle kombinationen durch, auf dem A8N-Sli war zumindest bis 2.6.16 nix zu machen unter 40% Last.
> 
> Bei meinem neuen hab ich ehrlichgesagt noch nicht drauf geachtet, aber der hat eh ne x2 Cpu, fällt also nicht wirklich auf.

  Hab auch einen Dual-Core, und die Werte bezogen sich auf eine CPU davon auf der gerade der Kopiervorgang läuft.  :Wink: 

----------

## a.forlorn

 *misterjack wrote:*   

>  *a.forlorn wrote:*   VIA ist doch für schlechte Performance unter IDE/SATA bekannt. Durchaus möglich, dass sich da ne ganze Menge heap rumtreibt. 
> 
> In meinen Augen grober Unfug, um VIA mal in Schutz zu nehmen:

 

Leider doch, der berühmte bug aus dem KT133 hat sich bis heute in den VIA-boards überlebt. Die Performance einseitig ist recht gut, aber sobald 2 Geräte an einem IDE- Port hängen, oder RW- Vorgänge laufen, wird der extrem instabil.

----------

## misterjack

 *UTgamer wrote:*   

> 
> 
> Auf einem Server laufen auch nicht gleichzeitig noch Sound und OpenGL, ansonsten ist der auch stabil. Sobald ich die nVidia-OpenGL-Treiber für meine Geforce 5900GT aktiviere wird er wieder instabil bei jedweder HD Aktion. Auch ist bekannt das er ein Problem auf dem PCE-Bus hat ganz speziel mit Soundblaster Karten, und ich habe eine Audigy mit da drauf.
> 
> 

 

mmh den Bug kannte ich noch nicht. Ich bin komischerweise von dem Bug verschont. Hab das Mainboard schon sehr lange und damals in meinen Haupt-PC am Laufen gehabt. Habs aus den Gründen der Stabilität weiterverwendet. Hatte auch 2 IDE-Festplatten drin und ne Ti4200 soweit ich mich dran erinnern kann.

 *a.forlorn wrote:*   

> 
> 
> Leider doch, der berühmte bug aus dem KT133 hat sich bis heute in den VIA-boards überlebt. Die Performance einseitig ist recht gut, aber sobald 2 Geräte an einem IDE- Port hängen, oder RW- Vorgänge laufen, wird der extrem instabil.

 

Beweise? Meine Recherchen haben nichts ergeben. Habe auch mehrere IDE-Geräte dran und instabil ist da absolut nichts.

----------

## boris64

 *UTgamer wrote:*   

>  *boris64 wrote:*   ...
> 
> PS: Ich habe durchaus auch hohe Kopierraten (40MB/s etc.), doch 
> 
> blockiert dieser Kopiervorgang meist alles andere. 
> ...

 

Ich glaube, das kam falsch rüber. Die CPU-Last beträgt max 10% auf einem Kern (Ich beziehe mich mal auf "kio_file"),

trotzdem hakt es beim Kopiervorgang an allen Ecken (hohe IO-Last o.ä.??).

Man beachte das "${prozent}wa" bei "top"(!). 

```

Cpu(s):  2.9%us,  2.9%sy,  0.0%ni, 13.9%id, 79.4%wa,  0.5%hi,  0.5%si,  0.0%st

```

----------

## sewulba

Also ich verstehe das nicht ganz, dass es soviel Last macht. Bei mir ist es, dass wenn ich eine 2GB große Datei von einer (Adaptec 29160-Conroller) SCSI160 Platte zur anderen schiebe, dann habe ich einen Datendurchsatz von 68,5MB/s bei einer Last von durchschnittlich 3%! 

Ich denke, dass Dein Chipsatz für SATA einfach nicht gut unterstützt wird. Hatte ähnliche Probleme mal mit VIA-Chipsatz. Habe mich von VIA-Chipsätzen komplett getrennt.

Sewulba

Nachtrag:

Eben gerade Last und Durchsatz auf meinem LSI Logic Kontroler gemessen. Hängen 4 SerialATA2 Platten dran (RAID). Last wie bei SCSI bei ungefähr 3%. Datendurchsatz 115MB/s.

----------

## UTgamer

 *sewulba wrote:*   

> Also ich verstehe das nicht ganz, dass es soviel Last macht. Bei mir ist es, dass wenn ich eine 2GB große Datei von einer (Adaptec 29160-Conroller) SCSI160 Platte zur anderen schiebe, dann habe ich einen Datendurchsatz von 68,5MB/s bei einer Last von durchschnittlich 3%! 

 

Nicht verstanden gehabt? Nicht von einer Platte auf eine andere, sondern auf die gleiche Platte, deine Werte sind nun ohne Vergleich alleinstehend!  :Smile: 

----------

## hoschi

 *ChrisJumper wrote:*   

> 
> 
> das beim brennen von der Platte via k3b mein X kurz einfriert.

 

Davon kann ich mit VIA ein Lied singen.

----------

## hoschi

 *py-ro wrote:*   

> Natürlich belegt der Kopiervorgang auf der gleichen Platte RAM, irgendwo müssen die daten ja zwischengespeichert werden und Linux neigt dazu dafür eine Menge RAM zu verwenden, wenn er dann Programme aus dem Speicher in den Swap schiebt wirds nochmal langsamer.
> 
> Das mit der CPU Last bei 40%beobachte ich bei meinem nforce Board übrigens auch, besserung würde ich auch gerne haben.
> 
> Py

 

Wie viel Speicher beim Kopieren oder Verschieben genutzt werden kann (!) um Schreib/Lesezugriffe geschickt zu kombinieren hängt wohl am meisten vom Dateisystem ab (sowie Chipsatz und Festplatte - SATA, PATA, NCQ, HDD-Cache, SSD oder HDD), XFS lässt kleinere Dateien gerne mal im Speicher um beendet lieber erstmal ein paar Schreiboperationen um ingesamt schneller voran zu kommen, dass verhindert auch eine schnelle Fragmentierung und CPU-Last (wie man sie von ReiserFS leider kennt).

Linux wird eher mal den Cache oder Buffer swappen, die Programme selber nur im Notfall und schon gar nicht für Dateioperationen.

WindowsXP ist da flexibler, WinXP kann sogar den eigenen Kernel in den SWAP packen  :Mr. Green: 

----------

## py-ro

 *Quote:*   

> Linux wird eher mal den Cache oder Buffer swappen, die Programme selber nur im Notfall und schon gar nicht für Dateioperationen.

 

Cache oder Buffer zu swappen macht 0 Sinn und wird auch nicht getan AFAIK, die Dinger sind ja eben dazu da damit er keinen Festplattenzugriff machen muss.

Programme die gerade nicht gebraucht werden, werden da schon eher geswapped, wobei ich schon lange keinen verbrauchten swap speicher mehr gesehen hab und das beim kompilieren auf einer RAMDISK.

Aber unter Umständen rede ich auch nur Müll, nicht so ganz mein spezialgebiet.

Hab jetzt mal ein bissel mit meinem neuen Board rumgespielt, interressanterweise benötigt cp mehr zeit zum kopieren einer 270MB datei als der MC, cp erzeugt auf einem kern bis zu 80% Last, der MC bis zu 40%.

Auf diesem System mitg XFS, bei dem alten war es ext3.

Beim kopieren nach /dev/zero, springt die last am anfang kurz 0.5 sec auf 100% und dann nix mehr, scheint also am schreiben liegen und damit am FS liegen.

Also das ganze mal in ein tmpfs kopiert, 80% Last, allerdings nur für kurze Zeit.

Das sagt dmesg über die Platte:

```

scsi3 : sata_nv

ata3: SATA max UDMA/133 cmd 0x000109f0 ctl 0x00010bf2 bmdma 0x0001dc00 irq 0

ata4: SATA max UDMA/133 cmd 0x00010970 ctl 0x00010b72 bmdma 0x0001dc08 irq 0

ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata3.00: ata_hpa_resize 1: sectors = 390721968, hpa_sectors = 390721968

ata3.00: ATA-7: SAMSUNG SP2004C, VM100-32, max UDMA7

ata3.00: 390721968 sectors, multi 1: LBA48 NCQ (depth 0/32)

ata3.00: ata_hpa_resize 1: sectors = 390721968, hpa_sectors = 390721968

ata3.00: configured for UDMA/133

......

sd 2:0:0:0: [sda] 390721968 512-byte hardware sectors (200050 MB)

sd 2:0:0:0: [sda] Write Protect is off

sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00

sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sd 2:0:0:0: [sda] 390721968 512-byte hardware sectors (200050 MB)

sd 2:0:0:0: [sda] Write Protect is off

sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00

sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

 sda: sda1 sda2

sd 2:0:0:0: [sda] Attached SCSI disk

```

anticipatory scheduler ist aktiv.

So, was soll ich noch suchen?   :Razz: 

----------

## hoschi

Ich habe 1024 MB und gar keine SWAP und habe auch nie eine gebraucht, als noch eine SWAP-Partition aktiviert war. Ist sowieso etwas, was in der heutigen Zeit einfach nicht mehr noetig sein darf (Speichergroesse und Preise).

----------

## AROK

Hallo,

Ich nutze einfach mal diesen Theard für mein Problem. Die Kopierperformance meines Systems versteht ich auch nicht:

Alle Platten von Western Digital, sdb ist etwa ein Jahr alt, die anderen erst dieses Jahr gekauft. Alle 16MB Cache, SATA2 (außer sdb).

sda500gb, sdb 160gb, sdc 360gb. Chipsatz ist Intel ICH9R. Prozessor C2D T6750, 2GB RAM. Kernel: 2.6.22-gentoo-r8

kopieren einer 400MB Datei, alles ext3:

von sda9 nach sda2: 33MB/s

von sda2 nach sdc7: 10MB/s

von sda9 nach sdc7: 20MB/s

von sdc7 nach sda2: 65MB/s

von sdc7 nach sda9: 55MB/s

von sdc7 nach sdb1: 35MB/s

von sdb1 nach sdc7: 10MB/s

von sdb1 nach sda2: 75MB/s

von sda2 nach sdb1: 50MB/s

Jeweils ca 100% Last auf CPU0 und etwa 1-2% auf CPU1

```

/dev/sda:

 Timing cached reads:   8526 MB in  2.00 seconds = 4267.34 MB/sec

 Timing buffered disk reads:  244 MB in  3.00 seconds =  86.27 MB/sec

/sbin/hdparm -tT /dev/sdb

/dev/sdb:

 Timing cached reads:   7696 MB in  2.00 seconds = 3850.88 MB/sec

 Timing buffered disk reads:   86 MB in  3.05 seconds =  35.18 MB/sec

/sbin/hdparm -tT /dev/sdc

/dev/sdc:

 Timing cached reads:   7944 MB in  2.00 seconds = 3975.97 MB/sec

 Timing buffered disk reads:  190 MB in  3.00 seconds =  73.25 MB/sec

```

sdc scheint beim schreiben sehr langsam zu sein, obwohl es fast die gleiche Platte ist, wie sda   :Confused: 

Hat von euch Jemand eine Idee?

aufgefallen ist mir das weil gerade das

von sdb1 nach sdc7: 10MB/s

häufig vorkommt.  und 10mb/s nervt natürlich ganz schön.

Danke für Hinweise und Gruß

AROK

----------

## De Beukelaer

Manche Dateisysteme werden recht langsam wenn die Partition fast voll ist. Der Lesekopf muss dann auch öfter springen um zur nächsten freien Stelle zu kommen wo noch was geschrieben werden kann (Fragmentation).

Das sollte allerdings auch nur mehr wa% machen und nicht die CPU quälen.

----------

## AROK

Hi,

danke für den Hinweis. Würde ich hier aber ausschließen. sdc7 ist nur zu 53% gefüllt, sdb1 ist zu 90% gefüllt, und wird häufig beschrieben und gelöscht, weil das meine Videoschnittpartition ist. sdc ist erst seit etwa 2 Monaten eingebaut, also kaum was gelöscht und sollte nicht fragmentiert sein. 

Ein Defragmentiertool für ext3 gibt es ja meines Wissens nach nicht, da es angeblich kaum fragmentiert.

Gruß

AROK

----------

## schachti

Die Defragmentierungstools für ext3 sind tar und cp.   :Laughing: 

----------

## schachti

 *AROK wrote:*   

> Ich nutze einfach mal diesen Theard für mein Problem. Die Kopierperformance meines Systems versteht ich auch nicht:
> 
> Alle Platten von Western Digital, sdb ist etwa ein Jahr alt, die anderen erst dieses Jahr gekauft. Alle 16MB Cache, SATA2 (außer sdb).
> 
> sda500gb, sdb 160gb, sdc 360gb. Chipsatz ist Intel ICH9R. Prozessor C2D T6750, 2GB RAM. Kernel: 2.6.22-gentoo-r8
> ...

 

Was man bei solchen Vergleichen auch beachten muss ist die Geometrie der Platten. Moderne Festplatten mit hohen Kapazitäten bestehen in der Regel aus mehreren physikalischen Magnetplatten. Die Datenrate hängt immer davon ab, aus wie vielen physikalischen Magnetplatten die Festplatte besteht und wo genau die Partitionen liegen, die Du zum Testen benutzt. Wenn Du gerade den blöden Fall erwischt, dass Du Daten aus dem Innenbereich einer physikalischen Magnetplatte liest und sie in den Innenbereich einer anderen physikalischen Magnetplatte schreibst, ist die Geschwindigkeit wesentlich niedriger als wenn Du Daten vom Außenbereich einer Platte liest und sie in den Außenbereich einer Platte schreibst.

Hintergrund: Die Drehfrequenz der Festplatte ist konstant (zum Beispiel 7200 Umdrehungen pro Minute). Das bedeutet, dass ein Punkt in den Außenbereichen der Festplatte in der gleichen Zeit eine längere Strecke zurücklegt als ein Punkt im Innenbereich der Festplatte (der Umfang eines Kreises ist 2 * Pi * Radius - ist der Punkt P1 doppelt so weit von der Kreismitte entfernt wie der Punkt P2, so muss er gemäß dieser Gleichung in der gleichen Zeit den doppelten Weg zurücklegen). Das bedeutet, dass die Datenrate für Daten auf dem gleichen Kreis wie P1ebenfalls bis zu doppelt so hoch sein kann wie die Datenrate für Daten auf dem selben Kreis wie P2 (vorausgesetzt, dass die Daten gleich "dicht" gespeichert werden - diese Technik nennt man Zone Bit Recording, sie ist AFAIK bei allen modernen Festplatten Standard).

----------

## AROK

 *Quote:*   

> 
> 
> Die Defragmentierungstools für ext3 sind tar und cp. 

 

Ok, das funktioniert.  Aber dann kaufe ich gleich ne neue Platte und "move" Alles Rüber   :Wink: 

 *Quote:*   

> 
> 
> Wenn Du gerade den blöden Fall erwischt, dass Du Daten aus dem Innenbereich einer physikalischen Magnetplatte liest und sie in den Innenbereich einer anderen physikalischen Magnetplatte schreibst, ist die Geschwindigkeit wesentlich niedriger als wenn Du Daten vom Außenbereich einer Platte liest und sie in den Außenbereich einer Platte schreibst. 

 

Das ist natürlich richtig und mir natürlich bekannt. Darüber habe ich auch schon nachgedacht.  

Wie ist das mit der "Geometrie der Partitionen" ? Ich denke die Zylinder erstrecken sich über mehrere Scheiben, von Innen nach Außen. Wenn mehrere Zylinder eine Partition bilden, sollte sdc7 recht weit außen liegen und sda2 eher weiter innen (natürlich auf einer anderen Platte). 

von sdb1 nach sdc7: 10MB/s

von sdc7 nach sda2: 65MB/s 

Gegen deine Theorie spricht, dass das lesen von sdc7 scheinbar gut klappt, nur schreiben nicht.

Gruß

AROK

----------

## Finswimmer

 *AROK wrote:*   

> 
> 
> von sdb1 nach sdc7: 10MB/s
> 
> von sdc7 nach sda2: 65MB/s 
> ...

 

Jaein, du vergleichst zwei verschiedene Sachen, denn das Lesen kann ich immer nur so schnell wie das Schreiben sein - und umgekehrt.

Interessant wäre sdb1 -> sdc7 mit sdc7 -> sdb1, und sdc7 -> sda2 mit sda2 -> sdc7 zu vergleichen.

Tobi

----------

## AROK

 *Quote:*   

> 
> 
> Interessant wäre sdb1 -> sdc7 mit sdc7 -> sdb1, 
> 
> und sdc7 -> sda2 mit sda2 -> sdc7 zu vergleichen
> ...

 

von sdc7 nach sdb1: 35MB/s

von sdb1 nach sdc7: 10MB/s 

von sdc7 nach sda2: 65MB/s 

von sda2 nach sdc7: 10MB/s

----------

## schachti

 *AROK wrote:*   

> 
> 
> Wie ist das mit der "Geometrie der Partitionen" ? Ich denke die Zylinder erstrecken sich über mehrere Scheiben, von Innen nach Außen. Wenn mehrere Zylinder eine Partition bilden, sollte sdc7 recht weit außen liegen und sda2 eher weiter innen (natürlich auf einer anderen Platte). 
> 
> 

 

Die tatsächliche physikalische Geometrie ist in der Regel vollkommen anders als die "virtuelle" Geometrie, die der Festplattencontroller an das Betriebssystem meldet. Es ist also sehr schwer zu sagen, welche Partition physikalisch wo landet.

----------

## AROK

 *schachti wrote:*   

>  *AROK wrote:*   
> 
> Wie ist das mit der "Geometrie der Partitionen" ? Ich denke die Zylinder erstrecken sich über mehrere Scheiben, von Innen nach Außen. Wenn mehrere Zylinder eine Partition bilden, sollte sdc7 recht weit außen liegen und sda2 eher weiter innen (natürlich auf einer anderen Platte). 
> 
>  
> ...

 

Wäre interessant, wenn man sehen könnte wo die Dateien physikalisch liegen.  

Würdest du denn dem

 *Quote:*   

> von sdb1 nach sdc7: 10MB/s
> 
> von sdc7 nach sda2: 65MB/s
> 
> Gegen deine Theorie spricht, dass das lesen von sdc7 scheinbar gut klappt, nur schreiben nicht. 

 

beipflichten, oder bin ich damit auf dem Holzweg? 

Meine Idee dabei war, dass wenn die Platte lesend mind. 65MB/s liefern kann und schreibend nur 10mb/s auf der gleichen Partition, kann es nicht daran liegen, dass die Daten innen liegen. 

Das Verhalten ist so reproduzierbar, und ändert sich auch nicht schlagartig mit dem Füllungsgrad (was evtl. durch "umspringen" auf eine andere Scheibe erklärbar wäre)

----------

## Max Steel

 *schachti wrote:*   

> Die Defragmentierungstools für ext3 sind tar und cp.  

 

Kleine Frage, gibt es auch für reiser3 ein Defragmentierungstools, oder auch nur tar und cp.

Ein anderes als diese beiden wäre noch besser, da ich das ganze nur im laufenden Betrieb machen kann.

----------

## schachti

 *AROK wrote:*   

> 
> 
> Würdest du denn dem
> 
>  *Quote:*   von sdb1 nach sdc7: 10MB/s
> ...

 

Vielleicht liegen aus irgendeinem Grund die Daten, die Du liest, relativ weit außen, während der freie Bereich, in den Du schreibst, relativ weit innen auf der Platte liegt. Kannst Du auschließen, indem Du nicht irgendwas ausliest, sondern die gerade geschriebenen Daten (vorher unbedingt den Cache leeren: echo 3 > /proc/sys/vm/drop_caches).

----------

## AROK

 *schachti wrote:*   

> 
> 
> Kannst Du auschließen, indem Du nicht irgendwas ausliest, sondern die gerade geschriebenen Daten 

 

So hatte ich das eh gemacht. Den Cache hatte ich allerdings außer acht gelassen. 

Hab es noch mal wiederholt und jedes mal nach einem Kopiervorgang den Cache geleert. 

Die Ergebnisse unterscheiden sich aber kaum von den Vorherigen. D

vorher:

von sdc7 nach sda2: 65MB/s

von sda2 nach sdc7: 10MB/s

jetzt:

von sdc7 nach sda2: ca 40MB/s

von sda2 nach sdc7: ca 8-10MB/s

EDIT:

kann denn von euch jemand abschätzen, ob die 10MB/s realistisch wären für den inneren Bereich der Festplatte? Und warum ich 100% Prozessorlast habe beim Kopieren?

----------

## schachti

 *AROK wrote:*   

> 
> 
> kann denn von euch jemand abschätzen, ob die 10MB/s realistisch wären für den inneren Bereich der Festplatte?
> 
> 

 

Wenn es eine aktuelle Desktop-Festplatte mit 7200 U/min ist, wäre das eigentlich zu wenig - mindestens 20 MB/s sollten meiner Erfahrung nach möglich sein.

----------

## AROK

 *schachti wrote:*   

> 
> 
> Wenn es eine aktuelle Desktop-Festplatte mit 7200 U/min ist, wäre das eigentlich zu wenig - mindestens 20 MB/s sollten meiner Erfahrung nach möglich sein.

 

Ja, ist eine Solche. Dann können wir  das Geometriethema abhaken. 

Was könnte denn noch die Ursache sein?

----------

## ChrisM87

Hallo,

ohne jetzt den ganzen Thread gelesen zu haben, aber wie wäre es, statt dem Kopieren mal nur das Schreiben oder Lesen zu testen? Zum Beispiel mit Bonnie++ oder auch einfacher mit dd (und dann entweder mit vmstat live zugucken oder die Statistik am Ende des dd-Aufrufs abwarten).

ChrisM

----------

## AROK

 *ChrisM87 wrote:*   

> Hallo,
> 
> ohne jetzt den ganzen Thread gelesen zu haben, aber wie wäre es, statt dem Kopieren mal nur das Schreiben oder Lesen zu testen? Zum Beispiel mit Bonnie++ oder auch einfacher mit dd (und dann entweder mit vmstat live zugucken oder die Statistik am Ende des dd-Aufrufs abwarten).
> 
> ChrisM

 

Sorry hat etwas gedauert....

Bonnie++ einaml mit 5, einmal mit 10MB

```

# bonnie++ -d./ -s5 -r2G -n10 -u1000

Using uid:1000, gid:100.

Writing a byte at a time...done

Writing intelligently...done

Rewriting...done

Reading a byte at a time...done

Reading intelligently...done

start 'em...done...done...done...done...done...

Create files in sequential order...done.

Stat files in sequential order...done.

Delete files in sequential order...done.

Create files in random order...done.

Stat files in random order...done.

Delete files in random order...done.

Version 1.93c       ------Sequential Output------ --Sequential Input- --Random-

Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--

             Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP

             5M   548  96 +++++ +++ +++++ +++  1305  89 +++++ +++ +++++ +++

Latency             67010us      19us      20us   10281us      14us    8944us

Version 1.93c       ------Sequential Create------ --------Random Create--------

                  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--

              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP

                 10 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

Latency              2830us    1425us    2501us    1388us    1256us    1952us

1.93c,1.93c,1,1194367638,5M,,548,96,+++++,+++,+++++,+++,1305,89,+++++,+++,+++++,+++,10,,,,,

+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,67010us,19us,20us,10281us,

14us,8944us,2830us,1425us,2501us,1388us,1256us,1952us

#bonnie++ -d./ -s10 -r2G -u1000

Using uid:1000, gid:100.

Writing a byte at a time...done

Writing intelligently...done

Rewriting...done

Reading a byte at a time...done

Reading intelligently...done

start 'em...done...done...done...done...done...

Create files in sequential order...done.

Stat files in sequential order...done.

Delete files in sequential order...done.

Create files in random order...done.

Stat files in random order...done.

Delete files in random order...done.

Version 1.93c       ------Sequential Output------ --Sequential Input- --Random-

Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--

                Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP

                10M   563  95 +++++ +++ +++++ +++  1259  79 +++++ +++ +++++ +++

Latency             75826us     222us      22us    6098us      12us   42831us

Version 1.93c       ------Sequential Create------ --------Random Create--------

                  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--

              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP

                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

Latency             17148us    5969us    2661us    1341us    1315us    2605us

1.93c,1.93c,1,1194367554,10M,,563,95,+++++,+++,+++++,+++,1259,79,+++++,+++,+++++,+++,16,,,,,

+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,75826us,222us,22us,6098us,

12us,42831us,17148us,5969us,2661us,1341us,1315us,2605us

```

Ist das ausreichend? Oder soll ich eine gößere Größe nehmen?

Gruß

AROK

*edit* Zeilenumbrüche zur besseren Lesbarkeit eingefügt -- think4urs11

----------

## AROK

Hi,

hab noch mal was anderes getestet: 

kopieren von /dev/zero nach auf die Platte bringt auch nur etwa 10 MB/s.

Was meint ihr, kann das an der Platte liegen, soll ich eine Neue kaufen?

Gruß AROK

----------

## AROK

```

# tune2fs -l /dev/sda2

tune2fs 1.40.2 (12-Jul-2007)

Filesystem volume name:   <none>

Last mounted on:          <not available>

Filesystem UUID:          e0334208-8000-4905-a324-4c0fd9c1a615

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file

Filesystem flags:         signed directory hash

Default mount options:    (none)

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              9781248

Block count:              19531023

Reserved block count:     976551

Free blocks:              14433129

Free inodes:              9206322

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      1024

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         16384

Inode blocks per group:   512

Filesystem created:       Mon Aug 27 20:14:22 2007

Last mount time:          Wed Nov 14 17:44:43 2007

Last write time:          Wed Nov 14 17:44:43 2007

Mount count:              14

Maximum mount count:      -1

Last checked:             Tue Nov  6 18:26:12 2007

Check interval:           2592000 (1 month)

Next check after:         Thu Dec  6 18:26:12 2007

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

First orphan inode:       3653649

Default directory hash:   tea

Directory Hash Seed:      5bda2ab6-ac55-4349-a1b6-6612c73789ac

Journal backup:           inode blocks

# tune2fs -l /dev/sdc7

tune2fs 1.40.2 (12-Jul-2007)

Filesystem volume name:   <none>

Last mounted on:          <not available>

Filesystem UUID:          e0838ad0-71f2-40aa-898f-4680fbe8676e

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file

Filesystem flags:         signed directory hash

Default mount options:    journal_data

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              31670272

Block count:              63340270

Reserved block count:     3167013

Free blocks:              26201646

Free inodes:              31616605

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      1008

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         16384

Inode blocks per group:   512

Filesystem created:       Sat Sep 22 22:31:05 2007

Last mount time:          Wed Nov 14 17:44:45 2007

Last write time:          Wed Nov 14 17:44:45 2007

Mount count:              19

Maximum mount count:      24

Last checked:             Thu Nov  1 11:22:26 2007

Check interval:           15552000 (6 months)

Next check after:         Tue Apr 29 12:22:26 2008

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

Default directory hash:   tea

Directory Hash Seed:      6ad0d849-3e91-4eb6-948c-6be81974bb79

Journal backup:           inode blocks

```

Könnte es am  *Quote:*   

> 
> 
> Default mount options:    journal_data

 

liegen  :Question:   das ist nur bei der langsamen Platte gesetzt.

Wär echt schön, wenn noch Jemand einen Tipp hätte, ist echt nervig, das langsame Ding   :Evil or Very Mad: 

Gruß

AROK

----------

## AROK

Hi,

ich versuche mal ein paar ext3 Optionen ausprobieren, die evtl was brigen könnten.

aber tune2fs wie auch e2fsck verweigern die Arbeit:

 *Quote:*   

> 
> 
>  e2fsck -D /dev/hdc7
> 
> e2fsck 1.40.2 (12-Jul-2007)
> ...

 

Habt ihr eine Ahnung woran das liegen kann?

Gruß

AROK

----------

## SvenFischer

der Feystemcheck geht glaube ich nur, wenn die Partition nicht eingebunden ist. Evtl. liegt es ja daran?

----------

## AROK

 *SvenFischer wrote:*   

> der Feystemcheck geht glaube ich nur, wenn die Partition nicht eingebunden ist. Evtl. liegt es ja daran?

 

ja, richtig, ich hab die Partition zuvor aber auch unmountet.

Gruß

AROK

----------

## AROK

Hi,

ich bin der Lösung nahe  :Very Happy:   es liegt definitv an ext3  :Exclamation: 

nach dem hier:

http://www.ibm.com/developerworks/linux/library/l-fs8.html#4

habe ich die Partition mal mit "data=writeback" gemountet und siehe da: Vervierfachung der Transferrate auf etwa 40-50 Mb/s  :Exclamation: 

Werde mir mal die Optionen von ext 3 näher anschauen. 

Komisch nur, dass tune2fs und e2fsck auf der Partition nicht funktionieren. Vielleicht ist da etwas kaputt gegangen und deswegen wird die Parttion auch anders gemountet als die anderen   :Question: 

Gruß

AROK

----------

## AROK

Hallo,

hat leider nur kurz funktioniert (cachen, irgendsowas...) Jetzt kopiere ich wieder mit 5MB/s   :Crying or Very sad: 

Jetzt stehe ich wieder am Anfang!

----------

## AROK

Hallo,

war leider Quatsch, was ich oben geschrieben habe   :Embarassed:  , liegt wohl nicht an ext3. 

Hab jetzt mal die Platte an einen anderen Controller angeschlossen, ist aber das gleiche wie zuvor!

Hat noch Jemand eine Idee für mich   :Sad: 

Grüße

AROK

----------

## AROK

Jetzt habe ich mal alles von der Platte gepackt und auf eine Andere verschoben und wieder zurück (in 2 Etappen) zum defragmentieren. Hat auch nichts gebracht. Auffällig war aber, das die Kopiergeschwindigkeit Vezeichnisabhängig zu seien scheint.

----------

