Corrupte files bij simpele acties, HD is ok

[Wizzkid007]

Hallo mede-tweakers,

Ik vermoed dat een server van mij (treazoweb01) raar aan het doen is, of ik doe iets compleet verkeerd, maar dat betwijfel ik uiteraard

specs:
uname -a: Linux treazoweb01 2.6.24-23-server #1 SMP Mon Jan 26 01:36:05 UTC 2009 x86_64 GNU/Linux
Distro: Ubuntu 8.04.2 Server x64
uptime: 03:35:08 up 141 days, 3:03, 2 users, load average: 0.00, 0.04, 0.14
default server installatie met daarna via apt-get apache, php, mysql e.d. er op gezet.

Het volgende is het geval.

Een bestand (g2data.tar, 1,5GB) heb ik via wget (via http protocol) en via rsync naar de server gegooid. Daar eenmaal aangekomen kijkt het bestand corrupt geraakt te zijn op eenzelfde manier als dat via FTP ASCII mode zou gebeuren (snelle google search na foutmeldingen van tar). md5 sum klopt ook niet.

Correcte md5 sum. dit is op de bron-locatie, tar accepteert dit, ik weet dat dit correct is:

code:

d4a38f1e825750f63aec5ef23a9e4d3f  g2data.tar

Nadat het bestand verstuurd is naar de server (via wget of rsync) controleer ik de md5 hash, deze klopt dan niet. Het downloaden via http naar mijn laptop (macbook pro, via safari) gaat wel gewoon goed, dus het probleem ligt bij de ontvangende kant (treazoweb01).

Vervolgens laat ik rsync een poging doen (gaat wat sneller dan het hele bestand weer opnieuw te versturen). rsync kan checksums maken van bestanden en alleen dat deel transferen wat corrupt is (-c optie), maar elke keer als ik het commando uitvoer is de md5 weer anders. Je zou verwachten dat dit werkt, of minstens de checksum consistent zou blijven.

code:

