[SuSE 7.2]Samba loopt vast

[EXX]

Als ik grote files copieer van mijn win98 workstation naar een SuSE 7.2 servertje (voor backups) dan loopt na enige tijd de server vast. De Workstation geeft aan dat er niet meer geschreven kan worden. Winzip geeft als mogelijke fout 'disk full' (error 53). Tijdens de hele operatie heb ik op de server het 'top' command laten lopen. Dat bevriest ook bij de crash. Als laatste wordt aangegeven:

code:

 1:04pm  up 43 min,   1 user, load avarage 0.93, 0.38, 0.37
43 prosesses: 40 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 9.1% user, 80.7% system, 0.0% nice 10.1% idle
Mem:   37436K av, 36676K used     760K free, 0K shrd, 4016K buff
Swap: 136544K av,   236K used, 136308K free          22860K cached
PID USER    PRI  NI  SIZE  RSS  SHARE STAT %CPU %MEM TIME COMMAND
825 taurus   13   0  1820 1820   1504 R    36.2  4.8 6:13 smbd
  7 root     20   0     0    0      0 SW   32.1  0.0 5:27 bdflush
824 root     17   0   916  916    732 R     4.4  2.4 1:20 top
....

Het LEDje op de switch (op de poort voor de server) blijft gewoon groen.
De HDD LED op de server blijft continu branden.

Voor hardware specs: zie sig.

Op de server draait SuSE 7.2 met Samba. De Samba share wijst naar de tweede HDD, die met ReierFS is geformatteerd.

Alle stations op het LAN lopen op DHCP; DNS en DHCP server is een Speedstore modem/router.

[ Voor 12% gewijzigd door EXX op 30-03-2003 13:47 ]

[Verwijderd]

'disk full'

Een wilde gedachte misschien, maar wellicht is je vaste schijf vol

[Squee]

Krijg je geen kernel messages voordat hij op zijn bek gaat? Reboot je server, en kijk eens of je nog wat in je logs kan vinden... misscihen geeft je kernel daarin nog wel een aanwijzing dat het fout aan het gaan is voordat de boel helemaal op zijn bek gaat.

[EXX]

Verwijderd schreef op 30 March 2003 @ 14:04:
[...]
Een wilde gedachte misschien, maar wellicht is je vaste schijf vol

Nee hoor, het is een 120 GB disk. Zit er pas een paar dagen in en is vrijwel leeg.

Heb overigens voor de zekerheid een tijd lang memtest 3.0 laten lopen, en die geeft geen fouten.

Je krijgt geen core dumped op zoiets. Welke logs zijn interessant?

[ Voor 26% gewijzigd door EXX op 30-03-2003 16:35 ]

[Wilke]

Defineer 'grote file' - een file van >2 GB, heel toevallig?

Welke versie van Samba gebruik je, een kennis van me had soortgelijk gezeur, en dat was opgelost door Samba te upgraden naar de nieuwste versie.

Verder: Weet je zeker dat je servertje een HD van 120 GB aankan? Wat voor computer is het voor de rest? Ik weet dat het niet zou mogen uitmaken omdat Linux de BIOS-detectie zou negeren, maar ik ben afgelopen week nog een systeem tegengekomen dat keihard crashte zodra er werd geschreven op een bepaald deel van de HD (een partitie achteraan), maar na een BIOS-upgrade (zodat de harddisk in het BIOS goed herkend werd) werkte dit ineens perfect!

[EXX]

Voor de systemspec vd server en workstation: zie sig.

De files zijn niet groter dan 2 GB. De grootste was 700 MB.

Ik heb nog wat zitten te prutsen en het ziet er naar uit het wel werkt als ik een netwerk drive map maak in een DOS box en niet door de servername maar door het ip adres te gebruiken, en dan de files ook copy vanuit de DOS box.

Samba versie moet ik even opzoeken, maar het is de versie die standaard bij SuSE 7.2 wordt geleverd.

De 120 GB HDD is overigens niet de disk waarvan Linux boot; dat is een 6 GB HDD.

[Wilke]

Juist ja...een Pentium 75. Het zou me enorm verbazen als dat BIOS een 120 GB harddisk ondersteunt.

Linux boot waarschijnlijk dan ook wel prima, maar het gaat toch ook fout als je op de 120 GB harddisk schrijft? Wat zegt het BIOS over deze schijf - wordt 'ie correct gedetecteerd of niet?

