Neu im forum, grüße und Frage

<===|~Phlummi~>

<===|~Phlummi~>

Active Member
Hallo @all,
ich bin neu in diesem Forum und möchte zuersteinmal alle hier grüßen und mich kurz vorstellen. Selbstverständlich habe ich auch gleich eine Frage.

Bin 37 Fachinformatiker und neu auf dem BSD, Unix, Linux Gebiet. Server konfigurieren ist eines meiner Hobbys, ;-) und das Arbeiten am Computer habe ich nun zu meinem Beruf gemacht. Seit einem Halben Jahr Selbständig treibe ich mein Unwesen im Norden Deutschlads. Das sollte erst einmal reichen.

Nun zu meinem Problem.
Free BSD 5.4 als Headless Samba Server. Konfiguration via Webmin und ssh im eigenen Lan.

Beim Speichern großer Dateimengen bekomme ich nun immer wieder das Problem das zu lange Dateinamen ein Inkonsistentes Dateisystem erzeugen, bzw einen absturz des Systems bzw. nichterreichbarkeit erzeugen. Reeboot ist dann nicht mehr möglich nur ein Reset. Meist muß ich dann aber die Graka wieder einbauen und per Konsole das Dateisystem auf Konsistenz prüfen. Danach funzt auch alles wieder. Das Problem scheint mir bei zu langen Dateinamen zu liegen.
Installiert habe ich das Standard Dateisystem mit sysinstall. Also die empfohlenen voreinstellungen von BSD. Vielleicht weiß jemand eine Lösung für das Prob.
Der vorherige Thread zum Thema Linux und BSD im selben Dateisystem ist zwar Interessant doch hilft er mir nicht so wirklich bei meinem Problem.
Für Eure Hilfe bin ich schon einmal im vorraus Dankbar.
Viele Grüße eines Neueinsteigers.
PS. Mir sind noch nicht alle Shell Befehle geläufig, bei Fragen bzw. Antworten wäre es noch hilfreich mir den betreffenden Befehl zu nennen. Syntax usw. suche ich mir dann schon selber raus.
THX
Phlummi
 
Viel zu wenige Details.

Bau mal die Grafikkarte ein, schließ eine Tastatur an und mache die "umfangreichen Datenoperationen", die Du hier beschreibst. Dann schau auf die Systemkonsole und sag uns was das System hat, wenn es nicht mehr erreichbar ist.

Wir brauchen:
- Fehlermeldungen
- Logs
 
der inhalt der konfigurationsfiles waere auch nicht schlecht.
zusammen mit der ausgabe von dmesg. und spaeter dann fdisk und disklabel
 
Werde das machen. Sobald der Fehler wieder Auftritt. Muß dann ja eh die GraKa wieder einbauen.
Kann aber schon mal eines sagen, an den zu Langen Dateinamen bzw. zu tiefer Dateiverwurzelung liegt es nicht. Wollte den Fehler gerade mit extrem Langen Dateinamen und tiefer Verwurzelung replizieren, und bekam den Fehler nicht.
Es muß also an der Datenmenge liegen die ich via Lan auf den Fileserver schiebe. Hatte selbiges Problem auch unter Suse 9.3. Ich versuche ca. 57 GB Daten einer Windose auf den Fileserver zu Schaufeln. Das scheint nicht in einem zu funzen. Werde das jetzt einmal stückchenweise versuchen. Sobald der Fehler wieder auftaucht. Melde ich ihn sofort.
THX
 
boote die kiste auch noch mal im safemodus, und guck nach ob der immer noch die gleichen probs hat.

ABGESEHEN DAVON: ohne internas ueber den server koennen wir dir ABSOLUT nicht helfen.
 
Nein, vorher.
Wie nakal schon gesagt hat.
Bevor der Fehler wieder auftritt, sollst Du den Bildschirm und die Tastatur anschließen.
Sonst siehst Du ja wieder nix.
 
Hallo,

