jbuszkie

Yeah.. That's the bummer of it! It would be nice if we had a command to remove the drive from the array without losing parity protection. I know it can be done if we were to zero out the disk first.. but I want to keep the data! We need a disable writes to drive x and recalc parity without drive x. Jim

I'm assuming the answer is yes.. but I'd figure I'd ask anyway because I've never tried it.. I have one of my drives which stores my backups. When it gets full, I would like to remove it from the array and keep it in a drawer or something.. Easy enough to remove.. but if I need to get some data off it at later date, will I be able to hook it back up and just mount the resiersFS without adding it back to the array? Thanks, Jim

I think I fiured out what was happening with the speed of my tests. It turn out the disks are slower when they are formatted. Not sure why.. but if I "clear" the disk and wipe out the partitions, the test is much faster. It uses a much smaller block size when it's formatted vs when it's clear. fdisk (formatted): root@Tower2:/boot/scripts# fdisk -l /dev/sda Disk /dev/sda: 1500.3 GB, 1500301910016 bytes 1 heads, 63 sectors/track, 46512336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 2 46512336 1465138552+ 83 Linux Partition 1 does not end on cylinder boundary. fdisk after clearing: root@Tower2:/boot/scripts# fdisk -l /dev/sda Disk /dev/sda: 1500.3 GB, 1500301910016 bytes 255 heads, 63 sectors/track, 182401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 182402 1465138552+ 0 Empty Partition 1 does not end on cylinder boundary. The smaller block size makes the test run much slower. Have you seen this? This makes my reads drop to about 30-40MB/s from 90ish MB/s Why does fdisk report differently? Does the smaller block size make the test any better? As in more thrashing? This explains why I had two very different speeds! Jim

There is a program called screen. It allows you to disconnect and reconnect to a particular session. I have that setup and it works nicely. there is a post somewhere that describes what you need.. You might be able to search the forums for it. Also.. if you have mail setup.. you can use the mail parameters and it will e-mail you the differences as well.. Jim

If you didn't get any results when precear finished then your disk is good! Also looking at the smart results you posted look great. If you had issues you would have seen output along the lines of: S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 57c57 < 1 Raw_Read_Error_Rate 0x000f 099 099 051 Pre-fail Always - 5005 --- > 1 Raw_Read_Error_Rate 0x000f 099 099 051 Pre-fail Always - 5264 66c66 < 13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 4648 --- > 13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 4912 69c69 < 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 4952 --- > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 9596 71c71 < 190 Airflow_Temperature_Cel 0x0022 071 067 000 Old_age Always - 29 (Lifetime Min/Max 29/33) --- > 190 Airflow_Temperature_Cel 0x0022 068 067 000 Old_age Always - 32 (Lifetime Min/Max 29/33) 74c74 < 197 Current_Pending_Sector 0x0012 092 092 000 Old_age Always - 331 --- > 197 Current_Pending_Sector 0x0012 100 092 000 Old_age Always - 0 78c78 < 201 Soft_Read_Error_Rate 0x000a 097 097 000 Old_age Always - 228 --- > 201 Soft_Read_Error_Rate 0x000a 100 097 000 Old_age Always - 0 You probably got a "pre-clear was successful" or something like that.. Enjoy the new drive!

There is something weird going on... I ran the test on both disks again concurrently and this time I got the same results as running a single. I can't duplicate the 25MB/s or even the 34MB/s Maybe I should just be happy I'm getting the faster speeds! Maybe I was running a some modifed version of the script that ran slow? Bizarre..

Just for more data.... On my 300GB drive... Using DD with no block size I get 27769+0 records out 14217728 bytes (14 MB) copied, 31.8698 s, 446 kB/s 66361+0 records out 33976832 bytes (34 MB) copied, 81.6211 s, 416 kB/s If I do dd if=/dev/zero bs=2048k of=/dev/md2 & I get: 78+0 records out 163577856 bytes (164 MB) copied, 15.3426 s, 10.7 MB/s 1886+0 records out 3955228672 bytes (4.0 GB) copied, 363.529 s, 10.9 MB/s 2678+0 records out 5616173056 bytes (5.6 GB) copied, 516.283 s, 10.9 MB/s So for me using the block size really helps! FYI..

