slarco

I just did what you sugested and worked like a charm. Thank you so much for your help man. Now i can get the info back from each drive and put it back in the 1 drive that i kept on the array. Thx a lot

Thanks for the answer. I´ll give it a try once i get back from work!

So i messed up reading over the instructiones (https://lime-technology.com/wiki/index.php/Shrink_array) I misunderstood the instrucions posted for the "Remove Drives Then Rebuild Parity" Method and i didn't manually move the data from the drives that i was going to remove from the Array This method does not keep the drive's data within the array. If the drive to be removed has data you want to stay in the array, you must move it yourself to the other data drives. Parity will be built based entirely and only on the remaining drives and their contents. Now is still running a parity sync / Data Rebuild. I still have the drives haven't touch anything yet after the 1st reboot. Is there anything that i can do to reassign the drives that i just took off , get them back on the array, move the data from them to the one drive that im keeping on the array and take them off again? I was reading the instruction so carefully but i guess i misinterpreted because English is not my fist lenguage. So sad, I'm looking to loose over 10 years of pictures. Thanks in advance guys.. I'm running 6.3.3 btw

zip it, (they zip really well) or, use ext host as you described. For pre-clear results I really do not need to see the entire syslog. You can attach only the pre-clear reports as found in /boot/preclear_reports Joe L. Ok, got the report on both drives. thx in advance both look fine. Thx Joe

zip it, (they zip really well) or, use ext host as you described. For pre-clear results I really do not need to see the entire syslog. You can attach only the pre-clear reports as found in /boot/preclear_reports Joe L. Ok, got the report on both drives. thx in advance preclear_rpt__WD-WCAWZ1679024_2012-03-29.txt preclear_rpt__WD-WCAWZ1714217_2012-03-29.txt

What if my syslog weight more than 192k? Use a external host? Just paste as quote?

other than it being pretty cool, no. Thx Joe

Does anyone see any problem with this last drive?? Thx in advance Prclear_Syslog_13-07-2011_WD20_WMAZA4246729.txt

perfectly normal, BUT your version of the preclear script is probably at least 10 versions old. Please always download and use the newest one. Dang, I didn't know. I am going to look for the newest version right now. Thx Joe

I just added a new disk, can anyone tell me if the Preclear results looks normal? Thx syslog-2011--06-29.txt

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count. I'd not wait if the current pending sectors on the parity drive are increasing by a few counts a day. I'd replace it and get a RMA process started on the old one. Joe L. I could try to do that but the thing is that i live in Chile, and if I replace the drive now and another drive goes bad from now until March i will be F*****, because here in chile i don't have any chance to get that kind of drive. So I was expecting get the RMA in my next trip to the USA (march) and try to hang on with this drive until that. I see... If it is your parity drive you can actually take some preventative measures. Here is an idea, see what you think. A sector pending re-allocation is one that the disk was unable to read properly. The pending-reallocation logic is waiting for that same sector to be written again so it can re-allocate it from its spare pool of sectors. Unfortunately, the parity disk sectors are not normally written unless the equivalent sector on one of the data disks is written. What you could do is force unRAID to re-write all the parity disks sectors. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those 2 or three sectors it would give the SMART firmware the opportunity to re-allocate the sectors it could not read. The first step is to perform a normal parity "Check" This will allow all the drives to read all their sectors and if there are any un-readable, hopefully re-allocate them. Once the parity check is complete, get a set of SMART reports, one from each of your drives. Hopefully none of the data drives will have sectors pending re-allocation. Then, if there are pending-reallocation sectors only on the PARITY drive, Stop the array Un-assign the parity drive on the "devices" page. (leave the parity disk unassigned for the next two steps) Start the array with the parity disk un-assigned. Stop the array once more. Re-assign the parity drive on the "devices" page. Start the array with the parity disk re-assigned. This last step will force unRAID to think the parity drive needs to be completely re-written. It will, of course, be re-writing all the parity disks sectors, including those pending re-allocation. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those few sectors pending re-allocation it would give the SMART firmware the opportunity to re-allocate the sectors. With any luck this will allow the SMART firmware to re-allocate all the sectors pending re-allocation. You'll have the time to get to the USA in March to obtain a replacement drive. To re-group if anything goes drastically wrong (another disk concurrently fails) you can use the "trust my parity" procedure since you know that parity is good (the process above was just re-writing exactly what is already on the parity disk.) Then you would be in exactly the same situation as you are now if a data disk were to fail, using parity and the other data disks to simulate the failed disk. Joe L. Ok, Im on it. Thx Joe. I will let you know how things goes. I did all the process and went down to 9 errors. Better than 22 but still not what i was hoping for. THanks for the help anyway Joe

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count. I'd not wait if the current pending sectors on the parity drive are increasing by a few counts a day. I'd replace it and get a RMA process started on the old one. Joe L. I could try to do that but the thing is that i live in Chile, and if I replace the drive now and another drive goes bad from now until March i will be F*****, because here in chile i don't have any chance to get that kind of drive. So I was expecting get the RMA in my next trip to the USA (march) and try to hang on with this drive until that. I see... If it is your parity drive you can actually take some preventative measures. Here is an idea, see what you think. A sector pending re-allocation is one that the disk was unable to read properly. The pending-reallocation logic is waiting for that same sector to be written again so it can re-allocate it from its spare pool of sectors. Unfortunately, the parity disk sectors are not normally written unless the equivalent sector on one of the data disks is written. What you could do is force unRAID to re-write all the parity disks sectors. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those 2 or three sectors it would give the SMART firmware the opportunity to re-allocate the sectors it could not read. The first step is to perform a normal parity "Check" This will allow all the drives to read all their sectors and if there are any un-readable, hopefully re-allocate them. Once the parity check is complete, get a set of SMART reports, one from each of your drives. Hopefully none of the data drives will have sectors pending re-allocation. Then, if there are pending-reallocation sectors only on the PARITY drive, Stop the array Un-assign the parity drive on the "devices" page. (leave the parity disk unassigned for the next two steps) Start the array with the parity disk un-assigned. Stop the array once more. Re-assign the parity drive on the "devices" page. Start the array with the parity disk re-assigned. This last step will force unRAID to think the parity drive needs to be completely re-written. It will, of course, be re-writing all the parity disks sectors, including those pending re-allocation. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those few sectors pending re-allocation it would give the SMART firmware the opportunity to re-allocate the sectors. With any luck this will allow the SMART firmware to re-allocate all the sectors pending re-allocation. You'll have the time to get to the USA in March to obtain a replacement drive. To re-group if anything goes drastically wrong (another disk concurrently fails) you can use the "trust my parity" procedure since you know that parity is good (the process above was just re-writing exactly what is already on the parity disk.) Then you would be in exactly the same situation as you are now if a data disk were to fail, using parity and the other data disks to simulate the failed disk. Joe L. Ok, Im on it. Thx Joe. I will let you know how things goes.

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count. I'd not wait if the current pending sectors on the parity drive are increasing by a few counts a day. I'd replace it and get a RMA process started on the old one. Joe L. I could try to do that but the thing is that i live in Chile, and if I replace the drive now and another drive goes bad from now until March i will be F*****, because here in chile i don't have any chance to get that kind of drive. So I was expecting get the RMA in my next trip to the USA (march) and try to hang on with this drive until that.

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count.

Or should i just run the preclear again?? Why? There was nothing wrong with what you posted. The drive looked fine. Because i just checked the syslog that i have here and is empty, so I thougt that the one that I posted is empty too... So i have no idea if the drive is good or not perhaps we are talking about different drives. In any case, you can get the full SMART report on the drive by typing: smartctl -d ata -a /dev/sdX where sdX = the device name of your specific device. There is no need to run the preclear script just wait hours for it to invoke that exact same command to see the final status of the drive. Joe L. Ok, this is the status o the new drive. Seems fine to me, but im not an expert. Can you tell me if it it's fine? I am planing to use this drive to replac my parity. Every day get 1 or 2 more current pending sector. Thanks in advance ! Syslog.txt