I have a HDD 4TB WD 40EFRX (red series) and try to check the health of that disc. Actually, I erased all partitions and the table via gparted and build a new table + ex4 partition. Subsequently, I wanted to overwrite all the data with zeroes in order to get rid of old data. However, I figured out that using

dd if=/dev/zero of=/dev/sdb status=progress

result in an I/O error right at the beginning:

sudo dd if=/dev/zero of=/dev/sdb status=progress
474558976 bytes (475 MB, 453 MiB) copied, 38.0445 s, 12.5 MB/s
dd: writing to '/dev/sdb': Input/output error
927977+0 records in
927976+0 records out
475123712 bytes (475 MB, 453 MiB) copied, 46.6914 s, 10.2 MB/s

while adding the option bs=64MB (cache of that HDD is 64 MB) the command works really fine. However, I guess based on the IO error the HDD is somehow dead or can I do other workarounds too? By the way, I have the HDD via SATA/USB connected to my laptop.

  • 1
    Does the error always occur at the same address? – Hauke Laging Dec 30 '17 at 13:44
  • @HaukeLaging, hmm, you're right, I didn't read the sample output very well, it seems. – ilkkachu Dec 30 '17 at 13:54
  • I do also wonder what happens if the drive is plugged directly to a computer. With a USB adapter in the middle, it could be another source of issues. – ilkkachu Dec 30 '17 at 13:55
  • @ilkkachu you are right but I have no other possibility right now. My desktop PC is 500 km far away. HaukeLaging I will check it out. Right now another HDD (same type) is running but the error occured always very rapidly (lets say after a few seconds so I guess it could be the same sample always). – Tobi Dec 30 '17 at 14:17
  • 2
    Use smartctl -a /dev/sdb to see what the disk thinks of its own fail state, and then run a -t short or -t long test too. – meuh Dec 30 '17 at 14:55

I admit that I have neither encountered nor heard about the following problem but on the other hand I am not an harddisk failure expert... :-)

The pure amount of I/O operations might somehow cause the problem. Between the two kinds of dd calls is the factor 128,000 in the number of read and write operations. I do not know whether the Linux block layer somehow reorders direct accesses to a block device. If it does then this factor would be lower.

You may try smaller block sizes. bs=512KB would be a reduction by a factor of 1024. Perhaps you find that even a block size much smaller that the cache size makes the problem disappear.

|improve this answer|||||
  • If I do not set a block size, which one is used as default one? As I said, if I put an blocksize such as bs=64MB, dd works fine (at least for the first hour). If I do use bb without the block size specification, it fails - always but only with one of the two HDD. So, how could I be sure the HDD is still okay.? Right now, I am using 512KB and it works fine till now too. Thanks for your reply. By the way is it normal that the transfer (write) rate starts with 130MB/s and falls to 20 MB/s and goes back to 75 MB/s. – Tobi Dec 30 '17 at 14:48
  • @Tobi As ilkkachu alreasy wrote: The default block size of dd is 512 bytes. – Hauke Laging Dec 30 '17 at 14:50
  • @Tobi I am not familiar with the progression of transfer speeds but I assume that in the beginning the empty disk cache helps a lot. When the cache is filled up then it is probably partly flushed which stalls the I/O operations which arrive during that time. After the partly flush an equilibrium is reached, I guess, which is between the highest and lowest transfer rate. – Hauke Laging Dec 30 '17 at 14:56
  • sorry, I did not see that ilkkachu said that the default value is 512 bytes. The speedup explanation seems to be fine for me. Thanks for the reply. I checked the disc with smartclt and it seems there is a problem (comment above) – Tobi Dec 30 '17 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.