graywolf

there is the pre-zero reads and post-zero reads. They both help stress test the drives. READ Joe L's following reply. I misunderstood exactly what the -N parm did BUT if you were wanting to skip the post-read, you would use the -N [uppercase] parm for the pre-clear script. Since you are doing 4 cycles, and only want to perform the post-read on the last cycle, what you would do would be: preclear_disk.sh -c 3 -N /dev/sd* then after those, you would do 1 more (for your 4th) preclear_disk.sh /dev/sd* (if you wanted to skip both pre & post reads, you would use -n [lowercase] parm) Usage: $progname [-t] [-n] [-N] [-m e-mail-addr] [-M 1|2|3|4] [-c count] /dev/??? where = hda, hdb, sda, sdb, etc... -n = Do NOT perform preread and postread of entire disk to allow SMART firmware to reallocate bad blocks in the clearing process -N = Do not perform read validation during postread. (skip this step) (basic test to check if values read are all zero as expected. Skipping this test will save a few miniutes, but possibly not detect a drive that returns non-zero values when zeros were expected as bad.) -c count = perform count preread/clear/postread cycles where count is a number from 1 through 20 If not specified, default is 1 cycle. For large disks, 1 cycle can take 10 or more hours -t = Test if disk has pre-clear signature. This option may NOT be combined with the -c or -n options. The test does not write to the disk. It makes no changes to a disk at all. It only reads the first 512 bytes of the disk to verify a pre-clear signature exists. Note: "-t" does not read the entire disk to verify it it pre-cleared as that could take hours for a large disk. since the pre-clear-signature is written *after* a disk is entirely filled with zeros, if it exists, we assume the disk is cleared. -w size = write block size in bytes -r size = read block size in bytes -b count = number of blocks to read at a time -v = print version of $progname -m [email protected] = optional recipient address. If blank and -M option is used, it will default to default e-mail address of "root" -M 1 = Will send an e-mail message at the end of the final results (default if -m is used, but no other -M option given) -M 2 = Will send an e-mail same as 1 plus at the end of a cycle (if multiple cycles are specified) -M 3 = Will send an e-mail same as 2 plus at the start and end of the pre-read, zeroing, post-read -M 4 = Will send an e-mail same as 3 plus also at intervals of 25% during the long tests The -m, -M options requires that a valid working mail command is installed. One version that has worked (bashmail) is affilaited with the unraid_notify script. There are others that also will work. Any of these need to be configured to work with your mail server. The unraid_notify script will have instructions on how to configure this. See http://lime-technology.com/forum/index.php?topic=2470.0 for unraid_notify and http://lime-technology.com/forum/index.php?topic=2961.0 for the mail script. NOTE: The lastest verion of mail has to be used. earlier versions of the mail script affiliated with unraid_notify do not support the standard mail syntax needed. Unless the -n option is specified the disk will first have its entire set of blocks read, then, the entire disk will be cleared by writing zeros to it. Once that is done the disk will be partitioned with a special signature that the unRAID software will recognize when the drive is added to the array. This special signature will allow the unraid software to recognize the disk has been pre-cleared and to skip an initial "clearing" step while the server remains off-line. The pre-read and post-read phases try their best to exercise the disk in a way to identify a drive prone to early failure. It performs reads of random blocks of data interspersed with reads of sequential blocks on the disk in turn. This program also uses non-buffered reads of the first and last cylinders on the disk, the goal is to perform those reads in between the others, and to keep the disk head moving much more than if it just read each linear block in turn.

how did you kick it off? was it from a telnet session? is the telnet session still open? if you didn't keep the telnet session connected, then the script ended when the telnet session ended. otherwise, you should be able to look at the session where you kicked it off and see the progress where it is at.