root@treazoweb01:/var/www/gallery/data# rsync -a -z -v --progress -c "[e-mail]::tmp/" /var/www/gallery/data --password-file=/file/location/hidden
receiving file list ... 
4 files to consider
./
g2data.tar
  1623658125 100%   11.98MB/s    0:02:09 (xfer#1, to-check=2/4)

sent 282254 bytes  received 4394315 bytes  25766.22 bytes/sec
total size is 1623664629  speedup is 347.19
root@treazoweb01:/var/www/gallery/data# md5sum g2data.tar
79121e61372986930f1eea882387e1db  g2data.tar
---------------------------------------------------------------------------------------------------------------------
root@treazoweb01:/var/www/gallery/data# rsync -a -z -v --progress -c "[e-mail]::tmp/" /var/www/gallery/data --password-file=/file/location/hidden
receiving file list ... 
4 files to consider
g2data.tar
  1623658125 100%   12.57MB/s    0:02:03 (xfer#1, to-check=2/4)

sent 282248 bytes  received 1532160 bytes  8872.41 bytes/sec
total size is 1623664629  speedup is 894.87
root@treazoweb01:/var/www/gallery/data# md5sum g2data.tar
10b44541204e76cc69623474da110918  g2data.tar

Eerst dacht ik een protocol, netwerk of versie probleem van rsync misschien, maar dat verklaart niet waarom na een wget (http protocol) of volledige rsync overdracht (dus geen binary compare/sync met de -c optie) de hashes nog niet kloppen.

Op beide servers (bron server en doel server) exact dezelfde rsync versie:

code:

root@treazoweb01:/var/www/gallery/data# rsync --version
rsync  version 2.6.9  protocol version 29
Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.
<http://rsync.samba.org/>
Capabilities: 64-bit files, socketpairs, hard links, symlinks,
              batchfiles, inplace, IPv6, ACLs,
              64-bit system inums, 64-bit internal inums

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

nja.. goed, wat simpele dd comando's dan... Zie het volgende:
3x hetzelfde commando uitvoeren resulteert 3x in dezelfde md5 hash:

code:

root@treazoweb01:/var/www/gallery/data# dd if=g2data.tar bs=50M skip=0 count=10 | md5sum
10+0 records in
10+0 records out
524288000 bytes (524 MB) copied, 2.87598 s, 182 MB/s
e777053e6aaa5800be16d167d01ff1b0  -

root@treazoweb01:/var/www/gallery/data# dd if=g2data.tar bs=50M skip=0 count=10 | md5sum
10+0 records in
10+0 records out
524288000 bytes (524 MB) copied, 2.86631 s, 183 MB/s
e777053e6aaa5800be16d167d01ff1b0  -

root@treazoweb01:/var/www/gallery/data# dd if=g2data.tar bs=50M skip=0 count=10 | md5sum
10+0 records in
10+0 records out
524288000 bytes (524 MB) copied, 2.85268 s, 184 MB/s
e777053e6aaa5800be16d167d01ff1b0  -

echter, schijf in het resultaat weg i.p.v. er een md5sum van te genereren, dan klopt het ineens niet meer, elke keer krijg ik een andere hash.

code:

root@treazoweb01:/var/www/gallery/data# dd if=g2data.tar bs=50M skip=0 count=10 > part1.500M 
10+0 records in
10+0 records out
524288000 bytes (524 MB) copied, 5.22855 s, 100 MB/s
root@treazoweb01:/var/www/gallery/data# md5sum part1.500M 
02a144bab3d83b0c1403227667a1d861  part1.500M

root@treazoweb01:/var/www/gallery/data# dd if=g2data.tar bs=50M skip=0 count=10 > part1.500M 
10+0 records in
10+0 records out
524288000 bytes (524 MB) copied, 4.29699 s, 122 MB/s
root@treazoweb01:/var/www/gallery/data# md5sum part1.500M 
2ab448c47b22b250c15d8d4d4111a46f  part1.500M

Dezelfde tests op de bron-server (PowerPC Mac Mini eerste generatie, G4 CPU) levert wel correcte MD5 hashes op. Op beide servers geeft badblocks commando ook geen error's (jah, hij heeft er een goede 1,5 uur over gedaan )

Doe ik nou iets verkeerd, of is de server (treazoweb01) gaar aan het worden?
Zijn er meer tests (iets voor de CPU of memory) wat ik via ssh kan uitvoeren?
Ohja, ook niet onhandig om te weten: fysieke toegang tot de server is wat lastig. Hij staat niet echt in de buurt.

Op deze tests na functioneert de server verder prima, nooit iets mee aan de hand geweest.

edit: toevoeging: wget vanaf andere locaties gaat ook niet goed (1000mb). 32mb en 100mb gaan wel goed:

code:

root@treazoweb01:/tmp# wget http://speedtest.bbned.nl/download/file1000mb.bin
--04:32:34--  http://speedtest.bbned.nl/download/file1000mb.bin
           => `file1000mb.bin'
Resolving speedtest.bbned.nl... 62.177.145.10
Connecting to speedtest.bbned.nl|62.177.145.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,048,576,000 (1000M) [application/octet-stream]

100%[====================================================================>] 1,048,576,000    7.89M/s    ETA 00:00

04:34:09 (10.54 MB/s) - `file1000mb.bin' saved [1048576000/1048576000]

root@treazoweb01:/tmp# md5sum file1000mb.bin 
337f303d6a623cd84345aeb20faaecc1  file1000mb.bin
root@treazoweb01:/tmp# rm file1000mb.bin 
root@treazoweb01:/tmp# wget http://speedtest.bbned.nl/download/file1000mb.bin
--04:34:28--  http://speedtest.bbned.nl/download/file1000mb.bin
           => `file1000mb.bin'
Resolving speedtest.bbned.nl... 62.177.145.10
Connecting to speedtest.bbned.nl|62.177.145.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,048,576,000 (1000M) [application/octet-stream]

100%[====================================================================>] 1,048,576,000    9.36M/s    ETA 00:00

04:36:08 (9.93 MB/s) - `file1000mb.bin' saved [1048576000/1048576000]

root@treazoweb01:/tmp# md5sum file1000mb.bin 
8fba93e85b645aaad09d5492cb47affc  file1000mb.bin
root@treazoweb01:/tmp#

[ Voor 14% gewijzigd door Wizzkid007 op 03-08-2009 04:44 ]

[_JGC_]

Erg raar wat dat ding doet. Als je 10x een md5sum van hetzelfde bestand trekt, heb je dan ook 10x een andere md5sum?
Aan je uptime te zien draai je iig niet de laatste kernel voorzien van alle security updates. Inmiddels heeft Ubuntu het een en ander aan kernel updates uitgebracht voor jouw versie, ik raad je aan om die te installeren en te rebooten (ja, voor kernels moet je rebooten ).

[Wizzkid007]

een simpele

code:

md5sum filename

resulteert altijd in dezelfde hash, dus ik vermoed schrijf-actied of netwerk corruptie tijdens downloaden.

de update en reboot ga ik straks even proberen

[Verwijderd]

Wanneer ik dit zo lees dan denk ik eerder aan data corruptie op netwerk niveau dan de server zelf. Zeker als je het vanaf andere locaties hebt geprobeerd en daar hetzelfde resultaat krijgt.

Ben benieuwd wat de kernel update/reboot gaat opleveren

[ Voor 5% gewijzigd door Verwijderd op 03-08-2009 12:47 ]

[Wizzkid007]

De tijd op de server liep een 20 min. voor, dit heb ik opgelost door nu dagelijks te syncen met een ntp server. (crontab: 0 * * * * /usr/sbin/ntpdate pool.ntp.org > /dev/null)

Na een apt-get update, upgrade en reboot de volgende info:

uname -a: Linux treazoweb01 2.6.24-23-server #1 SMP Wed Apr 1 22:14:30 UTC 2009 x86_64 GNU/Linux
uptime: 14:20:44 up 15 min, 1 user, load average: 0.00, 0.09, 0.11

Ik lijk dus niet een nieuwere versie te hebben, maar wel een image die later gecompiled is.
apt-get update/upgrade heeft geen nieuwe packages, maar wel:
The following packages have been kept back:
linux-image-server linux-server

Problemen zijn in ieder geval nog niet op gelost, wget http://speedtest.bbned.nl/download/file1000mb.bin geeft nog steeds verschillende hashes.

Op een windows-server geeft dit wel dezelfde hashes. Ook op mijn andere linux server (mac mini) werkt dit prima (kernel Linux navi 2.6.24-19-powerpc #1 Wed Aug 20 18:48:30 UTC 2008 ppc GNU/Linux). Correcte hash lijkt te zijn: f795d0a0b6f58e0b588cca6e2344f560, zou iemand dat even kunnen controleren voor mij?

Ik ben nu via rsync opnieuw mijn bestand (g2data.tar, 1,5GB) aan het versturen, eens kijken wat daar uit komt, maar ik verwacht niet veel goeds. (ETA: ruim een uur)

Tests in het onderstaande codeblok lijkt in ieder geval niet te duiten op een HD probleem (let op dat dit dus incorrecte hashes zijn, maar de hashes zijn wel consistent zodra het bestand eenmaal op de HD staat):

code:

root@treazoweb01:/tmp# md5sum file1000mb.bin 
0856c25fec6dfe93238f809cbeb26405  file1000mb.bin
root@treazoweb01:/tmp# md5sum file1000mb.bin 
0856c25fec6dfe93238f809cbeb26405  file1000mb.bin
root@treazoweb01:/tmp# md5sum file1000mb.bin 
0856c25fec6dfe93238f809cbeb26405  file1000mb.bin
root@treazoweb01:/tmp# md5sum file1000mb.bin 
0856c25fec6dfe93238f809cbeb26405  file1000mb.bin
root@treazoweb01:/tmp# cp file1000mb.bin file1000mb2.bin 
root@treazoweb01:/tmp# md5sum file*
0856c25fec6dfe93238f809cbeb26405  file1000mb2.bin
0856c25fec6dfe93238f809cbeb26405  file1000mb.bin

(gekke is dus dat bestanden van 32mb en 100mb wel goed gaan, maar het 1000mb bestand of mijn eigen bestand (g2data.tar, 1,5GB) gaat dus niet goed)

[ Voor 6% gewijzigd door Wizzkid007 op 03-08-2009 14:37 ]

[Sprite_tm]

Misschien een idee om es te kijken waar de verschillen zitten? Dus of het enkele bytejes zijn die omgevallen zijn, missensde segmenten, een hele sector (=512b) die stuk is, ...? Daarvoor zou je eens vbindiff kunnen installeren en dat 2 bestanden voeren (het liefst een goede en een slechte) en met 'enter' doorgaan naar het (volgende) verschil.

[Wizzkid007]

Sprite_tm, bedankt voor de tip, ik zal er mij later vandaag of morgen even in verdiepen, echter heb ik wat anders gevonden:

code:

root@treazoweb01:/tmp# echo 1 > /proc/sys/vm/drop_caches
root@treazoweb01:/tmp# cp file1000mb.bin file1000mb2.bin 
root@treazoweb01:/tmp# echo 1 > /proc/sys/vm/drop_caches
root@treazoweb01:/tmp# md5sum file*
8170fd6b4a3c6f85aa756303ad37160b  file1000mb2.bin
b8a73a100e8f8365882bb59e91b0ccd4  file1000mb.bin

auw... dit zou toch gewoon goed moeten gaan?

edit: na een test op mijn mac mini, gaat bovenstaande gewoon goed. Volgensmij is er toch wat aan de hand met de HD. het systeem heeft 4 gig ram, files zoals g2data.tar en file1000mb.bin passen in zijn geheel in de cache.

edit2: een test met vbindiff tussen file1000mb.bin en file1000mb2.bin laat zien dat er een enkele bit omgevallen is. Meer verschillen dan deze ene bit zijn er niet in het hele bestand.

[ Voor 32% gewijzigd door Wizzkid007 op 03-08-2009 15:08 ]

[Emmeau]

Deze ellende ben ik een keer tegen gekomen met SATA schijven die keurig werkte tenzij je er lompe hoeveelheden data heenstuurde.

Bleek dat de sata kabeltjes het probleem waren, nieuwe erop, en gaan als een speer.

[Wizzkid007]

HD is inderdaad een sata-schijf. Zodra ik de kans heb zal ik de kabel vervangen, maar dat kan een paar dagen duren. Bedankt voor de tip.

[hostname]

Wizzkid007 schreef op maandag 03 augustus 2009 @ 14:34:
...
Ik lijk dus niet een nieuwere versie te hebben, maar wel een image die later gecompiled is.
apt-get update/upgrade heeft geen nieuwe packages, maar wel:
The following packages have been kept back:
linux-image-server linux-server
...

Dan is je kernel dus niet geupdate. aptitude/apt-get install linux-image-server doet dan de daadwerkelijke kernel update.

[u_nix_we_all]

Sowieso in dit soort gevallen je geheugen controleren (memtest86+)

[zkiwi]

hostname schreef op maandag 03 augustus 2009 @ 15:12:
[...]

Dan is je kernel dus niet geupdate. aptitude/apt-get install linux-image-server doet dan de daadwerkelijke kernel update.

Volgens mij is het apt-get dist-upgrade.

[Wizzkid007]

met een dist-upgrade kun je naar een ubuntu 9.x ofzo i.p.v. dat je op je huidige release blijft, met apt-get install linux-image-server update hij idd de kernel, echter wacht ik daar nog even mee, ik heb op het moment niet zo'n zin om er heen te moeten als ie onderuit gaat, vanavond kan het wel weer denk ik.

Ik verwacht dat het de sata-kabel is, dus ik ga die eerst proberen vervangen te krijgen voordat ik verder ga.

[ Voor 15% gewijzigd door Wizzkid007 op 03-08-2009 15:29 ]

[Verwijderd]

Dit lijkt op een schijf die gewoon lastig doet.

Probleem is is dat vaak controle op niets uitwijst, omdat het niets vinden kan. Maar bij gewoon gebruik treed het wel op.

[Emmeau]

kabels een keer lostrekken, en goed aandrukken.

Het hele bevestigingsmechanisme van SATA vind ik echt een ramp. De beste kabeltjes die ik tot nu toe tegengekomen ben zijn van het type met een metalen lipje/veertje erin.

[Wizzkid007]

HD, sata kabel en kernel zijn het alle 3 niet. nieuwe verse ISO van ubuntu gedownload (x64, 8.04, nieuwe kernel) op een nieuwe HD gezet met een nieuwe sata kabel en bovenstaande problemen doen zich nog steeds voor

next up: server tijdelijk virtualiseren en de fysieke hardware aan een test gooien (cpu, memory, hd, etc). ben wel benieuwd of dezelfde problemen ook onder virtualisatie aanwezig zullen zijn, verwacht het niet.

[DrClaw]

zet smart aan in je bios

kijk of je drive smart aan kan
# smartctl -i /dev/sdb

zet het daadwerkelijk aan
# smartctl -s on -d ata /dev/sdb

en run een test
# smartctl -d ata -H /dev/sdb

[Wizzkid007]

Smart was available en enabled, test resultaat op beide HD's:
SMART overall-health self-assessment test result: PASSED

leek mij ook al sterk dat het de HD zou zijn na het plaatsen van een 2e HD met een nieuw OS
sda is nu de nieuwe HD (160 gig) met een nieuw OS, bevat alleen OpenSSH en standaard LAMP
sdb is de bestaande hd (250 gig) met bestaande OS, bevat alles wat de server draait
Server boot nu naar sdb

Ik heb wel een ander kort vraagje: is het mogelijk een memtest, superpi, prime95 of iets dergelijks uit te voeren vanaf de ssh prompt? Rebooten en memtest opstarten is namelijk geen optie aangezien ik geen fysieke toegang heb de komende paar weken. Ik ben zelf a.s. maandag ook 2 weken op vakantie.

Als het 't geheugen niet is, dan moet het 't moederbord zijn verwacht ik.

[Wizzkid007]

Software van de server is nu gevirtualiseerd (met dd een image gemaakt) en dezelfde tests gaan nu gewoon goed. De hardware draait nu Windows XP 32bit en draait ook goed tot nu toe.

Hardware is inmiddels aan verschillende tests onderworpen (o.a. memory, cpu, disk) en alles lijkt te werken

Dit lijkt dus een compatibiliteits issue geweest te zijn.

HP levert zelf support op Red Hat, dus dat zou ik nog een keer kunnen proberen, maar aangezien XP nu goed draait terwijl dat niet supported is, denk ik dat Red Hat ook wel goed zal draaien.

Ik blijf het vaak vinden, maargoed.

Topic mag van mij closed. Tnx voor alle hulp!.