kopieren traag in linux

[Verwijderd]

Ik heb al een tijdje Archlinux op mijn xp1800/512MB bak, en ik merkte het eerst niet zo, maar laatst viel het me op dat van partitie a naar partitie a kopieren gemiddeld maar zo'n 3,5 MB per seconde gaat... en in HDPARM staan 32bits i/o en dma wel aan.
Ik weet even niet waar het nu aan ligt.

de output van hdparm :

multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq=1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 81964302336, start = 0

[DeMoN]

En op welke schijf staan die partities? Op je eerste primare schijf?

geef eens in dat geval de output van:

hdparm -tT /dev/hda

Als je deze test goed wilt laten verlopen moet je eigenlijk zorgen dat de schijf die je test niet mounted is..

[dawuss]

En welke filesystems heb je op die partities?

Hier is de performance vanaf een zwaar gefragmenteerde FAT32 partitie naar een reiserfs partitie namelijk ook niet al te best. Ik defragmenteer de boel ook maar 1x per half jaar ofzo

[pierre-oord]

Snelheid moet je ook nog instellen.

hdparm -d1 -c3 -X68 /dev/hda

Uit m'n hoofd stelt dat je HDD in op UDMA 66 of het was 100. (Zie manpage -X optie. De -c optie was geloof ik de veiligste optie van de -c, er zijn ook nog snellere manieren, ik dacht c2 ofzo. Gewoon: man hdparm.

Als je HDD nu op DMA 33 staat kan dat toch een hoop schelen.

[nzyme]

uhm... waarom zou dat softwarematig moeten gwoon zorgen dat je de juiste flatcable gebruikt toch ?

[pierre-oord]

Hellraizer schreef op vrijdag 04 februari 2005 @ 11:04:
uhm... waarom zou dat softwarematig moeten gwoon zorgen dat je de juiste flatcable gebruikt toch ?

Ghehe, nee, zo simpel is het niet. Met Windows wel zo'n beetje, die kijkt gewoon meteen wat die schijf aan kan, ik linux moet je het even handmatig opgeven.

Wel heb ik eens debian testing gedraaid, die stond wel meteen goed geloof ik. Misschien dat stable liever voor "stable en werkend" kiest in dit geval.

HDparm geeft meestal wel aan als je de snelheid te hoog insteld dat de schijf het niet ondersteund en je pech hebt

man hdparm

edit:
En nog over die flatcables:
de 40 polige kabels zijn voor DMA <= 33 (dus met alle PIO modussen eronder)
De 80 polige (eigenlijk 40 polig, met 40 geaarde aders ertussen tegen interferrentie) is geschikt voor alles tot UDMA 100 (UDMA 133 was niet gemaakt voor parallel ata toch? Ik twijfel opeens daaraan.)

[ Voor 21% gewijzigd door pierre-oord op 04-02-2005 12:25 ]

[Gerco]

pierre-oord schreef op vrijdag 04 februari 2005 @ 12:23:
Ghehe, nee, zo simpel is het niet. Met Windows wel zo'n beetje, die kijkt gewoon meteen wat die schijf aan kan, ik linux moet je het even handmatig opgeven.

Voor zover ik weet is dat lang niet altijd nodig. Als je maar de goede chipset in de kernel gecompileerd hebt, zullen je drives op hun maximale snelheid ingesteld worden.

Ik heb tenminste niets zelf ingesteld behalve de chipset driver meecompileren en een hdparm -tT geeft dit:

code:

/dev/hda:
 Timing cached reads:   1640 MB in  2.00 seconds = 819.31 MB/sec
 Timing buffered disk reads:  152 MB in  3.01 seconds =  50.47 MB/sec

en dmesg | grep hda geeft

code:

hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133)

Auto detectie werkt hier dus prima. Dit is trouwens een PATA schijf en hij gebruikt UDMA133, dus blijkbaar is dat niet alleen voor SATA.

[ Voor 6% gewijzigd door Gerco op 04-02-2005 12:56 ]

[Creepy]

SATA is 150. PATA is max 133.

[Verwijderd]

Het zit zo, het is een kopie van een ext3 partitie naar diezelfde partitie op een andere dir.

Jullie zullen het wel vreemd vinden, maar ik gebruik de onboard IDE controller en niet de promise udma/133 controller, en de reden daarvoor is dat dat ding naar mijn weten alleen met autodetect werkt, en dat gaat zeer(!) traag, elke keer 10 seconden voor het proben van de IDE devices, terwijl de onboard standaard IDE controller het in een flits doet...

ik gebruik trouwens wel zo'n ouderwetse kabel (40draads?), maar ik denk niet dat dat het is, in windows haal ik met dezelfde test (fat32>fat32) 22MB/sec.

En fragmentatie, ik dacht dat eht defragmenteren van inode-filesystems zoals EXT*, reiserfs, XFS niet nodig was ?

[Verwijderd]

hdparm -tT op de drive waar het om gaat levert:

Timing cached reads: 511.06 MB/sec
Timin buffered disk reads: 17.64 MB/sec

Ik zal eens met de opties van hdparm kloten dan. Ik merkte dat mijn andere disk wel automatisch snel werkt, daar gaat het wel 23 MB/sec.

[Verwijderd]