[deadinspace]

Linux spreekt HDs direct aan, zonder daarbij van de BIOS gebruik te maken. De BIOS zou op dat moment dus geen roet in het eten moeten kunnen gooien. Maar je zou het kunnen proberen door samba naar die 6GB schijf te laten schrijven ipv naar de 120 GB schijf.

Als hij niet meer reageert, replied die machine dan nog pings? Hangt er een monitor aan, en zo ja: verschijnt daar iets op als het fout gaat? Kun je het probleem misschien ook op andere manieren uitlokken (hoge CPU load, of flink files kopieren bijvoorbeeld)?

[Verwijderd]

Misschien helpt het ook als je DMA voor je vaste schijven inschakelt. (man hdparm). Als al die grote bestanden via je CVE naar de vaste schijf worden gekopieerd, kan dit inderdaad flink beslag leggen op je computertijd. Zeker als het een oud beestje als een Pentium 75 MHz betreft.

[EXX]

Wilke schreef op 31 March 2003 @ 00:21:
Juist ja...een Pentium 75. Het zou me enorm verbazen als dat BIOS een 120 GB harddisk ondersteunt.

Linux boot waarschijnlijk dan ook wel prima, maar het gaat toch ook fout als je op de 120 GB harddisk schrijft? Wat zegt het BIOS over deze schijf - wordt 'ie correct gedetecteerd of niet?

Iig herkent BIOS de HDD type, vervolgens komt direct de Linux boot screen. Je ziet dus niet welke grootte BIOS aangeeft voor de HDD. Linux geeft de goede HDD capaciteit weer, ook het patitioneren en formatteren met ReiserFS gaf geen problemen.

deadinspace schreef op 31 March 2003 @ 01:49:
Linux spreekt HDs direct aan, zonder daarbij van de BIOS gebruik te maken. De BIOS zou op dat moment dus geen roet in het eten moeten kunnen gooien. Maar je zou het kunnen proberen door samba naar die 6GB schijf te laten schrijven ipv naar de 120 GB schijf.

Dat kan ik wel eens proberen.

Als hij niet meer reageert, replied die machine dan nog pings? Hangt er een monitor aan, en zo ja: verschijnt daar iets op als het fout gaat? Kun je het probleem misschien ook op andere manieren uitlokken (hoge CPU load, of flink files kopieren bijvoorbeeld)?

Nee, pingen kan niet meer en op de aangesloten monitor is er geen screen output als het fout gaat (geen kernel panic melding of iets dergelijks). Het top commando dat ik tijdens de hele operatie heb laten lopen bevriest ook; met de 'q' toets kom je niet meer naar de prompt, dus het hangt gewoon helemaal vast.

Om de zaak op een andere manier flink te belasten, zal eens kijken hoe.

Overigens zal ik vanavond nog wat meer onderzoek doen mbt het feit dat het gisterenavond het wel werkte vanuit een DOS box. Misschien dat het niet alleen aan de Linux machine ligt.

[Wilke]

[nohtml]

deadinspace schreef op 31 March 2003 @ 01:49:
Linux spreekt HDs direct aan, zonder daarbij van de BIOS gebruik te maken. De BIOS zou op dat moment dus geen roet in het eten moeten kunnen gooien.

Ja...dat dacht ik ook. Maar verklaar jij het verhaal dat ik hierboven schreef dan eens... computer wilde niet werken zodra we op de laatste paar partities schreven (van een te grote HD die het BIOS niet detecteerde), en wel zodra we het BIOS flashten zodat 'ie de grote HD herkende.

Maar je zou het kunnen proberen door samba naar die 6GB schijf te laten schrijven ipv naar de 120 GB schijf.

Yep, ben wel benieuwd of het dan ook fout gaat...?

[EXX]

Verwijderd schreef op 31 maart 2003 @ 09:14:
Misschien helpt het ook als je DMA voor je vaste schijven inschakelt. (man hdparm). Als al die grote bestanden via je CVE naar de vaste schijf worden gekopieerd, kan dit inderdaad flink beslag leggen op je computertijd. Zeker als het een oud beestje als een Pentium 75 MHz betreft.

