Extremer Laufzeitunterschied beim Zählen/Aufsummieren von Dateien auf gleichen HDDs

Dalai

Grand Admiral Special
Mitglied seit
14.06.2004
Beiträge
7.420
Renomée
262
Standort
Meiningen, Thüringen
Hey Leute :),

ich wende mich mal wieder vertrauensvoll an euch, um zu versuchen, ein kurioses Phänomen zu (er)klären. Es geht um ein Selbstbau-NAS (normale PC-Hardware) mit zwei identischen SATA-Platten mit nahezu identischem Inhalt. Die Platten erhalten ihre Daten mittels rsnapshot vom Server, d.h. hier wird massiv mit Hardlinks gearbeitet. Doch erstmal zur Hardware:
Code:
root@pluto:/# smartctl -Ai /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.13.0-29-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD20EFRX-68EUZN0
Serial Number:    <unwichtig>
LU WWN Device Id: 5 0014ee 209bed93b
Firmware Version: 80.00A80
User Capacity:    2.000.398.934.016 bytes [2,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   9
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Fri Aug 29 16:33:55 2014 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   173   171   021    Pre-fail  Always       -       4308
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       2368
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       13
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       114
194 Temperature_Celsius     0x0022   112   106   000    Old_age   Always       -       35
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0


root@pluto:/# smartctl -Ai /dev/sdc
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.13.0-29-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD20EFRX-68EUZN0
Serial Number:    <unwichtig>
LU WWN Device Id: 5 0014ee 25f1411f7
Firmware Version: 80.00A80
User Capacity:    2.000.398.934.016 bytes [2,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   9
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Fri Aug 29 16:33:55 2014 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   172   171   021    Pre-fail  Always       -       4366
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       2368
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       36
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       13
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       96
194 Temperature_Celsius     0x0022   111   106   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

root@pluto:/# hdparm -tT /dev/sdb /dev/sdc

/dev/sdb:
 Timing cached reads:   3692 MB in  2.00 seconds = 1847.28 MB/sec
 Timing buffered disk reads: 412 MB in  3.01 seconds = 136.86 MB/sec

/dev/sdc:
 Timing cached reads:   3668 MB in  2.00 seconds = 1834.50 MB/sec
 Timing buffered disk reads: 402 MB in  3.01 seconds = 133.41 MB/sec
Wie man sieht, ist die eine HDD leicht langsamer als die andere (ein Lesen einer großen Datei mit dd und Ausgabe in /dev/null ergibt ähnliche Werte). Das ist zwar einerseits interessant und seltsam, andererseits ist das bereits seit Einbau der Platten bekannt.

Auf den HDDs befindet sich jeweils ein ext4-Dateisystem, die zur gleichen Zeit im Mai dieses Jahres angelegt wurden. Ein fsck darauf zeigt einen kleinen Laufzeitunterschied, der sich aber durch den leichten Geschwindigkeitsunterschied erklären lässt:
Code:
root@pluto:/# time fsck -f /dev/sdb1; time fsck -f /dev/sdc1
fsck von util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
BackupDisk1: 1363040/122101760 Dateien (0.2% nicht zusammenhängend), 233247494/488378368 Blöcke

real    2m13.198s
user    0m29.810s
sys     0m8.844s

fsck von util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
BackupDisk2: 1294694/122101760 Dateien (0.2% nicht zusammenhängend), 234213398/488378368 Blöcke

real    2m21.853s
user    0m30.498s
sys     0m8.343s
Soweit so normal. Nun kommen wir zum Teil, den ich überhaupt nicht kapiere: ein Aufsummieren mit du -sh oder ein find -type f ergibt einen Laufzeitunterschied zwischen den Platten um knapp Faktor 3 (in Worten drei)! :o
Code:
root@pluto:/# time find /media/backup1 -type f | wc -l
5315004

real    7m20.819s
user    0m26.423s
sys     1m52.715s

root@pluto:/# time find /media/backup2 -type f | wc -l
4922198

real    20m4.032s
user    0m27.491s
sys     1m59.091s

Zusammenfassung:
  • zwei gleiche Platten mit leichtem Geschwindigkeitsunterschied mit erst drei Monate alten ext4-Dateisystemen.
  • auf der schnelleren Platte befinden sich laut fsck 1,36 Mio Dateien, die durch Hardlinks laut Zählung auf 5,3 Mio erhöht werden.
  • auf der langsameren Platte befinden sich laut fsck 1,29 Mio Dateien, die durch Hardlinks laut Zählung auf 4,9 Mio erhöht werden.
  • auf der langsameren Platte befinden sich also weniger Dateien (sowohl echte als auch verlinkte) und trotzdem braucht sie fast dreimal soviel Zeit, um diese zu zählen *kopfkratz
  • das System verwendet eine SSD fürs System und tut zum Zeitpunkt des Zählens/Aufsummierens nichts.
Normal finde ich das nicht. Kann mir jemand einen Hinweis geben, ob da ein Fehler vorliegt, und wo der zu suchen sein könnte?

MfG Dalai
 
Zuletzt bearbeitet:
Sind die Partitionen aligned?
Bringt ein Test mit bonnie++ auch so einen großen Unterschied zu tage?
Bei einem Test mit bonnie++ nicht vergessen mehr GB als Speicher vorhande ist zu verwenden
und auch den -n Test durchführen etwa mit -n100:128:0
 
Zuletzt bearbeitet:
Sind die Partitionen aligned?
Selbstverständlich:
Code:
root@pluto:/# fdisk -l

Disk /dev/sda: 63.0 GB, 63023063040 bytes
255 Köpfe, 63 Sektoren/Spur, 7662 Zylinder, zusammen 123091920 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x0006164e

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *        2048     2099199     1048576    b  W95 FAT32
/dev/sda2         2099200   123090943    60495872    5  Erweiterte
/dev/sda5         2101248    18878463     8388608   83  Linux
/dev/sda6        18880512   123090943    52105216   83  Linux

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Festplattenidentifikation: 0x000ba1a3

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdc1            2048  3907028991  1953513472   83  Linux

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Festplattenidentifikation: 0x00050bd8

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1            2048  3907028991  1953513472   83  Linux
/dev/sda ist die SSD, die anderen beiden sind die HDDs.

Bringt ein Test mit bonnie++ auch so einen großen Unterschied zu tage?
Bei einem Test mit bonnie++ nicht vergessen mehr GB als Speicher vorhande ist zu verwenden
und auch den -n Test durchführen etwa mit -n100:128:0
OK, schau ich mir mal an und melde mich wieder. Eine Frage noch: Ist es für den Benchmark ein Problem, wenn das System keinen Swap hat?

MfG Dalai
 
Ich würde eine swapdatei anlegen die Du dann wieder entfernen kannst. (swapon, swapoff)
Ein System ohne swap ist Unsinn.
 
Ein System ohne swap ist Unsinn.
Naja, so pauschal sehe ich das nicht. Da das System sonst nichts zu tun hat und nur Datensicherung betreibt, wird der RAM eh fast nur mit Cache und Buffer gefüllt, also gibt es nichts auszulagern.

Ich bin mir unsicher, in welchem Format ich die Ergebnisse von bonnie++ hier posten soll. Tabellen sind ja möglich, aber die colspans im HTML machen's nicht einfach... Daher vorerst Bilder:
sdb
attachment.php


sdc
attachment.php


MfG Dalai
 

Anhänge

  • sdb_full.png
    sdb_full.png
    23,9 KB · Aufrufe: 301
  • sdc_full.png
    sdc_full.png
    23,9 KB · Aufrufe: 295
Zuletzt bearbeitet:
schaut grob gleich schnell aus
 
Sidn die Platten INTERN gleich aufgebaut? Oder hat eine ggf. 4 die andere 5 Plattern? Alle Platten auf gleichen APM Level? Kannst du z.B. mit HDTACH setzen.

Und selbst da gibt es unterschiede in der Fertigungsqualität und wie schnelle die Platte auf die Spuren zugreifen kann.
 
Sidn die Platten INTERN gleich aufgebaut? Oder hat eine ggf. 4 die andere 5 Plattern? Alle Platten auf gleichen APM Level? Kannst du z.B. mit HDTACH setzen.

Und selbst da gibt es unterschiede in der Fertigungsqualität und wie schnelle die Platte auf die Spuren zugreifen kann.

Bonnie zeigt, dass die Random Seeks und die sequenzielle Datenrate cirka gleich sind, was bedeutet die Platten _sind_ praktisch gleich schnell.
Es muss offenbar an etwas anderem liegen.

@Dalai:
Geht auch ein Tar auf /dev/null unterschiedlich lang?
 
Zuletzt bearbeitet:
Sidn die Platten INTERN gleich aufgebaut? Oder hat eine ggf. 4 die andere 5 Plattern?
Als umsichtiger Käufer habe ich die Platten natürlich vor dem Einbau gewogen: die eine wiegt 595g und die andere 600g, die haben also beide je zwei Platter.

Alle Platten auf gleichen APM Level? Kannst du z.B. mit HDTACH setzen.
Die sollten auf demselben Level sein, nämlich APM deaktiviert, wie das nach meiner Erfahrung bei allen Platten ist. AAM unterstützen beide laut hdparm nicht. HD Tach kann ich schlecht einsetzen, denn hier geht es um ein Linux-System, das ich mangels physischem Zugriff nicht "mal eben" mit einem BartPE o.ä. booten kann.

Und selbst da gibt es unterschiede in der Fertigungsqualität und wie schnelle die Platte auf die Spuren zugreifen kann.
Siehe die hdparm- und bonnie-Benchmarks. Es sind leichte Unterschiede zu sehen, aber das ist bekannt. Das erklärt aber noch lange nicht den extremen Laufzeitunterschied von fast Faktor 3.

Bonnie zeigt, dass die Random Seeks und die sequenzielle Datenrate cirka gleich sind, was bedeutet die Platten _sind_ praktisch gleich schnell.
Naja, netghost hat schon recht: Sequential Input (Chars, Blocks) weicht bei sdc in dem einen Durchlauf extrem ab und im anderen Durchlauf hat sie immerhin die doppelte Verzögerung (Chars) bzw. fast die doppelte (Blocks) wie sdb.

Geht auch ein Tar auf /dev/null unterschiedlich lang?
Wird sofort getestet.

MfG Dalai
 
Zuletzt bearbeitet:
char input ist vollkommen unwichtig und hängt fast zu 100% von der cpu ab was die gerade macht.
Bei diesem geht es um einzelne bytes die gelesen werden! -> irrelevant
 
Irgendwie check ich das nicht mit dem tar auf /dev/null. Ich bekomm's nicht hin, dass er was tut. Egal, ob ich
Code:
tar -cf - /media/backup1/somedir >/dev/null
#oder
tar -c /media/backup1/somedir >/dev/null
#oder
tar -cf /dev/null /media/backup1/somedir
oder ähnliche Dinge verwende, tar kehrt sofort zurück, ohne etwas zu tun. Gibt man stattdessen eine Zieldatei auf einem Datenträger an (auch in der Umleitung!), tut er was. Andere Leute hatten ebenfalls diese Beobachtung gemacht: http://www.unix.com/ubuntu/118752-tar-not-reading-if-output-directed-dev-null.html
Laut dieser Aussage soll es aber so funktionieren: http://www.redhat.com/archives/rhl-list/2005-May/msg00783.html (auch wenn die schon fast 10 Jahre alt ist). Tut es aber nicht *kopfkratz.

MfG Dalai

--- Update ---

Keine Ahnung, was die Autoren von tar genau bewogen hat, explizit auf /dev/null zu prüfen, und zwar auch dann, wenn die Redirection darauf erfolgt, aber sei's drum. Man muss sich nur zu helfen wissen ;). Ich hab mal pv (Pipe Viewer) dazwischengeklemmt und das sind die Ergebnisse:
Code:
root@pluto:/# time tar -cf - /media/backup1/monthly.0/daten/Archiv/ | pv -terb > /dev/null
tar: Entferne führende „/“ von Elementnamen
6,63GB 0:01:33 [72,7MB/s]B/s]

real    1m33.409s
user    0m4.838s
sys     0m30.456s

root@pluto:/# time tar -cf - /media/backup2/monthly.0/daten/Archiv/ | pv -terb > /dev/null
tar: Entferne führende „/“ von Elementnamen
6,63GB 0:01:44 [65,1MB/s]

real    1m44.297s
user    0m5.032s
sys     0m31.566s
Das Verzeichnis enthält 6,7G an gemischten Dateien, meist relativ kleine. sdc ist hier also schon 11 Sekunden langsamer (macht ~11,7%). Aber warum? *noahnung* Und 11% sind eben auch noch nicht einmal in der Nähe von fast 300%...

MfG Dalai
 
Ich würde es einfacher tun: tar cf /dev/null /blablubb

EDIT: ups ich hatte überlesen, dass du das schon gemacht hast.

Tja, das bringt offenbar alle keine wirklichen Ergebnisse.
Keine Ahnung was das sein kann.

dmesg bringt kein ausgefallenen SATA Fehler oder sonst etwas Richtung IO?
 
Zuletzt bearbeitet:
dmesg bringt kein ausgefallenen SATA Fehler oder sonst etwas Richtung IO?
Nope:
Code:
root@pluto:/# dmesg | grep -i "ata"
[    0.000000] BIOS-e820: [mem 0x00000000d7df3000-0x00000000d7dfffff] ACPI data
[    0.000000]   NODE_DATA [mem 0x11fff9000-0x11fffdfff]
[    0.000000] Memory: 3829660K/4060696K available (7595K kernel code, 1136K rwdata, 3480K rodata, 1356K init, 1440K bss, 231036K reserved)
[    0.284357] libata version 3.00 loaded.
[    1.279105] acpi-cpufreq: overriding BIOS provided _PSD data
[    1.280411] Write protecting the kernel read-only data: 12288k
[    1.371998] scsi0 : pata_atiixp
[    1.372081] scsi1 : pata_atiixp
[    1.372108] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
[    1.372110] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
[    1.372399] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[    1.374804] ata3: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f100 irq 22
[    1.374806] ata4: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f180 irq 22
[    1.374809] ata5: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f200 irq 22
[    1.374811] ata6: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f280 irq 22
[    1.374813] ata7: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f300 irq 22
[    1.374816] ata8: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f380 irq 22
[    1.695829] ata7: SATA link down (SStatus 0 SControl 300)
[    1.695882] ata8: SATA link down (SStatus 0 SControl 300)
[    1.867856] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.867885] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.867910] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.867929] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.868322] ata3.00: ATA-9: SanDisk SDSSDP064G, 3.1.0, max UDMA/133
[    1.868326] ata3.00: 123091920 sectors, multi 1: LBA48 NCQ (depth 31/32)
[    1.868511] ata6.00: ATA-9: WDC WD20EFRX-68EUZN0, 80.00A80, max UDMA/133
[    1.868515] ata6.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    1.868523] ata5.00: ATA-9: WDC WD20EFRX-68EUZN0, 80.00A80, max UDMA/133
[    1.868527] ata5.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    1.869059] ata6.00: configured for UDMA/133
[    1.869104] ata5.00: configured for UDMA/133
[    1.869526] ata3.00: configured for UDMA/133
[    1.869743] scsi 2:0:0:0: Direct-Access     ATA      SanDisk SDSSDP06 3.1. PQ: 0 ANSI: 5
[    1.881538] ata4.00: ATAPI: PIONEER DVD-RW  DVR-221L, 1.00, max UDMA/100
[    1.894696] ata4.00: configured for UDMA/100
[    1.904414] scsi 4:0:0:0: Direct-Access     ATA      WDC WD20EFRX-68E 80.0 PQ: 0 ANSI: 5
[    1.904591] scsi 5:0:0:0: Direct-Access     ATA      WDC WD20EFRX-68E 80.0 PQ: 0 ANSI: 5
[    2.020234] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[    2.500783] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[    2.571031] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: acl,user_xattr
[    2.646348] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: acl,user_xattr
Die letzten Zeilen von dmesg zeigen nur das Mounten der Dateisysteme. /var/log/kern.log zeigt dasselbe.

