Jump to content

Most-free allocation method doesn't work?

Recommended Posts

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.




Link to comment

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.

Link to comment

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.




Link to comment

Yeah, I can't say for sure.  Interestingly, I shot nearly identical trouble the other night:




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?

Link to comment

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.


Link to comment

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.


Link to comment


This topic is now archived and is closed to further replies.

  • Create New...