also es liegt nicht an den Dateinamen oder ähnliches.
Ich habe das selbe Problem hier bei mir.
Windows sendet unter bestimmten Umständen (zu große Dateien, zu viele...??) ein _sehr_großes Ethernet Frame. Das bringt FreeBSD (bzw den Netzwerktrieber oder was auch immer) zum Absturz (lokales Arbeiten ist also noch möglich).
Es erscheint dann so eine Meldung wie
Received package with size 333680 dropped, maximal MTU 1500
Zum Vergrößern anklicken....
.
Nach dem was ich bisher gelesen habe liegt das an Windows. Aber evtl. gibt es ja eine Möglichkeit die Samba/FreeBSD Installation so zu "tunen", dass das System nicht mehr hängen bleibt.
Ich werde mal verstärkt darauf achten ob dieser Fehler wieder auftritt.
Übrigens: Wenn ich mit einem FreeBSD Client auf Samba zugreife ist mir das noch nie passiert.

//edit:
hier mal links, die evtl. helfen könten, oder ein gute ansatzpunkt sind um mal weiterzusuchen:
http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html
http://groups.google.de/group/comp....842f49fbef2/c51a7dc5c78b0838#c51a7dc5c78b0838
 
Zuletzt bearbeitet:
Bis jetzt noch keinen Fehler, 4 gb übertragen und alles in kleinen Häppchen.

Danke Gathen, jetzt wo ich Deine Fehlermeldung sehe fällt mir diese auch wieder ein. Richtig selbiges Prob unter Suse gehabt, Lokales Arbeit war möglich.

Da jetzt Headless muß ich Reset machen und dardurch kommt es zum Inkonsistenten Dateisystem. So stelle ich mir das jetzt einmal vor.

Habe jetzt Monitor Angeschlossen und kann so im Falle des Problems Fehler melden.

Auf welcher MTU steht denn die Einstellung standardmäßig bei Free BSD?
Eigentlich sollten sich doch beide nic`s beim Handshake auf die niedrigste MTU einigen oder nicht?
Möglicherweise sollte man diese Händisch (sry für den Microsoft Ausdruck) :p
auf 1502 stellen?
 
<===|~Phlummi~> schrieb:
Da jetzt Headless muß ich Reset machen und dardurch kommt es zum Inkonsistenten Dateisystem. So stelle ich mir das jetzt einmal vor.
Zum Vergrößern anklicken....

Jo, so wird's wohl sein.

<===|~Phlummi~> schrieb:
Auf welcher MTU steht denn die Einstellung standardmäßig bei Free BSD?
Eigentlich sollten sich doch beide nic`s beim Handshake auf die niedrigste MTU einigen oder nicht?
Möglicherweise sollte man diese Händisch (sry für den Microsoft Ausdruck) :p
auf 1502 stellen?
Zum Vergrößern anklicken....

Also standardmäßig wird die MTU auf 1500 gesetzt. Man könnte natürlich die MTU auch auf eine extrem hohen Wert setzen, allerdings ist das ja Unsinn und behebt das eigentliche Problem nicht...
Windows scheint die MTU wohl in diesem Fall zu "ignorieren" und sendete einfach wild drauflos.
Am besten wäre es wohl einfach mal herauszufinden wann der Fehler genau auftritt. Ich habe die Beobachtung gemacht, dass es beim Schreibzugriff mit großen und/oder vielen Dateien von einem Windows Client (XP Pro) zu dem Problem kommt.
 
Ja, ist ein Windows Problem. !!!!
Sorry Leute,
Bin die sache nun andersherum angegangen. Thx Gathen!

Ich habe von einem W2KServer auf den anderen (ist daher kein xp Prob) ca 50 gb Daten geschaufelt. Problem tritt auch auf. Kleinere Datenmengen ohne Probleme.

Sorry, werde mich dann wohl ins MCSE Forum begeben müssen. Zumindest für dieses Problem.

Thx @all
 
Danke Dettus, Problem habe ich schon im MCSE Forum gepostet. Mal sehen was dort dabei heraus kommt. Möglicherweise gibt es eine Lösung. Die MTU Händisch hochzusetzen behalte ich mir als letzte alternative vor. Da ich nicht weiß welche Nebenwirkungen das noch hat.
Alle Service Releases von Windows sind eh eingespielt.
Ich sag mir, wenn ich VW Fahre, nehme ich auch VW ersatzteile, auch wenn Jaguar oder Mercedesteile besser sind. :)

Mal schauen was dabei heraus kommt.
 