Ist ja auch komplett neue Hard- und Software (bzw. drei Monate alt), also die Platten, das Board, die Kabel usw. und eben auch die Dateisysteme, die Installation etc.

Übrigens war der Unterschied am Anfang nicht so extrem, aber mit zunehmender Füllung der Platten (derzeit ~50%) wurde es schlimmer. Ich meine, richtig stören tut es nicht, solange die Laufzeit nicht quadratisch oder gar exponentiell zunimmt, aber merkwürdig ist es dennoch - und ich will natürlich schlimmeren Laufzeiten vorbeugen, sofern möglich.

MfG Dalai
 
Bringt ein "tune2fs -l" irgend einen Unterschied im filesystem?
 
Bringt ein "tune2fs -l" irgend einen Unterschied im filesystem?
Leider nichts relevates.
sdb1:
Code:
root@pluto:/# tune2fs -l /dev/sdb1
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   BackupDisk1
Last mounted on:          /media/backup1
Filesystem UUID:          52fc4f27-8821-44ba-a335-f0c1cc2bbcee
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378368
Reserved block count:     24418918
Free blocks:              255130874
Free inodes:              120738720
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun May 18 15:00:13 2014
Last mount time:          Tue Aug 26 02:05:22 2014
Last write time:          Fri Aug 29 16:12:11 2014
Mount count:              0
Maximum mount count:      38
Last checked:             Fri Aug 29 16:12:11 2014
Check interval:           15552000 (6 months)
Next check after:         Wed Feb 25 15:12:11 2015
Lifetime writes:          1048 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      636c31d3-e5f1-4d5b-a7e2-1ca6be81e495
Journal backup:           inode blocks

