Interstellar Posted August 17, 2011 Share Posted August 17, 2011 Having issues stopping array.. Has done it twice in a row since installing latest beta. emhttp reporting bug, /mnt/user is showing as busy and won't unmount. Have to force shut down... Anyone else having issues with this? Upgraded to -beta11 on a small test server last night and had this happen twice. At first I was convinced that I had left a telnet session open somewhere, but I'm fairly certain that was not the case. Had to force shutdown both times. Having this issue on b10 now i've downgraded too. Quote Link to comment
peter_sm Posted August 17, 2011 Share Posted August 17, 2011 Hi Issue with Slimserver----- Installing Squeezebox to /usr/local/slimserver looks OK I got following line Squeezebox Server is running and I can continue to config the server. Changing to /mnt/cache/slimserver... it dont show the line Squeezebox Server is running when enabled it. ( i have rebooted severl times with this settings) And When slimserver is running in the memory (/usr/local/slimserver) I can't start SABnzb, disable slimserver then I can start SABnzb Anyone know why, cant see anything in my syslog, but attached the last line anyway... Aug 17 20:08:14 Tower su[11275]: Successful su for nobody by root Aug 17 20:08:14 Tower su[11275]: + root:nobody Aug 17 20:08:14 Tower su[11276]: Successful su for nobody by root Aug 17 20:08:14 Tower su[11276]: + root:nobody Aug 17 20:08:15 Tower su[11319]: Successful su for nobody by root Aug 17 20:08:15 Tower su[11319]: + root:nobody Aug 17 20:08:15 Tower su[11320]: Successful su for nobody by root Aug 17 20:08:15 Tower su[11320]: + root:nobody Aug 17 20:08:15 Tower su[11322]: Successful su for nobody by root Aug 17 20:08:15 Tower su[11322]: + root:nobody Aug 17 20:08:25 Tower su[11563]: Successful su for nobody by root Aug 17 20:08:25 Tower su[11563]: + root:nobody Aug 17 20:09:04 Tower su[12120]: Successful su for nobody by root Aug 17 20:09:04 Tower su[12120]: + root:nobody Aug 17 20:09:07 Tower su[12225]: Successful su for nobody by root Aug 17 20:09:07 Tower su[12225]: + root:nobody Aug 17 20:11:58 Tower su[14335]: Successful su for nobody by root Aug 17 20:11:58 Tower su[14335]: + root:nobody Aug 17 20:12:10 Tower sudo: root : TTY=console ; PWD=/ ; USER=slimserver ; COMMAND=/usr/local/slimserver/slimserver.pl --daemon --pidfile /var/run/slimserver/slimserver.pid Aug 17 20:12:17 Tower su[14854]: Successful su for nobody by root Aug 17 20:12:17 Tower su[14854]: + root:nobody Best Regards Peter Quote Link to comment
Yorgo Posted August 17, 2011 Share Posted August 17, 2011 From Beta10: - linux: use Realtek r8168 driver instead of linux r8169 driver From Beta11: - linux: restore linux r8169 driver I'm guessing the Realtek 8111E is still causing problems? Too bad if that's the case, since the majority of cheap socket 1155 motherboards use that NIC. Just noticed that, so yes that is what is causing the issue. A number of the AMD m-ATX boards also use that... Any reason for putting it back in the first place!? http://lime-technology.com/forum/index.php?topic=14158.msg134868#msg134868 Having the same problems with b11 as with b10. Gone back to b9 (which has been very solid on my production machine). I hope that this gets resolved before we go to a RC. Y Quote Link to comment
Johnm Posted August 18, 2011 Share Posted August 18, 2011 Upgraded to B11 a few hours after release So far nothing to report that is not "normal". I am not using a cache drive atm. The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). Quote Link to comment
dandirk Posted August 18, 2011 Share Posted August 18, 2011 Wow thanks Tom. I upgraded from 4.5 to 4.7 to 5 beta 11... No problems what so ever with the upgrade. SlimServer a HUGE plus too... wife will be very happy. I ran into just a slight problem with the setup. Installed SS as per your post, everything went fine. When I go to set it up, it asks for a playlist directory. So I created a new folder on my user share, within SS went to /mnt/Share/Storage and the folder is not listed. I tried to stop/start SS, no go. I stopped the array, rebooted. No go the folder still does not appear... Not a big deal, just selected an existing dir. Here is the syslog from the gui.. Aug 17 22:51:43 Tower emhttp: Start array... Aug 17 22:51:43 Tower kernel: mdcmd (41): start STOPPED Aug 17 22:51:43 Tower kernel: unraid: allocating 43960K for 1280 stripes (8 disks) Aug 17 22:51:43 Tower kernel: md1: running, size: 1465138552 blocks Aug 17 22:51:43 Tower kernel: md2: running, size: 732574552 blocks Aug 17 22:51:43 Tower kernel: md3: running, size: 732574552 blocks Aug 17 22:51:43 Tower kernel: md4: running, size: 1465138552 blocks Aug 17 22:51:43 Tower kernel: md5: running, size: 732574552 blocks Aug 17 22:51:43 Tower kernel: md6: running, size: 1465138552 blocks Aug 17 22:51:43 Tower kernel: md7: running, size: 732574552 blocks Aug 17 22:51:44 Tower emhttp: shcmd (23): udevadm settle Aug 17 22:51:44 Tower emhttp: shcmd (24): /usr/local/sbin/emhttp_event array_started Aug 17 22:51:44 Tower emhttp_event: array_started Aug 17 22:51:44 Tower emhttp: Mounting disks... Aug 17 22:51:44 Tower emhttp: shcmd (25): mkdir /mnt/disk7 Aug 17 22:51:44 Tower emhttp: shcmd (26): mkdir /mnt/disk5 Aug 17 22:51:44 Tower emhttp: shcmd (28): mkdir /mnt/disk4 Aug 17 22:51:44 Tower emhttp: shcmd (27): mkdir /mnt/disk3 Aug 17 22:51:44 Tower emhttp: shcmd (29): mkdir /mnt/disk2 Aug 17 22:51:44 Tower emhttp: shcmd (30): mkdir /mnt/disk1 Aug 17 22:51:44 Tower kernel: mdcmd (42): check CORRECT Aug 17 22:51:44 Tower kernel: md: recovery thread woken up ... Aug 17 22:51:44 Tower emhttp: shcmd (31): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md7 /mnt/disk7 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (32): mkdir /mnt/disk6 Aug 17 22:51:44 Tower emhttp: shcmd (33): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md5 /mnt/disk5 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (34): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (35): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (36): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (37): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md4 /mnt/disk4 |& logger Aug 17 22:51:44 Tower emhttp: shcmd (38): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md6 /mnt/disk6 |& logger Aug 17 22:51:44 Tower kernel: md: recovery thread has nothing to resync Aug 17 22:51:44 Tower kernel: REISERFS (device md7): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md7): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md3): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md2): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md1): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md4): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md4): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md5): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md5): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md6): found reiserfs format "3.6" with standard journal Aug 17 22:51:44 Tower kernel: REISERFS (device md6): using ordered data mode Aug 17 22:51:44 Tower kernel: REISERFS (device md7): journal params: device md7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower kernel: REISERFS (device md7): checking transaction log (md7) Aug 17 22:51:44 Tower kernel: REISERFS (device md3): checking transaction log (md3) Aug 17 22:51:44 Tower kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower kernel: REISERFS (device md2): checking transaction log (md2) Aug 17 22:51:44 Tower kernel: REISERFS (device md1): checking transaction log (md1) Aug 17 22:51:44 Tower kernel: REISERFS (device md4): journal params: device md4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower 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 Aug 17 22:51:44 Tower kernel: REISERFS (device md4): checking transaction log (md4) Aug 17 22:51:44 Tower kernel: REISERFS (device md5): checking transaction log (md5) Aug 17 22:51:44 Tower kernel: REISERFS (device md6): journal params: device md6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Aug 17 22:51:44 Tower kernel: REISERFS (device md6): checking transaction log (md6) Aug 17 22:51:44 Tower kernel: REISERFS (device md7): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md5): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md4): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md6): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md2): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md1): Using r5 hash to sort names Aug 17 22:51:44 Tower kernel: REISERFS (device md3): Using r5 hash to sort names Aug 17 22:51:44 Tower emhttp: shcmd (39): chmod 770 '/mnt/disk6' Aug 17 22:51:44 Tower emhttp: shcmd (40): chmod 770 '/mnt/disk7' Aug 17 22:51:44 Tower emhttp: shcmd (41): chown nobody:users '/mnt/disk6' Aug 17 22:51:44 Tower emhttp: shcmd (42): chown nobody:users '/mnt/disk7' Aug 17 22:51:44 Tower emhttp: shcmd (43): chmod 770 '/mnt/disk5' Aug 17 22:51:44 Tower emhttp: shcmd (44): chown nobody:users '/mnt/disk5' Aug 17 22:51:44 Tower emhttp: shcmd (45): chmod 770 '/mnt/disk4' Aug 17 22:51:44 Tower emhttp: shcmd (46): chown nobody:users '/mnt/disk4' Aug 17 22:51:44 Tower emhttp: shcmd (47): chmod 770 '/mnt/disk2' Aug 17 22:51:44 Tower emhttp: shcmd (48): chown nobody:users '/mnt/disk2' Aug 17 22:51:44 Tower emhttp: shcmd (49): chmod 770 '/mnt/disk3' Aug 17 22:51:44 Tower emhttp: shcmd (50): chown nobody:users '/mnt/disk3' Aug 17 22:51:44 Tower emhttp: shcmd (51): chmod 770 '/mnt/disk1' Aug 17 22:51:44 Tower emhttp: shcmd (52): chown nobody:users '/mnt/disk1' Aug 17 22:51:44 Tower emhttp: shcmd (53): mkdir /mnt/user Aug 17 22:51:44 Tower emhttp: shcmd (54): /usr/local/sbin/shfs /mnt/user -disks 254 -o noatime,big_writes,allow_other,default_permissions,use_ino Aug 17 22:51:44 Tower emhttp: shcmd (55): crontab -c /etc/cron.d -d &> /dev/null Aug 17 22:51:44 Tower emhttp: shcmd (56): /usr/local/sbin/emhttp_event disks_mounted Aug 17 22:51:44 Tower emhttp_event: disks_mounted Aug 17 22:51:45 Tower emhttp: shcmd (57): :>/etc/samba/smb-shares.conf Aug 17 22:51:45 Tower emhttp: Restart SMB... Aug 17 22:51:45 Tower emhttp: shcmd (58): killall -HUP smbd Aug 17 22:51:45 Tower emhttp: shcmd (59): ps axc | grep -q rpc.mountd Aug 17 22:51:45 Tower emhttp: _shcmd: shcmd (59): exit status: 1 Aug 17 22:51:45 Tower emhttp: shcmd (60): /usr/local/sbin/emhttp_event svcs_restarted Aug 17 22:51:45 Tower emhttp_event: svcs_restarted Aug 17 22:52:15 Tower sudo: root : TTY=console ; PWD=/ ; USER=slimserver ; COMMAND=/usr/local/slimserver/slimserver.pl --daemon --pidfile /var/run/slimserver/slimserver.pid Quote Link to comment
sunnyville Posted August 18, 2011 Share Posted August 18, 2011 I exchanged a 1TB disk for a 3TB disk yesterday evening & started the rebuild. This morning the servers web control panel no longer is accessible, and whenever I mount anything (which takes minutes rather than seconds), I get: "Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details. Switching to read-only mode". I believe somebody has also had this problem a few posts back. My question is, if it is rebuilding and I hard-reset it (As I conclude that it has become unresponsive), is there a chance of data loss? Quote Link to comment
capler Posted August 18, 2011 Share Posted August 18, 2011 Changelog: - linux: restore linux r8169 driver Thanks Tom - beta11 working very well with my Realtek r8169 NIC (PCI Tenda Gigabit TEL9901G) just like it did prior to beta10. Quote Link to comment
savestheday Posted August 18, 2011 Share Posted August 18, 2011 Uggh my AFP issues persist. I shouldn't really say that since they got much better since setting up my AFP the way Nezil described in the beta 10 thread http://lime-technology.com/forum/index.php?topic=14158.60 but I have done some testing on a new hackintosh I built. The new hack doesn't have my credentials saved for the AFP share so it connects as guest. When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares. It's exactly what it should be like! However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares. I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't? When I connect as 'redfive', I get a bunch of what's listed below in the syslog: Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:06 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:07 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:10 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/HD/.DS_Store Aug 18 09:20:11 EchoBase shfs/user: duplicate object: /mnt/disk9/Movies/HD/.DS_Store Aug 18 09:20:15 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:15 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store Aug 18 09:20:16 EchoBase shfs/user: duplicate object: /mnt/disk6/Movies/.DS_Store Aug 18 09:20:16 EchoBase shfs/user: duplicate object: /mnt/disk11/Movies/.DS_Store I don't see this connecting as guest. It's getting to the point where I may just open up full access to the shares to everyone because it's quicker viewing them that way. If I connect as 'redfive' on my hack, I'm back to waiting. Maybe Nezil knows what's up with this? Btw this is not really a beta 11 issue, same thing happened in beta 10. Just figured since Tom was able to get the final version of Netatalk that some of the issues might be solved. Quote Link to comment
prostuff1 Posted August 18, 2011 Share Posted August 18, 2011 Those .DS_Store files are not the fault of netatalk. It is something the Mac creates to keep track of Finder window position and settings. There is an unMenu package that will delete these from the server via a cron task. You can also do a google search to disable that creation on a network share permanently. Quote Link to comment
dlmh Posted August 18, 2011 Share Posted August 18, 2011 but I have done some testing on a new hackintosh I built. The new hack doesn't have my credentials saved for the AFP share so it connects as guest. When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares. It's exactly what it should be like! However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares. I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't? What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous. I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID. Quote Link to comment
Johnm Posted August 18, 2011 Share Posted August 18, 2011 but I have done some testing on a new hackintosh I built. The new hack doesn't have my credentials saved for the AFP share so it connects as guest. When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares. It's exactly what it should be like! However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares. I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't? What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous. I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID. Have you tried Cache_Dirs on your unraid and see if this still holds true? I'd hate to spin up 20 disks to find one file. Quote Link to comment
dlmh Posted August 18, 2011 Share Posted August 18, 2011 but I have done some testing on a new hackintosh I built. The new hack doesn't have my credentials saved for the AFP share so it connects as guest. When connecting as "Guest", clicking on my unRAID server on the Finder sidebar gives me an instantaneous view of my shares. It's exactly what it should be like! However, when I login with my account ('redfive') on my MacBook Pro, it takes at least a minute to list those same shares. I can only assume it's because it's checking file permissions against my account and when I connect as guest it doesn't? What happens when you select the share in the Finder sidebar is that all the hard disks will spin up (maybe to check permissions, dunno..). As long as the drives are all spun up, access to the share will be instantaneous. I'm not sure if Tom will be able to fix this, as the Netatalk daemon performs this check, not unRAID. Have you tried Cache_Dirs on your unraid and see if this still holds true? I'd hate to spin up 20 disks to find one file. Yep, cache_dirs is running and works perfectly for Samba shares. Quote Link to comment
Chris Pollard Posted August 18, 2011 Share Posted August 18, 2011 The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). This is also the case in windows. Quote Link to comment
Johnm Posted August 18, 2011 Share Posted August 18, 2011 The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). This is also the case in windows. Thanks. I never looked at that. Time to try another vendor then. Quote Link to comment
Interstellar Posted August 18, 2011 Share Posted August 18, 2011 I exchanged a 1TB disk for a 3TB disk yesterday evening & started the rebuild. This morning the servers web control panel no longer is accessible, and whenever I mount anything (which takes minutes rather than seconds), I get: "Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details. Switching to read-only mode". I believe somebody has also had this problem a few posts back. My question is, if it is rebuilding and I hard-reset it (As I conclude that it has become unresponsive), is there a chance of data loss? No. I just telnet in and manually delete the three .Apple files, then the problem is fixed! Quote Link to comment
speeding_ant Posted August 18, 2011 Share Posted August 18, 2011 The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). This is also the case in windows. Thanks. I never looked at that. Time to try another vendor then. Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive? Quote Link to comment
Johnm Posted August 18, 2011 Share Posted August 18, 2011 The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). This is also the case in windows. Thanks. I never looked at that. Time to try another vendor then. Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive? Other then the vendor ID, I don't believe so. My Mushkin SSD's work fine. I just wanted to use the Cheaper/Faster OCZ Solid3. Quote Link to comment
dgaschk Posted August 18, 2011 Share Posted August 18, 2011 The only bug i am still seeing is that OCZ Sata3 SSD's report their temps at 128 Deg. This panics the overheat scripts (if running) and puts your server in emergency shutdown. I have tried 3 different models (Agility, Vertex and Solid3). This is also the case in windows. Thanks. I never looked at that. Time to try another vendor then. Do the SSD's produce any unique identifiers that sets them aside from a standard hard drive? Other then the vendor ID, I don't believe so. My Mushkin SSD's work fine. I just wanted to use the Cheaper/Faster OCZ Solid3. The faster SSD won't help. The network is the bottleneck. Quote Link to comment
hurricanehrndz Posted August 18, 2011 Share Posted August 18, 2011 b11 seems to work fine with me, I am using pretty standard hardware such the SLAPS MV8 cards, and so far everything seems fine. All my disk spindown. On another note I wrote SABnzbd-0.6.8 plg, if anyone want to overlook it that would be greatly appreciated. First script ever written, I am use to vb .net so google came in very handy. Anyhow plg script is here: http://pastebin.com/zvPTb8QE I tested and it seems to work for the most part. I say for the most part, because you never know. I use the slimserver as the base. Quote Link to comment
speeding_ant Posted August 18, 2011 Share Posted August 18, 2011 Getting the kernel oops on array stop with my other unRAID server too. It appears to safely unmount all of the drives, but the user mount is what stops it. Quote Link to comment
Johnm Posted August 18, 2011 Share Posted August 18, 2011 I have stopped and started my array several times without an issue over the last few days. I just hit the "stop array" button in unmenu and it froze up the sever and killed the web connections to both default unraid web gui and unmenu. i had to hard reset with power switch I never use that button so for all i know it is bugged in 5x. Quote Link to comment
defected07 Posted August 18, 2011 Share Posted August 18, 2011 Savestheday: same lag with displaying shares in Finder via AFP occurs for me too. I haven't tried with a guest account, but when I connect to the server via Samba, they load up instantly. I will try spinning up the drives and see if they load instantly through AFP. Also, I'll try to "ls" on the mounted volumes through Terminal to see if it's strictly a Finder issue. Because even when the shares are mounted and displayed on my desktop, clicking under Shared on the left menu in Finder will act like it's connecting for the first time -- could just be a symptom of the comatose drives. Quote Link to comment
Nezil Posted August 19, 2011 Share Posted August 19, 2011 Savestheday: I'll go through my setup again in another post, when I've got a little more time. I think I have a good understanding of how Netatalk is working, and where the performance issues exist and could be improved, as well as what the pros and cons are of doing this. In short, the way it's set up by Tom in the latest betas (including beta11) is good, and I can't see any issues with his choice of settings. Personally, I have made several changes from Tom's options, which I believe improve browsing performance a little. Quote Link to comment
sunnyville Posted August 19, 2011 Share Posted August 19, 2011 Please if someone could help, this is my second try at rebuilding parity & expanding the array after replacing a 1TB drive with a 3 TB. It starts up, says it will take 700 minutes to complete, after two hours the web panel is still accessible, I leave it overnight, and in the morning the machine is non responsive. IF I reset it the whole rebuilding starts over. Quote Link to comment
Falcon Posted August 19, 2011 Share Posted August 19, 2011 Getting the kernel oops on array stop with my other unRAID server too. It appears to safely unmount all of the drives, but the user mount is what stops it. I got the same problem and had to use button to shut down the server. I have no syslog files Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.