Ik heb even geprobeerd, de i/o mode op 3 zetten met -c zorgde van 3MB/sec naar 9MB/sec, en met -X 68 naar 24MB/sec ! bedankt !

[Verwijderd]

Hm. even een schopje.

Ik merkte nl. dat hdparm nu wel lekkere waarden aangeeft, maar het kopieren gaat van schijf a naar schijf a nog steeds maar met zo'n 9MB/sec.

In het kernelconfiguratiemenu heb ik denk ik maar 1 keuze:
Devicedrivers - ATA/ATAPI/blaat support - VIA82CXXX chipset support

aangezien ik een Gigabyte GA7-VRXP(rev.2) heb met VIA chipset.

Nogmaals in Windows is de snelheid veel hoger... 20MB/sec van a naa r a en wel iets van 45MB/sec van a naar b...

[Keeper of the Keys]

Verwijderd schreef op vrijdag 04 februari 2005 @ 15:35:
Het zit zo, het is een kopie van een ext3 partitie naar diezelfde partitie op een andere dir.
(...)
ik gebruik trouwens wel zo'n ouderwetse kabel (40draads?), maar ik denk niet dat dat het is, in windows haal ik met dezelfde test (fat32>fat32) 22MB/sec.

Als ik je goed begrijp probeer je dus 'gewoon' naar een andere plek op dezelfde schijf te kopieren, als dat het geval is is het niet zo heel vreemd dat het langzaam gaat. Je schijf moet eerst informatie inlezen en dan weer op een andere plek wegschrijven, van een schijf naar een andere schijf kan veel sneller.

Verder is het (voor zover ik altijd heb begrepen) wel handig om als je een snelle (>=ata66) schijf hebt wel gebruik te maken van een 80-aderige flatkabel, bij 40 zou je nog weleens errors kunnen krijgen die door storing worden veroorzaakt.

[Verwijderd]

Maak gebruik van een 80-aderige kabel, en het kopieren van/naar een andere schijf gaat niet veel sneller. Kijk maar naar het getal. Bij 9MB/sec is het niet logisch dat de hdd de bottleneck is. Het moet de I/O afhandeling van het OS zijn. In Windows gaat, zoals gezegd, dezelfde operatie meer dan twee keer zo snel.

[pierre-oord]

Verwijderd schreef op donderdag 14 april 2005 @ 16:49:
Hm. even een schopje.

Ik merkte nl. dat hdparm nu wel lekkere waarden aangeeft, maar het kopieren gaat van schijf a naar schijf a nog steeds maar met zo'n 9MB/sec.

In het kernelconfiguratiemenu heb ik denk ik maar 1 keuze:
Devicedrivers - ATA/ATAPI/blaat support - VIA82CXXX chipset support

aangezien ik een Gigabyte GA7-VRXP(rev.2) heb met VIA chipset.

Nogmaals in Windows is de snelheid veel hoger... 20MB/sec van a naa r a en wel iets van 45MB/sec van a naar b...

Ik vraag het maar even: Je hebt wel beide HDD's met hdparm ingesteld toch he? Wat geeft een hdparm -tT , van beide schijven?

[Verwijderd]

/dev/hda:
Timing cached reads: 1160 MB in 2.00 seconds = 579.51 MB/sec
Timing buffered disk reads: 96 MB in 3.03 seconds = 31.68 MB/sec

/dev/hdb:
Timing cached reads: 1152 MB in 2.00 seconds = 574.94 MB/sec
Timing buffered disk reads: 152 MB in 3.01 seconds = 50.54 MB/sec


Maar zodra er gekopieerd wordt, gaat het bagger. 9 a 10MB/sec dus.
Dit is overigens van een ext3 partitie naar een andere ext3 partitie op een andere schijf (wel zelfde (80aderige) kabel).

[cashewnut]

Hoe heb je de partities gemount? IIRC kun je EXT3 journaling bij het mounten op drie manieren instellen: geen journaling, alleen metadata, of alle data. Bij de laatste instelling kopieert hij in feite alles 2x, dat zou het snelheidsverschil kunnen verklaren.

[Coen Rosdorff]

30MB/s enkel lezen en ook nog een reeks sectoren achter elkaar.
Dan is 9MB/s random sectoren lezen, en 9MB/s random sectoren schrijven helemaal geen slechte snelheid lijkt mij.

[Verwijderd]

Ik zal die mount opties eens uitproberen.


HdParm schrijft en leest idd sequentieel. Maar om realistische schijfactiviteit nou random te noemen ? Nee. Ik schreef naar een LEGE ext3 partitie dus da's net zo sequentieel als wat hdparm doet. Trouwens in WinXP haal ik dus wel die hoge snelheden (en da's ook niet altijd sequentieel)... OK OK NTFS is geen journaling system.

[Verwijderd]

uit het ext3-specifieke deel van man mount :

ordered
This is the default mode. All data is forced directly
out to the main file system prior to its metadata being
committed to the journal.

Dus hij staat niet op alle data eerst journallen.

Ik merk wel dat als ik die lege ext3 partitie als ext2 formatteer en mount, dat het dan wat sneller is.. vooral verderop in grote files keldert de snelheid niet zoals bij ext3..met ext2 haal ik 19 a 20MB/sec. van hda1 naar hda1