sdc1:
Code:
root@pluto:/# tune2fs -l /dev/sdc1
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:   BackupDisk2
Last mounted on:          /media/backup2
Filesystem UUID:          1a600d99-731f-45b0-ad92-e70b141de92f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378368
Reserved block count:     24418918
Free blocks:              254164970
Free inodes:              120807066
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun May 18 15:05:12 2014
Last mount time:          Fri Aug 29 02:16:20 2014
Last write time:          Fri Aug 29 16:14:24 2014
Mount count:              0
Maximum mount count:      38
Last checked:             Fri Aug 29 16:14:24 2014
Check interval:           15552000 (6 months)
Next check after:         Wed Feb 25 15:14:24 2015
Lifetime writes:          923 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      7d06c324-b46f-4d0c-b7f8-8e7940118cf6
Journal backup:           inode blocks

MfG Dalai
 
Hm, ich wüsste jetzt nicht was noch sein könnte.
Platztauschen wäre noch das letzte was ich tun würde um zu sehen ob der Fehler platzabhängig oder plattenabhängig ist.
 
Platztauschen wäre noch das letzte was ich tun würde um zu sehen ob der Fehler platzabhängig oder plattenabhängig ist.
Daran hab ich auch schon gedacht. Getestet wurde das kurz nach Einbau, als ich mich wunderte, dass die Platten in der Geschwindigkeit unterschiedlich sind (weil ein h2testw einen Laufzeitunterschied von 15-20 Min ergab), um rauszufinden, ob es an der Platte oder am SATA-Port liegt; die eine Platte ist wirklich etwas langsamer. Aber du hast recht, es wäre sinnvoll, das in der aktuellen Situation nochmals zu prüfen. Werden wir kommende Woche mal angehen. Ich vermute aber, dass sich am Ergebnis nichts ändert...