Kan dat überhaupt wel? De HDD's lopen nu hoogstwaarschijnlijk op PIO4. Ik betwijfel of de IDE controller wel DMA ondersteunt; eerlijk gezegd heb ik geen idee (chipset is UMC UM8886BF/UM8891BF/UM8892BF). De HDD's ondersteunen wel UDMA/33 (6GB Quantum)en UDMA/100 (120 GB IBM).

[Verwijderd]

Geen idee of jou IDE-bestuurder DMA kan. Lijkt me wel de moeite waard om dat uit te zoeken

[EXX]

Verwijderd schreef op 31 maart 2003 @ 10:43:
Geen idee of jou IDE-bestuurder DMA kan. Lijkt me wel de moeite waard om dat uit te zoeken

Vind maar eens docu over zo een obscure chipset Na ja , ik (en google) ga mijn best doen...

edit:
Naar wat ik heb kunnen vinden is de UM8886BF idd DMA capable, maar met problemen in de 2.2 Kernels. Gelukkig draai ik een 2.4 kernel dus vanavond even kijken of DMA aanstaat.

[ Voor 26% gewijzigd door EXX op 31-03-2003 14:30 ]

[EXX]

Nou ben maar weer even aan het testen geslagen. Als eerste DMA aangezet. Dat scheelt een hoop in de CPU load: voorheen 10%, nu 35%-40% idle. smbd en bdflush gebruiken nu ieder iets van 20%-23% CPU voorheen rond de 35%.

Test 1: gebruik explorer
Een drive letter gemapt (N:) naar de server, gebruik makende vd servernaam dus \\gemini\NetworkDisk. Dan HDD partitie E: met media files (mp3, divx etc.) kopieeren naar een subdirectory op N: via drag and drop. Dat gaat al snel fout. Nu stort de server niet geheel af, maar de netwerkverbinding is compleet foetsie. De server kan niet meer pingen naar de workstation of de router. De workstation kan ook niet meer pingen naar de server. De workstation en de router zien elkaar wel nog. Om de zaak weer aan de praat te krijgen: init 6 op de server.

Test 2: gebruik een DOS-box

E:\>net use N: \\gemini\NetworkDisk
E:\>xcopy *.* N:\backup\drive_e /S

Dit loopt nu al enige tijd zonder problemen, heel wat kleine en grote files zijn al gekopieerd. Wat me opvalt is dat de HDD led op de server bij deze test veel regelmatiger aan/uit gaat dan bij test 1.

Wat is er anders bij het kopieeren via een DOS box

edit:

Knudde, hij is er net ook uitgevlogen met:

The specified network resource or device is no longer available

Het heeft wel veel langer geduurd. Het was nog niet eens zo een grote file.

Ook nu leeft de server nog, maar is de netwerkverbinding is weer compleet down.

[ Voor 13% gewijzigd door EXX op 31-03-2003 21:39 ]

[Jaap-Jan]

Heb je ook de optie '-u 1' al eens gebruikt in hdparm? Dit zorgt ervoor dat de unmaskirq flag aangezet wordt. Tijdens schrijfbewerkingen kan de harde schijf het IRQ zolang voor zich opeisen dat de andere IRQ's geen kans meer krijgen, dit lost dat probleem op.

[EXX]

Volgens mij heeft het nix te maken met de HDD I/O, maar met de LAN topology.

Alle systemen op de LAN lopen op DHCP. De workstation (taurus) krijgt normaal 10.0.0.150 en de server (gemini) 10.0.0.151.

Nu zie ik in de /etc/hosts file staan:

10.0.0.152 gemini.zodiac.net gemini

Levert dit geen conflict op?

Ik zal die regel eens wegdoen dmv van een #.

edit:

Het zag er een hele tijd uit dat het goed ging, maar helaas...
Nog even wat extra info: ping 127.0.0.1 op de server werkt wel, ping 10.0.0.151 (zichzelf) ook, maar pingen naar iets anders niet meer.

[ Voor 24% gewijzigd door EXX op 31-03-2003 22:35 ]

[EXX]

Nog even: ik heb eens rond gekeken in /var/log/messages en daar duikt hetvolgende nogal eens op:

gemini kernel: eth0: Too much work at interrupt, IntrStatus=0x0040.

en ook:

gemini kernel: eth0: Too much work at interrupt, IntrStatus=0x0010.

met af en toe ertussen door:

gemini last message repeated x times, met x is o.a. 2, 5 , 8