I after I ran it a second time by its self, I got to 17.8ish hours. So I feel better.. I would have thought that running two disks wouldn't have THAT much of an effect! Maybe I'll boost the memory speed and CPU speed. Maybe that will help concurrent pre-clears. I've got it crippled to lower the power...

I ran the disk one more time. This is what I got: S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 57c57 < 1 Raw_Read_Error_Rate 0x000f 099 099 051 Pre-fail Always - 5005 --- > 1 Raw_Read_Error_Rate 0x000f 099 099 051 Pre-fail Always - 5264 66c66 < 13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 4648 --- > 13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 4912 69c69 < 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 4952 --- > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 9596 71c71 < 190 Airflow_Temperature_Cel 0x0022 071 067 000 Old_age Always - 29 (Lifetime Min/Max 29/33) --- > 190 Airflow_Temperature_Cel 0x0022 068 067 000 Old_age Always - 32 (Lifetime Min/Max 29/33) 74c74 < 197 Current_Pending_Sector 0x0012 092 092 000 Old_age Always - 331 --- > 197 Current_Pending_Sector 0x0012 100 092 000 Old_age Always - 0 78c78 < 201 Soft_Read_Error_Rate 0x000a 097 097 000 Old_age Always - 228 --- > 201 Soft_Read_Error_Rate 0x000a 100 097 000 Old_age Always - 0 ============================================================================ The Current_Pending_Sector didn't go up.. But neither did the Reallocated_Sectors?? what Happened to the 331 previous pending? Also the Raw_Read_Error_Rate and the Read_Soft_Error_Rate both went up.. but not as much as the first time. However the Reported_Uncorrect almost doubled. I also noted a bunch of errors in the syslog from the first time I ran the test (with both disks going) Here is a snippit of the error: Aug 23 16:20:49 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:20:49 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:20:49 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:20:49 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:20:49 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:20:49 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:20:49 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:20:49 Tower2 kernel: ata1: EH complete Aug 23 16:20:49 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:20:49 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:20:49 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:20:49 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 23 16:20:52 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:20:52 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:20:52 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:20:52 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:20:52 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:20:52 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:20:52 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:20:52 Tower2 kernel: ata1: EH complete Aug 23 16:20:52 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:20:52 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:20:52 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:20:52 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 23 16:20:55 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:20:55 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:20:55 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:20:55 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:20:55 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:20:55 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:20:55 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:20:55 Tower2 kernel: ata1: EH complete Aug 23 16:20:55 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:20:55 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:20:55 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:20:55 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 23 16:20:57 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:20:57 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:20:57 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:20:57 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:20:57 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:20:57 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:20:57 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:20:57 Tower2 kernel: ata1: EH complete Aug 23 16:20:57 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:20:57 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:20:57 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:20:57 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 23 16:21:00 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:21:00 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:21:00 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:21:00 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:21:00 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:21:00 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:21:00 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:21:00 Tower2 kernel: ata1: EH complete Aug 23 16:21:00 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:21:00 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:21:00 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:21:00 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Aug 23 16:21:03 Tower2 kernel: ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x0 Aug 23 16:21:03 Tower2 kernel: ata1.00: irq_stat 0x40000008 Aug 23 16:21:03 Tower2 kernel: ata1.00: cmd 60/00:08:18:fa:a1/02:00:62:00:00/40 tag 1 ncq 262144 in Aug 23 16:21:03 Tower2 kernel: res 41/40:60:b8:fa:a1/85:01:62:00:00/40 Emask 0x409 (media error) Aug 23 16:21:03 Tower2 kernel: ata1.00: status: { DRDY ERR } Aug 23 16:21:03 Tower2 kernel: ata1.00: error: { UNC } Aug 23 16:21:03 Tower2 kernel: ata1.00: configured for UDMA/133 Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] Sense Key : 0x3 [current] [descriptor] Aug 23 16:21:03 Tower2 kernel: Descriptor sense data with sense descriptors (in hex): Aug 23 16:21:03 Tower2 kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Aug 23 16:21:03 Tower2 kernel: 62 a1 fa b8 Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] ASC=0x11 ASCQ=0x4 Aug 23 16:21:03 Tower2 kernel: end_request: I/O error, dev sda, sector 1654782648 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847831 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847832 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847833 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847834 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847835 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847836 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847837 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847838 Aug 23 16:21:03 Tower2 kernel: Buffer I/O error on device sda, logical block 206847839 Aug 23 16:21:03 Tower2 kernel: ata1: EH complete Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] 2930277168 512-byte hardware sectors (1500302 MB) Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] Write Protect is off Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 Aug 23 16:21:03 Tower2 kernel: sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Full syslog attached except for a bug chunk in the middle I had to cut out to make the attacment the right size. It seems like there were a lot less errors the second time around. Now is this still an RMA canidate or do you think this might be a MB error? (It's new too) I'm running one more cycle Thanks, Jim

I just ran 2 disks single cycle. One disk was fine the other was not so much. Do you agree that this might be an RMA canidate? I'm running a sencond cycle to be sure.. S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 57c57 < 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 --- > 1 Raw_Read_Error_Rate 0x000f 099 099 051 Pre-fail Always - 5005 66c66 < 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 --- > 13 Read_Soft_Error_Rate 0x000e 099 099 000 Old_age Always - 4648 69c69 < 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 --- > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 4952 71c71 < 190 Airflow_Temperature_Cel 0x0022 070 070 000 Old_age Always - 30 (Lifetime Min/Max 30/30) --- > 190 Airflow_Temperature_Cel 0x0022 068 067 000 Old_age Always - 32 (Lifetime Min/Max 30/33) 74c74 < 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 --- > 197 Current_Pending_Sector 0x0012 092 092 000 Old_age Always - 331 78c78 < 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 --- > 201 Soft_Read_Error_Rate 0x000a 097 097 000 Old_age Always - 228 ============================================================================

But why the big descrepency with the cycle time? 17 hours vs 28 and 30 hours? I wouldn't think the 7200 vs 5400 would have that much of a difference. I'm running a single drive now again to see how much one drive vs 2 does. Jim

What was your cycle time for a 1.5T disk? It seemed like yours was in the 17 hour time frame from your screen capture? I would hope that I would get closer to that rather than the 28 hour time frame. Oh.. And the zeroing took ~5 hours.

I wasn't doing anything else with the array.. It was stopped. I was getting parity check speeds of 90-100MBs (parity synch was about 50-60MB/s) with the two drives when I tested that.. That's why I would expect to get something similiar with the pre-read. Maybe I'll try some dd comands. The preclear cycle for the disks took about 28 hours for one and 30 hours for the other. One was fine and the longer one had some smart errors which I'll post in the other thread. Jim

Joe, I just got a new unraid MB and CPU and I'm currently testing it with two new Samsung 1.5T drives. I'm preclearing both and I'm not getting nowhere near the speeds you are. If yours was a PCI based system.. Mine is a new pci-e based system. I only have the two drives attached. Syslog says they are runnign in 3.0Gbs... But they are both going at a rate of about 25% every 4 hours for the preread. Even when I just did one drive I was getting 2GB/min ~ 34MB/s. I would expect a lot better than that! Right now I'm getting about 25.6MB/s. Am I missing something. In the log I see: Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: smartctl version 5.38 [i486-slackware-linux-gnu] Copyright (C) 2002-8 Bruce Allen Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Home page is http://smartmontools.sourceforge.net/ Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: === START OF INFORMATION SECTION === Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Device Model: SAMSUNG HD154UI Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Serial Number: S1Y6J1KS743788 Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Firmware Version: 1AG01118 Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: User Capacity: 1,500,301,910,016 bytes Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Device is: In smartctl database [for details use: -P show] Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: ATA Version is: 8 Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: ATA Standard is: ATA-8-ACS revision 3b Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Local Time is: Fri Aug 21 23:17:43 2009 EDT Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details. Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: SMART support is: Available - device has SMART capability. Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: SMART support is: Enabled Aug 21 23:17:43 Tower2 preclear_disk-start[14626]: What is this -F samsung? I'm running in AHCI mode set in the bios. Anything else I'm missing?

