strange problems: AFP slow, then shares list shows up empty

Having some problems with my tower lately.

Currently running 5.0-rc15a, 12 before that, and 5 before that IIRC.

Set everything up using AFP only, since I have an all Mac network.

Everything ran fine for about 6 months, and now, over the last few months, things have slowly been going downhill.

First, connecting to a share, getting a directory reading from a share became incredibly slow – about 1 minute to get a directory listing of any size folder. I chalked this up to having added lots of data to the server, lots of files in the share, etc.

Then, my TimeMachine backups started getting corrupted on my MacBook Air, system asking me to start a new backup. It would do this every few months. I chalked this up to it being a portable, and often disconnecting from the network during a backup, etc.

Then a week or so ago, shares started suddenly disconnecting. Finder gave a "The share does not exist on the server. Please check the share name, and then try again" message.

Connected to the admin panel, and the list of shares was empty.

Rebooted the server, shares where there as expected.

It's been doing this for the last couple of days.

Ran a parity check, everything was OK.

I upgraded the system to rc15a, but that hasn't helped.

so:

- the AFP weirdness may or may not be related to the user share problems

- but I'm concerned about the user share problems.

Sorry for this long, rambling, imprecise question, just wondering if anyone might have an idea what's going on. I mention the AFP stuff only for completeness.

I'm activating SMB for testing, will report back if that changes anything.

thanks.

SMB isn't working well either.

I turned it on for one of my user shares – it appeared, and I was able to connect to the share, but it conked out after a minute and now I can' even connect to it any more, Finder says it can't be found.

Attach a syslog.

Attached is a .zip of a few of the most recent syslogs. thanks!

syslog-20130627-to-30.zip

Attached is perhaps a better log file, which I just grabbed from the server as per the troubleshooting guide, and which covers a time in which the server dropped an AFP connection.

there's a lot of "Transport endpoint is not connected" in there. 

syslog-2013-06-30.txt

Send a message to Tom (Lime-tech) with a link to this thread.

I tried running reiserfsck, but the telnet session was cut off:

~# reiserfsck --check /dev/md1

...

reiserfsck --check started at Mon Jul  1 16:09:41 2013
###########
Replaying journal: Done.
Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed
Checking internal tree.. \/  5 (of  29// 57 (of  91|/ 19 Connection closed by foreign host.

and the last few lines of my syslog read thus:

Jul  1 16:08:39 zetta login[3510]: ROOT LOGIN  on '/dev/pts/0' from '10.0.1.21'
Jul  1 16:11:20 zetta unmenu[1296]: df: `/mnt/user': Transport endpoint is not connected
Jul  1 16:11:21 zetta last message repeated 7 times
Jul  1 16:20:53 zetta kernel: mdcmd (41): spindown 2
Jul  1 16:20:53 zetta kernel: mdcmd (42): spindown 3
Jul  1 16:20:54 zetta kernel: mdcmd (43): spindown 4
Jul  1 16:20:54 zetta kernel: mdcmd (44): spindown 23
Jul  1 16:24:45 zetta kernel: mdcmd (45): spindown 0
Jul  1 16:39:06 zetta kernel: mdcmd (46): spindown 1

Attach a keyboard and screen.

I've now run reiserfsck directly on the machine.

All of the disks seem to be fine.

The summary screen at the end of the check is always more or less the same (transcribed by hand here)

resierfsck --check
No corruptions found.
There are on filesystem:
Leaves 72471
Internal nodes 4603
Directories 131146
Other files 1720429
Data block pointers 414009836 (2842 of the are zero)
Safe links 0

anything else that I could look at which might explain strange behavior?

The current release is rc16c.