Running e2fsck with the '-c' option causes e2fsck to run the "badblocks" command to detect the bad blocks, and to automatically mark them as unusable.
All modern disk drives (=manufactured in 1990s or later) have built-in bad block detection in the hardware, at the disk mechanism/firmware level. The disk has a number of spare blocks: it transparently redirects any I/O that would access the bad blocks to these replacement blocks.
If e2fsck/badblocks can detect any bad blocks on the disk, that means the disk's built-in bad block mechanism has already detected and corrected as many bad blocks as it can, and is unable to fix any more. So it's an indication that there is already fairly severe damage on the disk.
Running e2fsck -cy might be acceptable as a *short-term workaround only* to allow backing up the latest data, or if the server is in a distant location where the disk cannot be replaced without a significant delay.
But you should definitely treat the disk as *unreliable* from now on: make extra sure all important software, data and configuration information is backed up and that the backups are usable.
The only real fix for the problem is to replace the disk.
(NOTE: in some special cases a diagnostic program published by the disk manufacturer can fix some types of errors. These fixes are usually disk model specific and suggest that the disk may have known hardware/firmware bugs: check if the manufacturer has published disk firmware upgrades in this case.)
For the "dd" command: if you don't specify the "count=" parameter at all, the command will automatically process the entire source disk. If the dd command can be run into completion without any new disk errors appearing into the system logs (see the "dmesg" command and the log files in /var/log), the disk has no bad blocks that would be visible to the filesystem level.
The bs= parameter should be set to a value that is a multiple of the actual block size of the disk. A larger value will allow dd to request blocks from the disk in larger chunks, which may speed the process.
If the actual size of the disk is not an exact multiple of the bs= value, the dd command will report one incomplete block at the end. This is not a problem.
The output of the dd command should look like:
12345678+0 records in
12345678+0 records out
if the disk size was an exact multiple of the bs= value, and
12345678+1 records in
12345679+0 records out
if it wasn't. (12345678+1 means "12345678 complete blocks of size bs= and one incomplete block", and dd will automatically pad it with zeroes when outputting, creating one extra full block.)
MK
MK
