Re: clients freezing while copying


Subject: Re: clients freezing while copying
From: Lorenzo Perone (lopez.on.the.lists@yellowspace.net)
Date: Thu Mar 29 2001 - 15:49:03 EST


At 18:08 Uhr +0200 29.03.2001, Mac Conin wrote:
>something strange her...
>
>my try-out of netatalk (version 1.4.99-5 from the Suse 7.1 distr. on an
>intel c667)
>seemed for the moment ok. Now that I'm testing stability with copying
>large amounts
>of files (~7.000 files with a total of approx. 200 MB) strange things
>are coming up.
>the first 500-600 files are going through as expected. After that the
>process comes
>more and more to a halt. It ends up with the clinet freezing (or nearly
>because the
>client is so busy trying to copy). When I'm killing the afpd on the
>server the
>clients' behaviour is normal again. Restarting the afpd and copying
>smallamounts of
>data is ok until I try to copy again larger numers of files
>
>Yes, I'm only using TCP - no ddp.
>
>I don't think its the network itself (the hardware) because the rst of the
>servers are working fine.
>
>Any help would be appreciated (I dont' wanna install another windoze...).
>
>

Hi there...

- Dunno if this can help, but I had a very similar symptom on LinuxPPC with netatalk, and it turned out to be an IDE related problem.:
have a look at the kernel messages - in my case, the kernel was telling

hdc: dma_intr: status=0x58 { DreiveReady SeekComplete DataRequest }
hdc: status timeout: status=0xd0 { Busy }
hdc: drive not ready for command
ide1: reset: success
often preceeded and / or followed by "lost interrupt".

When the ide bus got reset, DMA support was switched off too, thus netatalk became much slower as anything else accessing the disk.

For some times this ide went unnoticed, until the server began to panic and eventually crashed. And after restart, on that filesystem, we had a MESS and had to reformat it. No way of recovering anything.
Actually in my case (Power Macintosh G3 DT/266, Maxtor 40GB on /dev/hdc) I couldn't solve the problem. It seemed to get a lot better with hdparm /dev/hdc -d1 -m16 -k1 (so it kept the setting over resets), but my solution was to remove it from that server and serve that disk over a PC on ide0.

Anyway - for god's sake, hdparm is _the_ troubleshooter 4 most of disk-access related performance issues.... ;-)

- In another case I had on the same server, the server started getting slower after about 800MB transfer, then freezed at about 1 GB (actually fluctuating. at times, 300MB, at times, 1GB.).
Banning the network card of that particular client I was uploading from removed this problem (!!). I understood this when I saw that other clients (B/W G3, G4s, iMacs) were uploading seemlessly and fast.
I strongly reccommend to _ban_ any MacSense Fast Ethernet cards from Your network. The same model used to crash ASIP, too.

Note: At that time the interrupt problem described above had not been identified, so it could have been part of the cause, but this upload was actually occurring on another fs (/dev/hda).

.....regards,

:-)

Lorenzo



This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:36 EDT