MfG Dalai
 
Was mich etwas irritiert, ist dass es auch deutlich sichtbare Zeitunterschiede im Kernelmode gibt. Das System scheint bei der langsameren Platte auch mehr im Kernel zu rechnen. Kannst du probieren, was passiert, wenn du die angeschlossenen Ports tauscht?
 
Was mich etwas irritiert, ist dass es auch deutlich sichtbare Zeitunterschiede im Kernelmode gibt.
Du meinst die 1m52 bei der einen im Vergleich zu den 1m59 bei der anderen Platte beim Zählen der Dateien? Ich find 7 Sekunden Differenz jetzt nicht so ungewöhnlich, wenn die Gesamtlaufzeit sich verdreifacht. Der Kernel muss ja auf das Gerät warten. Aber wahrscheinlich muss er in der Zeit nicht rechnen. Naja, ich bin da nicht so drin, und wundere mich nur über die Gesamtlaufzeit ;).

Kannst du probieren, was passiert, wenn du die angeschlossenen Ports tauscht?
Genau das hatte Tom ja bereits vorgeschlagen und heute haben wir die Platten umgesteckt. Ergebnis: die schnellere Platte braucht nun 12 (teilweise auch 14), die andere weiterhin 20 Minuten. Wichtig hierbei ist, dass die Erhöhung der Laufzeit bei der einen um 5-7 Minuten nicht am Umstecken lag, denn vor dem Umstecken brauchte diese Platte am Dienstag auch schon 14 Minuten zum Zählen. Die Ursache ist vielmehr darin zu suchen, dass am Dienstag ein Backup auf diese Platte lief, d.h. dort liegen mittlerweile mehr Dateien als bisher (5,7 Mio verlinkte). Vermutlich werden sich die 20 Minuten der langsameren Platte nach dem Backup in der kommenden Nacht noch weiter erhöhen.

