hallo!
ich habe einen rechner aufgesetzt mit fedora (fc3), der als fileserver dienen soll. samba ist installiert und funktioniert auch. allerdings stürzt der rechner (zufällig) ab (kein anpingen möglich), wenn größere dateien hochgeladen werden (>100MB).
in den logfiles ist imho nichts zu finden.
mein letzter rettungsversuch war der wechsel der realtek- zur 3com-netzwerkkarte, allerdings erfolglos.
hat jemand noch einen rat für mich?
ps: ist mein erster post hier. ein freund hat mich auf euch aufmerksam gemacht. ich hoffe ich mach hier nix verkehrt :)
Hi Roger,
du must das Problem eingrenzen..
was stürzt ab – der Server oder geht nur das Netz nicht ?
Erzeuge eine Datei – 1,5 x grösser als der Hauptspeicher am besten – mittels
dd if=/dev/urandom of=testfile bs=1M count=
und kopiere sie mehrmals hin und her ($HOME nach /tmp und zurück oder so, oder über mehrere Platten wenn du hast).
Crasht es hier: Probleme mit dem Server (Hardware, evtl. Memory, memtest mal laufen lassen). Diese Variante ist möglich, aber eher unwahrscheinlich (bei der Installation sind ja auch grosse Dateien dabei),
Kopiere die Datei von einer Remote-Maschine (mittels ftp, sftp etc.)
Crasht es hier: Probleme mit dem Server, evtl. NIC / Plattencontroller in Kombi..
Kopiere die Datei mittels smbclient auf eine andere Maschine; crasht es dann, ist eher ein Problem mit Samba.
Ist es eine SMP-Maschine ? Benutzt du ACPI auf Single-CPU ? Wie sind die Interrupts gelagert (Plattencontroller, NIC). Was für Clients nutzt du (W2K, XP etc.)
CU
Michael
Hi,
naja, da kann es natürlich eine Vielzahl von Ursachen geben, der Samba-prozess, selber, ein Hardware-problem (nicht nur der Netzwerkkarte).
Vielleicht kannst Du es mit den folgenden Maßnahmen ein wenig eingrenzen:
Was passiert, wenn Du eine große Datei (>100MB) quer über die Platte, zum Beispiel nach /tmp, kopierst?
Was passiert, wenn Du von Deinem Windows-Rechner aus, zum Beispiel mit WinSCP eine Datei auf den Samba-Server schiebst?
Verabschiedet sich der Rechner eigentlich am Anfang des Kopiervorgang, am Ende oder zwischendurch?
Trage in der smb.conf den Parameter log level =3 ein und starte den Samba-Server neu. Versuche wieder den Upload. Befinden sich in der DAtei /var/log/samba/log.smbd irgendwelche Hinweise?
Viel Glück & Erfolg,
Stefan
—
********************************************
in-put GbR – Das Linux-Systemhaus
Stefan-Michael Guenther
Moltkestrasse 49 D-76133 Karlsruhe
Tel./Fax : +49 (0)721 / 83044 – 98/93
http://www.in-put.de
********************************************
Schulungen Installationen Support
********************************************
hab gerade mal eine datei (1,4gb) versucht, auf die andere platte zu kopieren. und schwupps war er wech. 2% hab ich noch im mc gesehen, ab da an war er nicht mehr anpingbar.
ich komme leider nur per per vpn in das netzwerk, wo der rechner steht (steht nicht unmittelbar neben mir). deswegen dauern evtl. antworten etwas länger ;)
verabschiedet hat sich der rechner generell mittendrin. also 2% war bisher das schnellste ;) aber manchmal klappt es auch komplette dateien zu kopieren :(
ich hab mal ne große datei hin und herkopiert. ergebnis siehe weiter unten.
ein memory test werd ich nächste woche mal in angriff nehmen, der dauert ja immer ne weile…
der rechner hat ein etwas älteres elitegroup-board mit sis-chipsatz und einen betagteren amd-prozessor (wenn ich die daten irgendwo auslesen kann, würde ich das gern mal machen, mir fehlt aber das wissen / die befehle dazu).
die clients sind win xp, win2k und mac os x.
was vielleicht noch interessant ist: drin steckt ein promise controller (ich glaub tx4), 4 platten (1×2 hd’s raid 0; softwareraid).
Hallo Roger,
>was vielleicht noch interessant ist:
Jau…
Softwareraid macht die Sache natürlich komplizierter. Aus (kurzer) Erfahrung heraus, IMHO: niemals Softwareraid, schon gar nicht Level 0, und schon überhaupt nicht mit der Platte wo das OS drauf ist 8-[ …
Wenn du durchgängigen Platz benötigst empfehle ich LVM (s.u).
Einfache Infos zur Hardware bringt das proc-Dateisystem,
cat /dev/cpuinfo
sagt genug über die CPU, Parameter von Platten findest du unter /dev/ide bzw. /dev/scsi, Speicher unter /proc/meminfo.
Desweiteren helfen lspci und lshw..
Das ist aber hier aber nicht wirklich wichtig, wichtig ist
– welches Linux
– Plattenconfig (/etc/fstab)
– Speichergrösse
Wenn das Teil bei einem Hoster steht, hast du ja evtl. Zugriff auf die Konsole via Lara oder so.. (Romteconsole via TCP/IP). An das Teil musst du schon ran, sonst nützt das hier nix.
CU
Michael
[1] http://www.selflinux.org/selflinux/html/lvm.html
Ich sehe das anders: Niemals Hardware RAID;-)
Wenn der Hardware RAID Controller durchbrennt stehst Du ganz schön im Regen:
Du brauchst denselben Controller (gelegentlich sogar mit identischer
Firmwareversion, und finde die mal raus, wenn der Controller hin ist!), um
wieder an Deine Daten zu kommen. Da ist ein Software RAID deutlich einfacher
was die Datenrettung angeht…
Bei dem “schon überhaupt nicht mit der Platte wo das OS drauf ist” muss ich
Dir aber voll zustimmen.
Bei LVM aber wieder nicht: Platten mit LVM zusammenzuhängen vergrößert die
Ausfallwahrscheinlichkeit der virtuellen Platte. Es reicht schließlich wenn
eine der beteiligten Platten ausfällt, um die Daten zumindest teilweise zu
schreddern. Bei so einer Konstellation ist ein regelmäßiges Backup noch
wichtiger als sowieso schon.
Hallo Tobias,
jedem seine Meinung. Wenn man ein RAID einsetzt, macht man das üblicherweise zur Datensicherheit (Redundanz, Ausnahme Level 0). Deshalb sichert man die Daten möglichst nachts noch einmal woanders hin, um diese Sicherheit noch einmal zu erhöhen (vorallem wenn die Nutzer aus “Versehen” löschen).
Softwareraids werden im ungünstigsten Fall beim Boot von der Distri-CD nicht erkannt…
Mir ist noch NIE ein RAID-Controller abgebrannt, gute Controller können die vorhandenen Platten in ihrer Reihenfolge erkennen und wieder einbinden, zumindest meine ich das bei IPC Vortex schon gesehen zu haben, vielleicht war es auch Mylex (ist schon etwas her).
RAID Level 0 (und darum geht es hier) aka Striping ist a) eigentlich kein RAID und b) der absolute Supergau beim Ausfall einer Platte. Da die Blöcke abwechselnd auf beide Platten verteilt werden, wars das dann bei einem Fehler.
Inwieweit sich dazu LVM verhält, kann ich so nicht sagen. Im Bezug auf das Problem – und um das OS vom Software-RAID herunterzuhalten – halt ich es für eine adequate Lösung.
Generell kann ich dir nicht zustimmen, dass LVM die Ausfallwahrscheinlichkeit erhöht; wenn ich LVM auf einem RAID1 oder RAID5 mache, so ist das völlig unabhängig davon.
Ich würde immer wieder – auch wenn mal ein Controller “abbrennt” – ein Hardware-RAID nehmen, sofern bezahlbar. Der zusätzliche Luxus, eine Ebene weniger im Plattensubsystem zu haben, ist es mir Wert (unabhängig von LVM).
CU
Michael
Bis vor dem Gau, den ich mit einem Hardware-RAID erleben durfte, hätte ich Dir
in allen Punkten recht gegeben. Wahrscheinlich tue ich das auch wieder, wenn
mir mal ein Software RAID um die Ohren fliegt;-)
so.
das wochenende hab ich mal die säge rausgeholt und hab mich direkt vor den server gestellt.
um es kurz zu machen: das dateisystem hatte einen defekt. der server lief zwar noch weiter, aber an der konsole konnte man zumindest den fehler schonmal angezeigt bekommen. ;)
behoben hab ich es, indem ich die platte formatiert habe. allerdings auch auf umwegen, weil die kiste plötzlich mittendrin stehen blieb (nicht einmal mehr die numtaste war willig).
nunja, die daten darauf sind erstmal weg, ist aber nicht so schlimm (backup ist da ;))
die frage die mich jetzt noch interessiert:
wie kann ich in zukunft vermeiden, das das filesystem (ext3) beschädigt wird? bzw. wie geht sowas überhaupt?
btw: danke für die vielen tips. hat mir echt weitergeholfen!
Ein Journaling Filesystem kann eigentlich nur aus zwei Gründen beschädigt
werden:
1) Kernelfehler: Der Kernel schreibt Unsinn auf die Platte. Dann brauchst Du
einen neuen Kernel ohne Fehler (zumindest an der Stelle). Wenn Du einen
stabilen Kernel einsetzt, dann sollte diese Art von Fehler nicht auftreten.
2) Plattenfehler: Der Kernel schreibt sinnvolle Daten auf die Platte, die
daraus Unsinn macht. Dagegen kannst Du Dich nicht wirksam schützen.
Regelmäßige Prüfläufe mit fsck können aber helfen solche Platten frühzeitig zu
entdecken, genauso wie eine “Gesundheitskontrolle” der Platte über die SMART
Funktionalität (da gibt es Dämonen für, die diese Informationen ständig
auswerten und Warnungen ausspucken, idealerweise bevor die Platte ganz kaputt
ist).
Deiner Platte mit dem fehlerhaften Dateisystem würde ich jedenfalls nicht mehr
genug trauen, um darauf wichtige Daten abzulegen.
wo du recht hast… ich hab mich zu früh gefreut oder auf’s heftigste selbst überschätzt.
ich habe eben den server wieder eingebaut. nach ausgiebigen testen hier im büro (knapp 10gb hin und her kopiert). hier lief alles fehlerfrei.
nachdem ich das (scheiß)serverding wieder eingebaut habe und stolz zeigen wollte, dass es wieder geht (habe von einer w2k-ws per samba eine 300mb datei rüberkopieren wollen), sah ich noch im augenwinkel die console, wie da plötzlich merkwürdige fehlermeldungen auftauchten, mit dem alten resultat: aufhängen des systems.
die fehlermeldungen lauteten (hab sie abgekritzelt):
status=0x51 {DriveReady SeekComplete Error}
error=0x14 {DriveStatusError SectorIdNotFound}
die meldungen sind ab jetzt immer reproduzierbar. ein fsck brachte mir auch keine fehlermeldungen weiter…
also doch ein hardware-defekt?
(ich würde es gern vorher genau wissen, bevor ich 150,- investiere – klar, garantie ist auch noch drauf, aber bei einer umtauschzeit von 6 wochen will ich gar nicht weiter drüber reden).
—
ich hau’se wech! … ich hau’se wech!
weiß keiner weiter?
ich hab gestern die hd ausgetauscht. seitdem ist nat. keine fehlermeldung mehr aufgetaucht. mal sehen, was der seagate support zu der (meiner meinung nach) defekten platte sagt.
ich halt euch auf dem laufenden…
Hallo!
Heute habe ich eine neue Platte vom Händler bekommen, der die alte eingeschickt hatte. Leider wurde auf jegliche Erklärungen verzichtet (wäre doch interessant gewesen). Einzigstes Wort auf der Rückgabeliste war: Ausgetauscht.
Also kann man zumindest davon ausgehen, das die Platte tatsächlich defekt war. Es handelte sich übrigens um eine Seagate 200GB ST3200822AS. Schade, war ich doch bisher von der Zuverlässigkeit dieser Baureihe überzeugt…