Oh.. Can can this be under-clocked easily to reduce power?

Are you still happy with this board? I'm about to pull the trigger on this one...

Seems like the code is no good.. It told me it had already been redeemed.. May be oneone else will have better luck.

Brainbone, I've run into a little issue with the script. I was running parity syncs and my drive temps were going up. I stopped getting emails. After I looked into it a little I found out I was supposed to be getting error e-mails. If I commented out the RcptTo field in the cfg file, I started getting the e-mails. In debug mode it looks like my e-mail server didn't like the format when there was a RcptTo and an ErrorRcptTo. I dove in the script and I commented out the second a=0 in the place where it's building the To: header. That seems to make it work correctly. What are your thoughts? Jim

Wow! They fixed that pretty quickly! I didn't get the $160 so I'm actually happy... I saved myself $160

someone PLEASE talk me out of this! Seems like too good of a deal!!!

Each cycle is just about 12hours. I'm in no immediate rush so I just popped off another cycle. Maybe an interesting additiion to the script would be to save the smart data after every cycle so we can see when the events happend. When I ran the 1st 3 cycles I don't know if the events happened in the 1st, 2nd, or 3rd cycle.. Jim

Done! I started a new thread that can be devoted to just questions about the results of the script. Hopefully all the gurus will monitor that thread too! Thanks again, Joe, for a great script! Results discussion thread can be found here

In an effort to keep the Preclear script thread more about questions about the script itself, I've started another thread here to discuss the results. The preclear thread is peppered with result questions and questions about the script and is now 15 pages long! So I'm thinking that a seperate thread was warranted. So I'll start it off... If it stays at 5, in my opinion, no problem. If it increases over time, then you might want to use the RMA process. Odds are good it will stabilize. I have one 250Gig drive that has had 100 relocated sectors since the first time I ran smartctl on it. That number has never changed on that disk. I'd say, download the new version of preclear_disk.sh and run another set of test cycles and see if it shows an increase in re-allocated sectors. (the new version stress-tests the drive more. The old one had a bug that prevented the random cylinders from being read in addition to the linear read that was properly occurring) If the number stays at 5, fine, if not another test cycle might be in order. At that point you have all the evidence you need if an RMA is warranted. You might want to start a thread with your preclear experience. It will allow the questions about the output to all be in one spot. Joe L. Ok.. I ran one more full cycle with the new verions of the script and I got no reallocated sector changes. Should I run once more or do you think I'm good now and can put the disk into service? So... first 3 cycles. - 5 reallocated sectors 4th cycle - no more reallocated sectors. Jim

I haven't tried any of these.. but they seem pretty new. Good competition for the WD green drives? @ $109.. This seems like a good deal! Too bad I just bought a 1TB.. Have to wait till next credit card cycle! They are normally $115 but if you get hte newsletter and the code it's $109.99 FYI...

After running 3 interations on my new 1TB green disk I had < 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 --- > 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 5 64c64 < 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 --- > 196 Reallocated_Event_Count 0x0032 199 199 000 Old_age Always - 1 Are 5 reallocated sectors anything to worry about.. I was hoping for 0! This is still running on the old version of the script.. Maybe I should try the new version.. (I started my test the morning before Joe posted the new version!) I did start a cycle again on a different controller (one cycle this time - and still the old script) Another thought... Should we start a new thread for preclear disk result questions and keep this thread for questions/comments about the functionality of preclear? Jim