adriencater

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?

i was running it on a telnet session on the tower... everything keeps pooping out with a "Transport endpoint is not connected" error. also working on that issue over here: http://lime-technology.com/forum/index.php?topic=28282.0 I'll reboot, run it again, and keep an eye open for any user.org.netatalk.supports-eas.xxxxx : Exec format errror thanks for the help!

I ran this command, and it generated ~7k lines of output (about 2400 individual items) before the server sneezed a bunch of lines ending in "Transport endpoint is not connected" and the whole thing stopped These are the types of extended attributes that were found: user.com.apple.diskimages.fsck user.com.apple.diskimages.recentcksum user.com.apple.metadata:kMDItemFinderComment user.com.apple.metadata:kMDItemWhereFroms user.com.apple.metadata:kMDLabel_… user.com.apple.Preview.UIstate.v1 user.com.apple.quarantine user.com.apple.TextEncoding user.com.apple.xcode.PlistType user.com.macromates.caret user.org.netatalk.supports-eas.G7qPCu

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

This seems very logical. I'll give that a go, and see how things work out. Don't forget to check for corrupted extended attributes with the command above. Also, where is your netatalk db being stored? (there are different sh&tty parts to all this and each has its own effect) I'll look into these issues as well. I haven't been getting any "CNID DB" error messages, but this gives me a good hook to search for further information here and elsewhere – thanks!

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

From the admin panel: Device Identification Temp. Size Free Reads Writes Errors parity WDC_WD30EZRX-00MMMB0_WD-WCAWZ2453611 (sde) 2930266532 39°C 3 TB - 350938 375361 0 disk1 WDC_WD30EZRX-00MMMB0_WD-WCAWZ2456458 (sdd) 2930266532 33°C 3 TB 137.15 GB 15947 111 0 disk2 WDC_WD30EZRX-00MMMB0_WD-WCAWZ2456364 (sdb) 2930266532 33°C 3 TB 1.3 TB 174 96 0 disk3 ST3000DM001-9YN166_Z1F15JTV (sdc) 2930266532 33°C 3 TB 143.65 GB 116 67 0 disk4 WDC_WD30EZRX-00DC0B0_WD-WMC1T0037466 (sdf) 2930266532 35°C 3 TB 2.3 TB 76 73 0 disk23 WDC_WD10EADS-00L5B1_WD-WCAU45627201 (sdg) 976762552 36°C 1 TB 308.28 GB 1655457 453326 0 flash Reader_SD_MS - 3.97 GB 3.87 GB 330 11 0 and from "df -aTh": Filesystem Type Size Used Avail Use% Mounted on proc proc 0 0 0 - /proc sysfs sysfs 0 0 0 - /sys tmpfs tmpfs 128M 188K 128M 1% /var/log /dev/sda1 vfat 3.7G 79M 3.7G 3% /boot /dev/md1 reiserfs 2.8T 2.7T 128G 96% /mnt/disk1 /dev/md2 reiserfs 2.8T 1.6T 1.2T 57% /mnt/disk2 /dev/md3 reiserfs 2.8T 2.6T 134G 96% /mnt/disk3 /dev/md4 reiserfs 2.8T 650G 2.1T 24% /mnt/disk4 /dev/md23 reiserfs 932G 645G 287G 70% /mnt/disk23 shfs fuse.shfs 12T 8.1T 3.9T 68% /mnt/user and, yes, apologies, those are four 3TB drives –– not GB, it's not 1999 anymore! -- plus one 1TB drive which is devoted to timemachine. thanks

Attached is a .zip of a few of the most recent syslogs. thanks! syslog-20130627-to-30.zip

I've been having this as well. Directory read can also take a while, and my TimeMachine backups often get corrupted. rc15a (but was acting up on previous install of rc12). running 4 drives, 3GBs each, and a 1GB drive for TM, one parity, no cache.

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.

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.

I’d like to build a primary external storage drive based on a 3-disks-in-rotation principle, with 2 disks in a drive and a 3rd disk off-site. The two disks in the drive would act like a RAID-1 drive. A third disk would be an off-site backup. I would rotate the disks between the drive and the off-site. i.e.: In the morning, I would remove one of the disks from the drive, take it to work, take the third disk that was at work back home, put it in the drive, the ‘new’ third disk would be brought up to date with the disk already in the drive; repeat on a weekly basis My thinking is that this would offer the advantages of RAID-1 insurance against random disk failure, while having an off-site backup which is only a few days old in case my house burns down (unlikely) or I do something stupid like erase an important directory (more likely than I’d like to think). The system would have to be robust enough to not panic when a disk is randomly removed (even if I continue to work on the drive with only one disk in it), and smart enough to quickly copy/sync the newer data when a disk is inserted. Any ideas? (PS: first post, hello. A friend has a Lime box, and suggested I post this idea here...)