Das Ergebnis ist, wie ich erwartet hatte: die eine Platte ist langsamer, egal, an welchem Port sie hängt. Ich werd morgen noch ein paar Durchläufe mit bonnie++ machen und dann die Ergebnisse hier posten.

MfG Dalai
 
Ist der Fragmentierungsgrad auf der einen Platte evtl. zu hoch? Ggfs. könnte man das Dateisystem neu aufsetzen und die Dateien wieder drauf schieben. Wie ist die CPU Last beim Durchführen der Zählung? Laufen die Platten vielleicht mit unterschiedlichen DMA Levels?
 
Ist der Fragmentierungsgrad auf der einen Platte evtl. zu hoch?
Das ist nicht der Fall, wie man an den bereits im OP gegebenen fsck-Ausgaben sieht: 0,2%.

Wie ist die CPU Last beim Durchführen der Zählung?
Normale Gerätewartezeit, sieht man ja auch an den Ausgaben von time, die ich jeweils vor die relevanten Befehle geschrieben habe.

Laufen die Platten vielleicht mit unterschiedlichen DMA Levels?
Nein, das würde sich schon stärker auf den Benchmark auswirken. Die Ausgaben von hdparm -I und smartctl -i (siehe OP) zeigen keine Unterschiede bis auf die Serial und die Unique ID.

