October 23, 201114 yr In 5.0 beta 12, I have data 5 disks. Disk 1 is full, and disks 2-5 are completely empty. I use split level 0 and "most-free" allocation method. I created "unRAID/Recorded TV" folder on disks 2-5, and then did `mv /mnt/disk1/.unRAID/Videos/Recorded\ TV /mnt/user/unRAID/Recorded\ TV`. When I do `ls -la /mnt/disk?/unRAID/Recorded\ TV` (or `du`), I see files in Recorded TV spread fairly evenly across disks 2-4, but NOTHING is being written to disk 5. root@unraid:/mnt# du -h disk?/unRAID/Recorded\ TV 13G disk2/unRAID/Recorded TV 12G disk3/unRAID/Recorded TV 16G disk4/unRAID/Recorded TV 0 disk5/unRAID/Recorded TV No disks are "included" or "excluded" on the "unRAID" share settings or on the global share settings. Why is disk 5 being excluded from the user share? Syslog attached. Thanks. syslog.txt.zip
October 24, 201114 yr I'm not an expert, but I'll try to take a stab at this. Disk 5 is showing some problems in the syslog: Oct 24 07:36:44 unraid kernel: REISERFS warning (device md5): sh-2021 reiserfs_fill_super: can not find reiserfs on md5 Oct 24 07:36:44 unraid logger: mount: wrong fs type, bad option, bad superblock on /dev/md5, Oct 24 07:36:44 unraid logger: missing codepage or helper program, or other error Oct 24 07:36:44 unraid logger: In some cases useful info is found in syslog - try Oct 24 07:36:44 unraid logger: dmesg | tail or so Oct 24 07:36:44 unraid logger: Oct 24 07:36:44 unraid emhttp: _shcmd: shcmd (135): exit status: 32 Oct 24 07:36:44 unraid emhttp: disk5 mount error: 32 Is this drive added to the array and showing a good status? My initial guess is that you may have corruption on that disk and that's what's causing this mounting issue. If it is corruption, I'd suggest checking your power availability, your connections and possibly try a different SATA port to try & root out the initial cause. (There may be no hardware cause...it could be something like an improper shutdown, too.) Even if you fix the issue and something is creating corruption on your disk, any fix will be short lived. Can you attach the SMART report, and if possible, the initial preclear report from that disk? You might try to run reiserfsck on that disk as well because it might be able to clear it up.
October 24, 201114 yr Author It's a brand new disk that had just completed preclear. Everything looked normal (to me). After the preclear finished, I stopped the array, added the disk, started the array, and formatted the disk. I could make directories on it and copy files to the disk5 share, but the allocation method would never choose disk5. Since posting here, I stopped the array, rebooted unRAID, started the array, and tried again. It worked that time. Still a bit troubling, though. Attached the preclear reports. preclear_finish__WD-WCAZAC701466_2011-10-23.txt preclear_rpt__WD-WCAZAC701466_2011-10-23.txt preclear_start__WD-WCAZAC701466_2011-10-23.txt
October 24, 201114 yr Yeah, I can't say for sure. Interestingly, I shot nearly identical trouble the other night: http://lime-technology.com/forum/index.php?topic=15867.msg147494#msg147494 Same error, both shortly after adding a disk, similar mysterious resolution. In his case, his drive did mount later...which I didn't see in your logs. Both of you are running late betas, you 5b12, him 5b10. I'm not normally one to scream "bug" but I'd be negligent to point out that you are running betas, which means things aren't *fully* baked yet. I think this warrants one of the heavyweights around here to look at it. Maybe they'll see this and comment?
October 24, 201114 yr Author Doesn't this look like it did eventually mount? Oct 24 07:40:20 unraid emhttp: shcmd (161): mkdir /mnt/disk5 Oct 24 07:40:20 unraid emhttp: shcmd (162): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md5 /mnt/disk5 |& logger Oct 24 07:40:20 unraid kernel: REISERFS (device md5): found reiserfs format "3.6" with standard journal Oct 24 07:40:20 unraid kernel: REISERFS (device md5): using ordered data mode Oct 24 07:40:20 unraid kernel: REISERFS (device md5): journal params: device md5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Oct 24 07:40:20 unraid kernel: REISERFS (device md5): checking transaction log (md5) Oct 24 07:40:21 unraid kernel: REISERFS (device md5): Using r5 hash to sort names Oct 24 07:40:21 unraid kernel: REISERFS (device md5): Created .reiserfs_priv - reserved for xattr storage. Oct 24 07:40:21 unraid emhttp: resized: /mnt/disk5 Oct 24 07:40:21 unraid emhttp: shcmd (163): chmod 770 '/mnt/disk5' Oct 24 07:40:21 unraid emhttp: shcmd (164): chown nobody:users '/mnt/disk5' Also had a thought, that if it wasn't mounted properly my tests of writing to /mnt/disk5 were probably creating files and folders on my USB stick. Too late to check now, I guess. At the time I thought that it was mounted and accessible via the disk5 mount, but not by the user mount. But the unRAID interface showed disk5 as green, reporting 2TB free, just like all the other disks. No errors.
October 24, 201114 yr Author Just read that other thread, and it does appear to be an identical situation. I only noticed the problem sooner in my case because I was explicitly watching files being written to the user share and expecting them to be balanced across all disks. Strange that in both cases it was disk5, too. The other thread doesn't say if the problem was fixed with a stop/start, or reboot. But he does say that he could copy directly to the disk share from Windows Explorer. Perhaps the disk share was mounted and working in my case, and only the user share was having trouble, as I thought.
Archived
This topic is now archived and is closed to further replies.