Kan de LAN het werk niet aan of duwt de workstation de server teveel data door de strot?

Info: installatie log vd LAN interface:

gemini kernel: 8139too Fast Ethernet Driver 0.9.16
gemini kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xc30fd00
gemini kernel: eth0: Identified 8139 chip type 'RTL-8139C'
gemini kernel: eth0: Setting 100mbps full duplex based on auto-negotiation partner ability 45e1.

[ Voor 10% gewijzigd door EXX op 31-03-2003 22:51 ]

[EXX]

Even een update:

Het probleem zit em idd in de LAN communicatie. Eerst naar de MTU waarde gekeken. Die staat overal op 1500. Dan nog een test gedraaid (even een CD image kopieeren) en herhaaldelijk ifconfig opgeroepen. Daaruit blijkt dat 1 op de 10 packets fout is. Als je kijkt naar het aantal RX packets heb je 10% errors, allemaal veroorzaakt door overruns. Er zijn ook een fors aantal dropped frames. Blijkbaar kan de CPU het niet allemaal bijhouden. Vreemd vind ik dat wel voor een P75, ik had toch gedacht dat die snel genoeg zou zijn.

De situatie is sterk verbeterd nadat ik in de smb.conf volgende regel:

socket options = TCP_NODELAY

heb veranderd in

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192

Het aantal overruns is drastisch teruggelopen. De CD image van 700 MB kon worden gekopieerd naar de server. Na het kopieeren had ik nog 115 overruns en 5 dropped frames. Ook zag je de HDD LED op de server minder actief worden. Blijkbaar is zo dus minder HDD I/O en dus meer CPU tijd voor de LAN afhandeling. De CPU idle time neemt nl. niet af.

Wat ik nog wil proberen is het vergroten van de SO_RCVBUF waarde. Kijken of dan nog minder errors krijg (of zelfs naar nul). Kun je die buffers eigenlijk naar believen opschroeven of geeft dat weer andere problemen?

[LollieStick]

Een overrun kan komen doordat de preocessor overbelast raakt. Heb je nergens een 3Com kaartje liggen? Die Realteks zijn verder perfect, maar vreten nogal van je CPU. Probeer eens een 3Com, Intel of een SMC. Dat moet vrijwel zeker goed zitten.

[EXX]

Zal eens kijken of ik zo een kaartje kan bemachtigen; zelf heb ik er geen. Overigens een test met de buffers van 16384 bytes geeft nog een kleine verbetering. Het werkt igg wel nu.

[EXX]

De hand weten te leggen op een intel pro/100S kaartje en daarmee eens getest. Warempel, geen enkele overrun error of dropped frame meer.

Een andere vraagje: hoe snel gaat het overpompen van data zoals in mijn geval (van workstation naar server) normaliter. Nu doet ie ongeveer 15 tot 20 minuten over een CD image van 700 MB. Met 100Mbps LAN had ik eigenlijk een hogere throughput verwacht.

[LollieStick]

hmm... 15 tot 20 minuten is wel erg lang

Misschien kan je met mii-tool kijken waar je verbinding op staat. Het kan zijn dat ie op 10 mbps draait en dan is het logisch dat de snelheid zo laag is.

[EXX]

Ik zal vanavond eens kjjken, maar na de installatie van de intel NIC heb ik gisteren in var/log/messages gekeken en ik dacht me te herinneren dat daar 100Mbit FD vermeld stond. Ik kan ook op de switch (Unex SD050s) de LED functie even omzetten: als het dan groen blijft is het 100 Mbps.

Misschien moet ik niet meer tegelijkertijd van newszilla zitten te downloaden terwiijl ik data naar de server aan het pompen ben (je zou toch denken dat dat met een switch elkaar niet in de weg zit)

edit:

Zou het ook met te maken kunnen hebben met ReiserFS? Ik heb gelezen dat dat nogal traag kan worden met grote bestanden; de combinatie met zo een antieke P75 is dat natuurlijk ook niet bevorderlijk. Ik zal vanavond eens een test doen door ook eens een samba share te maken op de andere HDD; die is ext2.

[ Voor 25% gewijzigd door EXX op 04-04-2003 10:12 ]

[LollieStick]