try ls -l /dev/disk/by-id Sample output would be: lrwxrwxrwx 1 root root 9 2011-01-14 10:55 ata-Hitachi_HDS722020ALA330_JK1101YBJRHY1F -> ../../sdh lrwxrwxrwx 1 root root 10 2011-01-14 10:55 ata-Hitachi_HDS722020ALA330_JK1101YBJRHY1F-part1 -> ../../sdh1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 ata-SAMSUNG_HD204UI_S2H7J1BZA28980 -> ../../sdg lrwxrwxrwx 1 root root 9 2011-01-14 10:55 ata-SAMSUNG_HD204UI_S2HGJDWZ806729 -> ../../sdf lrwxrwxrwx 1 root root 10 2011-01-14 10:55 ata-SAMSUNG_HD204UI_S2HGJDWZ806729-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 ata-ST32000542AS_6XW1P9ED -> ../../sdb lrwxrwxrwx 1 root root 10 2011-01-14 10:55 ata-ST32000542AS_6XW1P9ED-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_Hitachi_HDS7220_JK1101YBJRHY1F -> ../../sdh lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_Hitachi_HDS7220_JK1101YBJRHY1F-part1 -> ../../sdh1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_SAMSUNG_HD204UIS2H7J1BZA28980 -> ../../sdg lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_SAMSUNG_HD204UIS2HGJDWZ806729 -> ../../sdf lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_SAMSUNG_HD204UIS2HGJDWZ806729-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_ST32000542AS_6XW1P9ED -> ../../sdb lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_ST32000542AS_6XW1P9ED-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_ST32000542AS_6XW1T2LJ -> ../../sdc lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_ST32000542AS_6XW1T2LJ-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_WDC_WD20EADS-00_WD-WCAVY4045062 -> ../../sde lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_WDC_WD20EADS-00_WD-WCAVY4045062-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 scsi-SATA_WDC_WD20EADS-00_WD-WCAVY4310187 -> ../../sdd lrwxrwxrwx 1 root root 10 2011-01-14 10:55 scsi-SATA_WDC_WD20EADS-00_WD-WCAVY4310187-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 2011-01-14 10:55 usb-SanDisk_Cruzer_355010189012F904-0:0 -> ../../sda lrwxrwxrwx 1 root root 10 2011-01-14 10:55 usb-SanDisk_Cruzer_355010189012F904-0:0-part1 -> ../../sda1 so find the line with the drive/serial number and the end of the line tells you the device name. Ignore the lines that end in 1

Check your local small PC repair shops. They may have some. Otherwise look at something like 100 ct bags or so.

What was the 2TB drive you used? WD, Samsung, Seagate, etc AND model? For example, was it a WD20EARS ? Did you have the jumpers set? Any specific information you can provide will assist in advising you.

so what does setting autoneg off do? why would someone want it on, or would want it off?

Sounds like it might be HPA (search the forums on it) that is causing you problems.

Is the XP in the same WorkGroup as all the other PCs?

If all the disks are the same size, make your allocation for the share MOST FREE. That should do the trick. If not all the same size, the larger disks will be used until the "free space" on the larger disks are around the same size as the smaller disks, then they will start being used also.

what page? Under all the pictures

Have no clue if it would turn back on with a server restart/reboot But if you wanted, you could put the command in your go script.

another way would be: ls -lR \mnt\disk*> /boot/directory_list.txt

you can use mc (midnight commander) to make it easier telnet in cd /mnt mc <left pane get to /mnt/disk4 by drilling down> <right pane get to /mnt/disk5 by drilling up/down as the case may be> <on left pane, click/highlight the Storage directory> F6 <which will do the mv command for you>

Another thing you might check is how close are the serial numbers? That might also indicate if they might be from the same batch or not. Like others have said, you should be fine in most cases. As long as when 1 does fail, you replace it in a timely manner.

rats. missed this yesterday. could use another UPS. would have been a good deal. guess I'll just have to watch for any other sales that come along

I've been corrected in another post, i was wrongly looking at the raw values instead of current values column. What you should do is runn diff between the starting/ending smart reports and see if current value has changed between them for those rows. also compare current versus threshold.

Reallocated, Pending, and Error rates all 0....looks good to me. Just checking since you didn't mention it and these are EARS, did you jumper pins 7-8 prior to preclear? If not, you'll probably need to preclear them again after putting the jumpers on and BEFORE adding them to your array

Similiar to my just preclearing 2 WD 2TB drives. From other readings, the speed difference is normal due to where on the platter you are reading. Joe could give a better explanation than I. Since you are in the post-read, you could calculate the estimated time remaining by taking the full size in bytes minus already read, divide that by 1048576 to get MB, then divide that by 50MB/s (or whatever your current speed is) which will give you seconds, divide that by 60 to get approx minutes left.

Here are the smartctl for the disk that completed. diff is: 19,20c19,20 < Offline data collection status: (0x80) Offline data collection activity < was never started. --- > Offline data collection status: (0x84) Offline data collection activity > was suspended by an interrupting command from host. smart_start1387.txt smart_finish1387.txt

OK...pre-clearing 3 disks. 1 completed and I would think is good. Other 2 were at 98% and 96% of post-read phase when had a storm power outage. This is not on UPS (but I see the value in getting one now) so naturally the starting SMART logs no longer exist. Attached is the output from smartctl -a /dev/sd[a,b] As much as I know, they look good. So what should really be paid attention to?? reallocate, error_rate, what else? So would you figure they are good or recommend going thru the pre-clear process again for them? smart-sda.txt smart-sdb.txt