Windows sendet unter bestimmten Umständen (zu große Dateien, zu viele...??) ein _sehr_großes Ethernet Frame. Das bringt FreeBSD (bzw den Netzwerktrieber oder was auch immer) zum Absturz (lokales Arbeiten ist also noch möglich).
Zum Vergrößern anklicken....
ist aber nicht optimal wenn die kiste dann abschmiert... ->warum dropped er den frame nicht einfach?
 
soul_rebel schrieb:
ist aber nicht optimal wenn die kiste dann abschmiert... ->warum dropped er den frame nicht einfach?
Zum Vergrößern anklicken....

stimmt, das ist eher suboptimal ;) ...
Warum er abschmiert weiß ich allerdings nicht, laut Log wird das Paket aber gedropped.
 
Sry Antwort erst jetzt.
Er schmiert nicht ab, die Netzwerkverbindung bricht ab. Somit keine verbindung mehr zu dem Headless Server. Nach Reset kommt er dann auch wieder, ist aber nun schon zweimal passiert das ich das Dateisystem mit ckdsk oder so auf konsistenz Prüfen musste. Das muß ich aber vor dem start der NIC machen. Ergo, Graka einbauen und Tastatur, erst danach kann ich das Dateisystem wieder Reparieren. bzw. auf Konsistenz Prüfen. Es schmiert nur das Netzwerk ab.
Normalerweise sollte aber doch das unvollständige Paket erneut gesendet werden???
Ich glaube das meint Ihr mit Droppen?!
Tatsache ist, es passiert nur bei großen Datenmengen. Wenn ich die Daten in kleineren stücken Kopiere funzt es Problemlos. erst ab so ca. 4 bs 5 GB tritt dieses Problem auf.
Ich werde Morgen mal im Windows Forum nachschauen was sich dort zu dem Thema ergeben hat.
Erst mal vielen Dank für Eure Tipps, schön das man als Unix Linux BSD Anfänger hier Hilfe findet.
cu
 
ein "billigstes Mittel" ist ein Ethernet-DoS sicher nicht, da sowas nur in lokalen Netzwerken passieren kann (übers Internet geht das schon mal nicht), aber trotzdem nicht ganz unkritisch. Meine Frage hier wäre mal im allgemeinen, wie kann man Fehler im LinkLayer eigentlich debuggen?
 
Erst mal ein frohes neues Jahr.
Ich kann nicht sagen ob Samba abschmiert. Da ja die Netzwerkverbindung abbricht.
Ist so etwas denn ein DoS? Denied of Service heißt es glaub ich oder?
Sorry das ich mich noch so blöde im BSD Bereich anstelle!
 
Vergiss Moni/Tastatur. Klemm lieber ein Nullmodemkabel ran und aktiviere die serielle Konsole, dann kannst du auch bequem den panic-String abgreifen (wie das geht, dem Handbuch entnehmen).

6.0 waere auch dem 5.4 vorzuziehen, aber egal ob es ein Windows-Problem ist oder nicht, die Kiste darf nicht abstuerzen, deshalb wuerde ich folgendes machen.

0. 6.0 installieren.
1. Moni/Tasta weg
2. Serielle Konsole hin
3. Kernel mit KDB+DDB bauen
4. Die serielle Konsole von einer anderen Kiste aus beobachten und warten, bis der Fehler wieder auftritt.
5. Den Backtrace an stable@freebsd.org senden.
 
Oh mann, das ist doch für mich alles noch recht schwierig.
Habe gerade 6.0 Installiert. Da ich noch ein anderes Problem hatte.
Ich melde mich sobald das System dann läuft. Ich bekomme mit der 6.0 Probleme meine NIC zu starten. Aber das bekomme ich bestimmt in den Griff, soll hier nicht Thema dieses Threads sein.
 
Hallo @ all,
ich habe es nun geschafft, 6.0 läuft stabil. Die Probleme mit der NIC habe ich auch in den Griff bekommen. 6.0 scheint anders auf BIOS einstellungen zu reagieren wie 5.2. Was das Problem mit dem abbrechen der Netzwerkverbindung angeht so kann ich berichten das sich dieses Problem seit umstellung auf 6.0 und nutzung einer 3Com NIC nun nicht mehr ergeben hat.
Somit sind vorerst alle meine Probleme in dieser hinsicht gelöst. ;'(

Damit kann ich gar nicht gut um, werde mir jetzt ein neues Problem suchen.

cu und thx
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben