Joe L.

You must do it from the system console. It is a choice on the boot menu. (cannot do it from telnet) From what you said, odds are it is the disk.

It is not a good sign. It does save you from possibly pulling out your hair in attempting to find elusive random parity errors. the preclear wrote a block of zeros. When it read them back, they were not all zeros. You can look in the syslog, but we've seen many cases where no other errors are reported. Typically, with MS-Windows, we would blame Microsoft, but in this case, it is bad hardware... The same symptoms could also be caused by bad RAM, so I'd suggest a memory test, preferably overnight before condemning the disk, and then trying it on a different port on the disk controller, is it also could be the cause. I see another preclear cycle in your future.

Unless you ran it under "screen", it was terminated when you lost the telnet session. The unMENU MyMain screen only shows the progress it had when the progress file kept for that purpose was last updated. (In other words, don't expect the 50% to advance to 51%, as the file will never be updated.)

CRC errors are usually cabling or power supply related. Also, make sure you are not bundling your data cables close to power cables.

that is not the output of the preclear_disk.sh script. looks ok, but no idea if it was successfully cleared or not.

me too. They seem to always be re-written into place, so I'd suspect the power supply as an additional thing to check. (poor quality power might contribute to a poor quality write of the disk) In general, I'd not trust my data on it. Joe L.

If everything is in RAM, yes. There is no need for the OS to to read the directories from the physical disk, since they are in the linux buffer cache, so each "find" command is very fast.

Nothing wrong... Just different drives.

Since he says it is in the "writing" of the disk where errors occur, reading from it using "dd" as you described will probably not help. Instead, for a quicker test, simply use the "-W" option to the preclear script to ask it to skip the initial "reading" of the disk. It will then start with the "writing" of zeros. preclear_disk.sh -W /dev/sdX

You are misinformed. On drives > 2.2TB, a different partitioning scheme is used. It is a GPT partition, and it indeed is aligned to a 4k boundary, so it is compatible even with those drives whose performance suffers when a partition is not aligned with a 4k boundary. To keep older utilities from thinking the drive is not partitioned, since the GPT partition does not use the MBR, a "protective partition" is defined in the MBR. That "protective partition" is defined as starting on partition 1 and extending the full 2.2TB that was possible using an MBR partition table. IT is there only to make older utilities (such as "fdisk") happy. To them, the entire drive is allocated and no further partitioning is possible. You need not worry. Everything is as it should be. One more thing... your drive is NOT an "advanced format" drive that needs to be handled specially. It presents 512 byte sectors to the OS and hitachi drives do not suffer regardless of the alignment of partitions. Also, as far as I know, no drive uses 4096 byte sectors when communicating with the OS. The WD EARS drives were the only ones where performance suffered if not accessed on a 4k alignment. (But even they work perfectly fine in unRAID, regardless of how they are jumpered or partitioned.) Even un-aligned, they have more than sufficient performance to serve up movies, since most media access is linear, and we typically read large numbers of contiguous blocks from the disks. Joe L.

looks good

looks good to me

you are having I/O errors on /dev/sdh. Those are filling the syslog to where you are running out of available memory, so the out-of-memory process in the kernel is killing off processes in an attempt to free some memory. (and killing off your login shell, the pre-clear process, and probably your screen session too)

That was a bit confusing. That's why i asked about the cycles. Thanks Joe L. The four drives are now precleared. It took 25 - 30 hours to complete like you said. I changed that post to now say: 7. optionally repeats the process for additional cycles (if you specified the "-c NN" option, where NN = a number from 1 to 20, default is to run 1 cycle) hopefully, it is more clear.

If the disk were stable you would not see any additional un-readable sectors. I'd say at this point for ME to think of it as OK to use for anything critical it would have to pass several pre-clear cycles with NO change in un-readable sectors. It is entirely up to you. Do you feel lucky? Joe L.

Did i understand correctly that the post-reads step does 20 cycles? No, it does one cycle. However it can go up to 20 cycles if you use the -c NN option. (where NN is a number between 1 and 20)

It entirely depends on your hardware. Somewhere around 25 to 35 hours is normal for a single 2TB drive. See here in the wiki: http://lime-technology.com/wiki/index.php?title=User_Benchmarks#Preclear_Times If there are no bottlenecks in I/O to the drives, 4 concurrent pre-clears should not take a lot more time than one. But... if the disk controller waits on one for another, it could take longer.

The results of your pre-clear indicated that three of your sectors were not readable. The drive marked those as needing re-allocation, so when the drive was zeroed, they were re-allocated. That is good. If you had not performed the preclear, it is possible for a file or files to have been written that was not readable. Or, a file-system structure written that could not be read. Either of those could have resulted in lost files, or corrupted files. Now, do you trust the drive? It is a know fact that drives with re-allocated sectors are more likely yo have additional re-allocated sectors in the future. The question is, is the disk stable, or will additional sectors be un-readable when you start to use it. The only way to know is to either use it for real data, or run it through another preclear cycle. Joe L.

Looks pretty decent. There were 28 sectors realocated before yhou had performed the preclear. Three more were re-allocated during the pre-clear. I'd give it one more cycle. If additional sectors are re-allocated, then I'd not trust the drive for anything critical. If it remains at 31, you look good to go.

looks good to me.

It means it is time to RMA the drive.

media errors are unreadable sectors on the disk. they might be physically bad, or just written poorly. they are not a bad cable... those show as crc errors. (checksum errors)

Your syslog is filled with these "media errors" (unreadable sectors) The speed is slowed way down since unRAID is resetting the disk and trying again and again on each failure. ov 18 08:05:56 Tower kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Nov 18 08:05:56 Tower kernel: ata8.00: BMDMA stat 0x64 Nov 18 08:05:56 Tower kernel: ata8.00: failed command: READ DMA Nov 18 08:05:56 Tower kernel: ata8.00: cmd c8/00:08:b8:b8:dd/00:00:00:00:00/e7 tag 0 dma 4096 in Nov 18 08:05:56 Tower kernel: res 51/40:08:b8:b8:dd/40:00:07:00:00/e7 Emask 0x9 (media error) Nov 18 08:05:56 Tower kernel: ata8.00: status: { DRDY ERR } Nov 18 08:05:56 Tower kernel: ata8.00: error: { UNC } Nov 18 08:05:56 Tower kernel: ata8.00: configured for UDMA/33 Nov 18 08:05:56 Tower kernel: ata8: EH complete Nov 18 08:05:59 Tower kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Nov 18 08:05:59 Tower kernel: ata8.00: BMDMA stat 0x64 Nov 18 08:05:59 Tower kernel: ata8.00: failed command: READ DMA Nov 18 08:05:59 Tower kernel: ata8.00: cmd c8/00:08:b8:b8:dd/00:00:00:00:00/e7 tag 0 dma 4096 in Nov 18 08:05:59 Tower kernel: res 51/40:08:b8:b8:dd/40:00:07:00:00/e7 Emask 0x9 (media error) Nov 18 08:05:59 Tower kernel: ata8.00: status: { DRDY ERR } Nov 18 08:05:59 Tower kernel: ata8.00: error: { UNC } Nov 18 08:05:59 Tower kernel: ata8.00: configured for UDMA/33 Nov 18 08:05:59 Tower kernel: ata8: EH complete Nov 18 08:06:01 Tower kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Nov 18 08:06:01 Tower kernel: ata8.00: BMDMA stat 0x64 Nov 18 08:06:01 Tower kernel: ata8.00: failed command: READ DMA Nov 18 08:06:01 Tower kernel: ata8.00: cmd c8/00:08:b8:b8:dd/00:00:00:00:00/e7 tag 0 dma 4096 in Nov 18 08:06:01 Tower kernel: res 51/40:08:b8:b8:dd/40:00:07:00:00/e7 Emask 0x9 (media error) Nov 18 08:06:01 Tower kernel: ata8.00: status: { DRDY ERR } Nov 18 08:06:01 Tower kernel: ata8.00: error: { UNC } Nov 18 08:06:01 Tower kernel: ata8.00: configured for UDMA/33 Nov 18 08:06:01 Tower kernel: sd 5:0:0:0: [sdj] Unhandled sense code Nov 18 08:06:01 Tower kernel: sd 5:0:0:0: [sdj] Result: hostbyte=0x00 driverbyte=0x08 Nov 18 08:06:01 Tower kernel: sd 5:0:0:0: [sdj] Sense Key : 0x3 [current] [descriptor] Nov 18 08:06:01 Tower kernel: Descriptor sense data with sense descriptors (in hex): Nov 18 08:06:01 Tower kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Nov 18 08:06:01 Tower kernel: 07 dd b8 b8 Nov 18 08:06:01 Tower kernel: sd 5:0:0:0: [sdj] ASC=0x11 ASCQ=0x4 Nov 18 08:06:01 Tower kernel: sd 5:0:0:0: [sdj] CDB: cdb[0]=0x28: 28 00 07 dd b8 b8 00 00 08 00 Nov 18 08:06:01 Tower kernel: end_request: I/O error, dev sdj, sector 131971256 Nov 18 08:06:01 Tower kernel: Buffer I/O error on device sdj, logical block 16496407 Nov 18 08:06:01 Tower kernel: ata8: EH complete Nov 18 08:06:04 Tower kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Nov 18 08:06:04 Tower kernel: ata8.00: BMDMA stat 0x64 Nov 18 08:06:04 Tower kernel: ata8.00: failed command: READ DMA Nov 18 08:06:04 Tower kernel: ata8.00: cmd c8/00:08:c0:f5:dd/00:00:00:00:00/e7 tag 0 dma 4096 in Nov 18 08:06:04 Tower kernel: res 51/40:08:c0:f5:dd/40:00:07:00:00/e7 Emask 0x9 (media error)

It says the disk had been power cycled 8 times since it was manufactured. I'd be more concerned about the 7 times the disk heads retracted because power was suddenly lost. 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 7 Check your power connections.

Media errors are unreadable sectors. You should see a bunch of them pending re-allocation/re-allocated if you get a smart report now. Joe L..