MfG Dalai
 
Hier die bonnie-Benchmarks nach dem Umstecken/Tausch der Platten:

sdb (war vorher sdc):
attachment.php


sdc (war vorher sdb):
attachment.php


Bemerkenswert finde ich den Unterschied in der Latency beim Sequential Input (Blocks) zwischen den Platten: die eine hat 40-47ms, die andere 68-72ms. Vor dem Umstecken gab's da ja ähnliche Unterschiede.

Ergänzung: Die langsamere Platte (derzeit sdb) braucht nach dem Backup in der vergangenen Nacht nun 24 Minuten zum Zählen.

MfG Dalai
 

Anhänge

  • sdb_tausch.png
    sdb_tausch.png
    23,8 KB · Aufrufe: 185
  • sdc_tausch.png
    sdc_tausch.png
    23,9 KB · Aufrufe: 190
Aufgrund steigender Laufzeiten auf beiden Platten hab ich die Backup-Geschichte etwas umgestellt und verwende nun ein simples df zum Bestimmen des belegten Speicherplatzes. Das hat zwar den Nachteil, ungenauer zu sein, aber je einmal vor und nach dem Backup mehr als 20 Minuten Laufzeit von du sind einfach zu viel. Zumal das rsnapshot weiterhin unbekümmert in 13 Minuten durchgelaufen ist.

Ergebnis: Problem und dessen Ursache bleiben weiterhin ungeklärt, aber vorerst stört es nicht weiter.

Ungeachtet dessen danke ich allen Beteiligten! *great*

MfG Dalai
 
Ist eigentlich auch ein Laufzeitunterschied wenn Du "rsnapshot du" auf die beiden Platten laufen lässt?
 
Zurück
Oben Unten