March 5, 200818 yr Here's what happened... I just installed 4.2.3. It booted just fine. (that is the good news) I then thought I'd document the process of adding a new disk to my array. I have both a 250 gig sitting in the array, and a 750 gig drive in the array, both un-assigned. I wanted to first add the 250 gig drive to slot9. Once it was in the array I was going to use the parity-swap procedure to replace the other 250 gig drive I currently have in slot3 of my array. I never got to try the parity swap procedure since I have not been able to add the 250 gig drive to my array. Here is what I did: I stopped my array, assigned slot9 with the 250 gig drive. (slot9 was previously empty) When I returned to the main page it looked like this: I checked the checkbox to "Start" the array and pressed the "Start" button. The screen looked like this: The screen did NOT refresh itself, but I could press Refresh every once in a while and I could see the progress of the disk clear progress. Here is an image of it when nearly done: A few minutes more, I pressed the refresh button once more and I saw this... It was not what expected. I was back on the screen where I could choose either the "Start" or "Restore" buttons. Once more I pressed the "Start" button (after checking its affiliated checkbox) and the array once more shows that clearing had started on my new drive.... My array is 54% through clearing my new drive for the second time. Somehow, I'm guessing when it is done I'll be asked to "Start" or "Restore" once more. My syslog shows these entries that look very suspicious. Mar 5 08:22:39 Tower kernel: [ 7938.785101] md9: new disk Mar 5 08:22:41 Tower kernel: [ 7940.811764] md9: new disk Mar 5 08:22:42 Tower emhttp[1094]: ... clearing 100% complete Mar 5 08:22:42 Tower emhttp[1094]: ... syncing Mar 5 08:22:44 Tower emhttp[1094]: driver cmd: start EXPANDING Mar 5 08:22:44 Tower kernel: [ 7943.143252] mdcmd (2741): start Mar 5 08:22:44 Tower kernel: [ 7943.143400] md1: missing Mar 5 08:22:44 Tower kernel: [ 7943.144078] md6: missing Mar 5 08:22:44 Tower kernel: [ 7943.144346] md8: missing Mar 5 08:22:44 Tower kernel: [ 7943.144474] md9: new disk Mar 5 08:22:44 Tower kernel: [ 7943.144762] md9: new disk Mar 5 08:22:44 Tower kernel: [ 7943.144768] md: start_array: ERROR:INVALID_EXPANSION Mar 5 08:22:44 Tower kernel: [ 7943.145791] md9: new disk Mar 5 08:22:44 Tower kernel: [ 7943.635957] md9: new disk Mar 5 08:22:44 Tower emhttp[1094]: shcmd (33): killall -HUP smbd Mar 5 08:22:46 Tower kernel: [ 7945.169935] md9: new disk Mar 5 08:22:48 Tower kernel: [ 7947.186069] md9: new disk Mar 5 08:22:50 Tower kernel: [ 7949.202054] md9: new disk Mar 5 08:22:52 Tower kernel: [ 7951.218093] md9: new disk Mar 5 08:22:54 Tower kernel: [ 7953.234180] md9: new disk Mar 5 08:22:56 Tower kernel: [ 7955.250125] md9: new disk Mar 5 08:22:58 Tower kernel: [ 7957.266097] md9: new disk I'll send a full syslog to Tom via e-mail... but basically, its last few lines look like this: Mar 5 09:18:54 Tower kernel: [11307.572957] md9: new disk Mar 5 09:18:56 Tower kernel: [11309.602047] md9: new disk Mar 5 09:18:58 Tower kernel: [11311.723123] md9: new disk Mar 5 09:19:01 Tower kernel: [11313.748932] md9: new disk Mar 5 09:19:01 Tower emhttp[1094]: ... clearing 66% complete Mar 5 09:19:03 Tower kernel: [11315.865301] md9: new disk Mar 5 09:19:05 Tower kernel: [11317.891567] md9: new disk Mar 5 09:19:07 Tower kernel: [11319.917276] md9: new disk Mar 5 09:19:09 Tower kernel: [11322.232017] md9: new disk Mar 5 09:19:11 Tower kernel: [11324.258679] md9: new disk Mar 5 09:19:13 Tower kernel: [11326.286176] md9: new disk Mar 5 09:19:15 Tower kernel: [11328.309179] md9: new disk Joe L.
March 5, 200818 yr Author The plot thickens... This time, when the clearing process was complete, the syslog entries looked like this: Mar 5 09:54:35 Tower kernel: [13444.382847] md9: new disk Mar 5 09:54:37 Tower kernel: [13446.518032] md9: new disk Mar 5 09:54:39 Tower kernel: [13448.544661] md9: new disk Mar 5 09:54:41 Tower kernel: [13450.660989] md9: new disk Mar 5 09:54:44 Tower kernel: [13452.878707] md9: new disk Mar 5 09:54:46 Tower emhttp[1094]: ... clearing 100% complete Mar 5 09:54:46 Tower emhttp[1094]: ... syncing Mar 5 09:54:46 Tower kernel: [13454.903725] md9: new disk Mar 5 09:54:48 Tower emhttp[1094]: driver cmd: start EXPANDING Mar 5 09:54:48 Tower kernel: [13456.689028] mdcmd (5403): start Mar 5 09:54:48 Tower kernel: [13456.690067] md9: new disk Mar 5 09:54:48 Tower kernel: [13456.691927] unraid: allocated 21366kB Mar 5 09:54:48 Tower kernel: [13456.692168] md1: running, size: 488386552 blocks Mar 5 09:54:48 Tower kernel: [13456.692193] md2: running, size: 390711352 blocks Mar 5 09:54:48 Tower kernel: [13456.692213] md3: running, size: 245117344 blocks Mar 5 09:54:48 Tower kernel: [13456.692232] md4: running, size: 390711352 blocks Mar 5 09:54:48 Tower kernel: [13456.692251] md5: running, size: 390711352 blocks Mar 5 09:54:48 Tower kernel: [13456.692269] md6: running, size: 390711352 blocks Mar 5 09:54:48 Tower kernel: [13456.692288] md7: running, size: 488386552 blocks Mar 5 09:54:48 Tower kernel: [13456.692311] md8: running, size: 488386552 blocks Mar 5 09:54:48 Tower kernel: [13456.692329] md9: running, size: 245117344 blocks Mar 5 09:54:48 Tower emhttp[1094]: driver cmd: checkMar 5 09:54:48 Tower kernel: [13457.045655] mdcmd (5406): check Mar 5 09:54:48 Tower kernel: [13457.045667] md: recovery thread got woken up ... Mar 5 09:54:48 Tower emhttp[1094]: shcmd (37): udevsettle Mar 5 09:54:48 Tower kernel: [13457.051729] md: recovery thread has nothing to resync Mar 5 09:54:48 Tower emhttp[28520]: shcmd (38): mkdir -m 700 /mnt/disk1 Mar 5 09:54:48 Tower emhttp[28520]: shcmd (39): mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1 >/dev/null 2>&1 Mar 5 09:54:48 Tower kernel: [13457.180738] ReiserFS: md1: found reiserfs format "3.6" with standard journal Now, the screen looks like this: with the array started and a choice available to format my new disk9. I pressed the format button and the screen looked like this... It stayed that way until I pressed the refresh button again a few minutes later. I think the format only takes a few seconds... but once I pressed the refresh button now my screen looks like this: I've got a feeling some variables are not being initialized correctly in the expansion process, or perhaps some of my disks had gone to sleep while the clear was in progress and were not found at the time the expansion was first attempted... in any case, this time the array expansion was successful. My syslog through all this is here... Joe L.
March 5, 200818 yr Author True... a shell script looking for status change to spin up the drives when my media player goes online. Might it have gotten things confused? Joe L.
March 5, 200818 yr I didn't spend a lot of time ensuring the command/status interface was multi-thread aware - it should be, but this wasn't tested extensively. Theory is your shell script is executing 'mdcmd status' right around same time as emhttp process is sending 'mdcmd start' command. I'll have to look into this - note this is probably not a 4.2.3 specific problem.
March 5, 200818 yr Author I didn't spend a lot of time ensuring the command/status interface was multi-thread aware - it should be, but this wasn't tested extensively. Theory is your shell script is executing 'mdcmd status' right around same time as emhttp process is sending 'mdcmd start' command. I'll have to look into this - note this is probably not a 4.2.3 specific problem. I'm happy to hear it might be that simple... (for me, as I can make the shell script use a different test to determine when the array is off-line, even if it does complicate your life... because it sounds as if it could just as easily have been somebody pressing the refresh button on the web-interface) I can try adding another drive I have laying around... it is a tiny one, if you think it might help. (I'm as good a test-case as any) Joe L.
March 5, 200818 yr Someone pressing Refresh would not see this because the web interface is the same process tree as the one which is clearing new disks & great care has been taken here to prevent this kind of problem. User customizations are "at your own risk", but I agree this problem should be fixed.
March 5, 200818 yr Author Someone pressing Refresh would not see this because the web interface is the same process tree as the one which is clearing new disks & great care has been taken here to prevent this kind of problem. User customizations are "at your own risk", but I agree this problem should be fixed. I'll accept the blame, but since I've never run into an instance where my status call to the kernel module caused any issue with emhttp, my first thought was it was a side-effect of your changes to the parity-swap code. (I have once or twice belonged to the "find-a-bug, fix-a-bug, cause-a-different-bug club..." I'm guessing you have had at least an honorary membership at one time or another? ) Joe L. p.s. My new shell script for my media player now uses this for the get_status function. It will keep status checks from occurring unless the samba daemon is active. That should keep my checks exclusive from most maintenance activity emhttp would be doing. # Determine if the unRaid array is on-line or not. If not currently # started, we do not want to be spinning up any drives. # Grab the physical disks we need to spin up at the same time get_status() { ps -ef | grep smbd >/dev/null 2>/dev/null if [ $? != 0 ] then STATUS="stopped" else cmd status | strings >/tmp/$$spin_up_status STATUS=`grep mdState /tmp/$$spin_up_status | cut -d "=" -f2` PHYSICAL_DISKS=`grep "^rdevName.*=" /tmp/$$spin_up_status | cut -d "=" -f2` fi }
March 11, 200818 yr I think I experienced something similar recently, but it was with v4.2, not 4.2.3, and I'm not running any modifications or scripts. I added a new drive, the first since the initial setup of my system. Everything would appear to go fine (clear, format) but upon reboot the drive would no longer be considered part of the array and running a parity check identified errors. Went through this a couple times, rebuilt parity, and rebooted with the same effect. At the same time I noticed that my time zone settings no longer appeared correct on the web page (I had previously used the documented steps to download the appropriate "custom" timezone file). The problem appeared to be related to the fact that I had the "flash" share exported as read-only, as once I set it to read/write, adding the new drive persisted and my timezone settings returned. Is it possible a script somewhere is referring to the potentially read-only flash share rather than to the usb device directly? Sorry I didn't document the problem any better than this. It didn't occur to me at the time, and once things were working I stopped worrying about it I'm running an MD-1500/LL with no modifcations to what came in the box other than to add drives, update the timezone and the unRAID version.
Archived
This topic is now archived and is closed to further replies.