slarco

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

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

Or should i just run the preclear again??

Lol..i didnt save the syslog properly, any chance that i can recover it?? server is still up and running

I just precleared a new drive. Can anyone take a look at this please? Seems to be normal to me but i just want to make sure before add the disk to the array. Syslog Attached. Thanks in advance!! syslogData3-10-11-2010.txt

Hoe is good because im already moving data It is fine. The only counter that incremented was the "load-cycle" counter. And if it had NOT incremented there would have been a HUGE issue, because it would then indicate the disk heads did not move from their parked position. Enjoy your new drive. for now, at least, it is working well. (good cooling... the temp did not change from 29C at its start. You must have good fans) 04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Disk /dev/sdc has been successfully precleared Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Ran 1 preclear-disk cycle Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Using :Read block size = 8225280 Bytes Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Pre Read Time : 7:34:51 (73 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Zeroing time : 7:18:06 (76 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Post Read Time : 14:48:50 (37 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Total Time : 29:42:54 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Total Elapsed Time 29:42:54 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Disk Start Temperature: 29C Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Current Disk Temperature: 29C, Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]: S.M.A.R.T. error count differences detected after pre-clear Oct 21 04:04:16 Tower preclear_disk-diff[32619]: note, some 'raw' values may change, but not be an indication of a problem Oct 21 04:04:16 Tower preclear_disk-diff[32619]: 63c63 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 76 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: --- Oct 21 04:04:16 Tower preclear_disk-diff[32619]: > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 77 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]: Thanks Joe for taking the time to review the Logs. I have 2 Enermax 120mm + 2 Enermax 80mm fans

Hoe is good because im already moving data

I have one more syslog if anyone can take a look at this. I did check it for reallocated sectors and pending sectors. Seems fine to me but I been here for a short time. Thanks! syslog20-10-2010-0730.txt

Looks good. No re-allocated sectors, or sectors pending re-allocation. No parameters FAILING_NOW, nor any where the current value is nearing the failure-threshold. (You can see several changing from the factory 253 value to the starting value of 200.) You must have very good air flow past that drive, since its temperature only rose from 26C to 28C during the clearing cycle that lasted over 27 hours. Nice. Thanks Joe. FYI Im using 2 X 120mm Enermax Fans in the front and 2 X 80 mm Enermax fans in the rear. Both are really quiet, I love them .

Hey! Im back here again because i just finished the Preclear for a new drive and i was hoping to get some help with the syslog. Ilooked for the reallocated sectors and in my knowledge seems to be Ok. Syslog attached if anyone can take a look and give me some advice about the drive. Thx in advance!! syslog_26-9-2010-0200.txt

Everything looks normal. Enjoy your new drives. Yay...!!!!!!

Hi. I Just finished running the preclear script in 2 of my drives and i was wondering if anyone can give me some help in interpretate the syslogs. I read in this post about similar Syslogs and the Raw & UDMA errors and seems to e normal, but i just rather double check before start moving data. Syslogs attached Thanks in advance! syslog_21-9-2010-1000.txt syslog_22-9-2010-0940.txt

nothing new about this?