Het kan ook liggen aan ReiserFS. Dit heeft ook nog de nodige bugs (ext2/3 en XFS ook trouwens). Ik heb weinig ervaring met Reiser, maar zover ik weet kan het inderdaaad traag worden. Als iemand dat kan bevestigen heel graag.

Ext2 wordt nog altijd het beste ondersteund door de kernel. Als je journaling wil, is misschien XFS of Ext3 een oplossing

[EXX]

Ja, ik wil journaling. Ik moet er niet aan denken dat ie op die 120 GB HDD een file system check begint uit te voeren . Op de 6 GB HDD lijkt het al een eewigheid te duren (in de orde van 5 tot 10 minuten).

Hehe, ik kan altijd nog proberen die P75 wat sneller te laten lopen; 90 MHz moet ie toch kunnen.

[EXX]

Not! Eerst even de FSB omhooggezet naar 60 MHz: niet eens BIOS in beeld. Terug naar 50 MHz, en de multiplier op x2. Weer zwart beeld, niet booten. Dan wordt nix met overclocken

Even nog een test gedaan: eenzelfde file van pakweg 21 MB gekopieerd:

- disk 1 (ext2): duur = 25 sec, transfer 800 - 900 KB/s
- disk 2 (ReiserFS): duur = 30 sec, transfer 700 - 800 KB/s

Er zit dus een wat verschil in, maar erg groot is het niet.

[ Voor 80% gewijzigd door EXX op 04-04-2003 19:30 ]

[EXX]

Is het trouwens normaal dat bij een copy van de workstation naar de server de CPU op de workstation 100% belast wordt? Lijkt me erg vreemd! De workstation heeft een PIII-800 CPU en wordt 100% belast, terwijl de server met een P75 maar voor 30% belast wordt?

[LollieStick]

welke netwerkkaart?

[EXX]

Je raad het al, in de workstation zit een Sitecom LN-001 kaart en dat is dus Realtek RTL8139 chipset. Maar met een 800 MHz CPU moet toch wel volstaan. Overigens merk je weining van die "100% CPU load" het systeem wordt niet traag ofzo.

[LollieStick]

hmm.... welk proces vreet die 100%? 100% op een 800 Mhz mag niet voorkomen. Heb je al geprobeerd de drivers te updaten? Windows Update gedraaid?

Het lijkt me niet nodig om die Realtek in je workstation ook te vervangen.

Het overpompen kan lang duren omdat dat systeem niet echt snel is. Door de lees-/schrijfsnelheden die je hierboven specificeerd kan je heel makkelijk uitrekenen hoe lang het gaat duren.

[ Voor 90% gewijzigd door LollieStick op 06-04-2003 21:50 . Reden: typo in link ]

[EXX]

Thnx, driver update kan ik eens proberen. Over de vraag welk process hier 100% zit te vreten, ik kom er niet achter. Win98 heeft nu eenmaal niet zo een fraaie NT achtige task manager. Suggesties voor een progje om daar achter te komen zijn welkom.

Tijdens downen van i-net (gaat ook via ethernet) is de CPU usage maar een paar procent.

De drivers die Win98 nu gebruikt worden aangegeven als zijnde Microsoft drivers.

Heb gelijk even een network/LAN bandwith benchmark gedaan op de workstation richting server met Sandra 2002: Daarbij kwam ik op een bandwith van 4414 KB/s en een latency van 1 ms.

[ Voor 46% gewijzigd door EXX op 06-04-2003 22:22 ]

[EXX]

De situatie heeft zich behoorlijk verbeterd. Voor de server een ander mobo op de kop kunnen tikken met 96 MB RAM en en Pentium 200 CPU. Resultaat: een file van 72 MB wordt nou in 1 minuut overgepompt en de Sandra 2000 network bandwith test geeft nu een bandbreedte van 6738 KB/s.

edit:

He, unzippen van een file naar de network-drive gaat een stuk rapper! Ongeveer 2.2 MB/s.

[ Voor 17% gewijzigd door EXX op 08-04-2003 21:02 ]

[EXX]

Even een oud topic omhoog schoppen met nieuwe info ter volledigheid:

Na het overschakelen op Windows XP loopt het eea een factor 3 rapper. De task manager geeft bij het kopieeren een network utilization van pakweg 30%, dus zo rond de 30 Mbps = +- 3 MB/s. Voorheen (onder Win98) was dat rond de 1 MB/s. De Win98 network driver was blijkbaar een beetje brak.