March 31, 201115 yr I have a few 2TB drives that were added pre-4.7 and aren't 4k aligned. I'm going through the align process now with 4.7. I've noticed something that seems to conflict with docs/posts. After unassigning, wiping the MBR, and rebooting, unRAID immediately starts the array every time, even in the degraded state. If I don't catch it and stop it quickly enough it'll get stuck unmounting for 10+ minutes waiting for some process that reads every disk a bunch, in sequence. It hasn't caused a problem yet, other than wasting time, and I haven't tried investigating the culprit at the console. Is there a way to tell unRAID not to start the array automatically, at least not if degraded?
March 31, 201115 yr What command are you using to wipe the MBR? Are these disk Advanced Format? If not, or they are WD EAR with jumpers, then there there is no advantage to reformatting.
April 1, 201115 yr Author Unfortunately I had begun installing AF drives before I even knew what AF meant. Now five of six are AF. The two WD EARS drives were never jumpered. Just dd'ing. I was more destructive with the first drive but dropped to 200 blocks after reading the faq: dd if=/dev/zero count=200 of=/dev/thedrive
April 1, 201115 yr When you first unassign the drive, immediately start the array with the subject drive unassigned. This will cause unRAID to forget about the drive and treat it as new. Then stop the array and clear the MBR. When you next start the array it should offer to rebuild the disk contents. The MBR cleared disk does not need to be formatted or cleared.
April 1, 201115 yr Author Right. That sounds like the sequence. From the thread: Stop, unassign, start, stop, dd, reboot, except each time in my case the array starts.
April 1, 201115 yr Unfortunately I had begun installing AF drives before I even knew what AF meant. Now five of six are AF. The two WD EARS drives were never jumpered. Just dd'ing. I was more destructive with the first drive but dropped to 200 blocks after reading the faq: dd if=/dev/zero count=200 of=/dev/thedrive I think it is enough to just clear 1 block (count=1) ... That would zero out the partition table and the entire MBR. It does not hurt anything to clear 200, it just zeros the initial part of any file system too.
April 1, 201115 yr Unfortunately I had begun installing AF drives before I even knew what AF meant. Now five of six are AF. The two WD EARS drives were never jumpered. Just dd'ing. I was more destructive with the first drive but dropped to 200 blocks after reading the faq: dd if=/dev/zero count=200 of=/dev/thedrive I think it is enough to just clear 1 block (count=1) ... That would zero out the partition table and the entire MBR. It does not hurt anything to clear 200, it just zeros the initial part of any file system too. I used a count of 8 and unRAID seemed to still identify the existing file system even though the alignment is "unknown". I was worried that something odd would happen so I increased the count and unRAIDs reference to the file system was gone as well. I'm not sure why your array is starting after reboot. Other than this can you follow the procedure?
April 2, 201115 yr Author Certainly, it works, it's just a little unsettling to be consistently inconsistent. Just started the fourth drive on its rebuild. Slight error in the steps. Stop, unassign, dd - oops, start, stop, dd, reboot. Again, the array started immediately after the reboot but this time it stopped quickly when asked, without the long delay-of-reads. No doubt because I was waiting at the console for it to happen.
April 2, 201115 yr I'm not sure why you are rebooting either. There is no reason to reboot before assigning the drive and starting again. It was bad advice wherever you read it. The basic idea is this - Stop, unassign, dd, start, dd alternate #1, stop, dd alternate #2, assign, start. The dd command can be done at any time while the drive is unassigned. You stopped the array and then started the array with the disk missing. Once you do that, unRAID ~assumes~ that is what you want to do from that point forward. So, the array will start after a reboot because the config is considered valid after you started it with the disk missing. And unRAID always automatically starts the array (except in the 5.0b6a) when it boots if the array is considered valid. Peter
April 2, 201115 yr Author Seems like I saw the recommendation to reboot several times in various threads about alignment and it sounded logical to clear remnant state information. I'll avoid it for the last drive. But, I settled on the procedure in the top-most sticky, "EARS Jumpered / Unjumpered Thread", the 2nd section: "TO PROPERLY ALIGN AN UNJUMPERED EARS DRIVE ALREADY IN THE ARRAY".: (http://lime-technology.com/forum/index.php?topic=11842.0) ... 8 - Reboot (click reboot buttong on unRAID GUI) 9 - Array should not start automatically. DO NOT START IT YET! ... Looks like some steps may have unintentionally drifted among the sections.
Archived
This topic is now archived and is closed to further replies.