My 8TB Western Digital HDD is showing errors in SMART id 197: Current Pending Sector Count. (Value=416, normalized=100). How can I reduce this?
(The SMART fields are readable in e.g. Ubuntu live CDs as well as openmediavault's web UI)
edit: After searching SE and finding nothing, my 5th Google led here, which could be useful: How to force a remap of sectors reported in S.M.A.R.T C5 (Current Pending Sector Count)?
Easiest is to use a tool was designed for this purpose, for example Victoria for Windows:
Note that you should consider replacing the drive in case of a significant amount of pending / reallocated sectors. I personally advise doing so even before the normalized SMART thresholds are reached. At a minimum you want to run a regular surface scan and keep a close eye on relevant SMART attributes.
As reported by other sources, the drive needs to try to write to that area of the disk.
edit: Best tool is seachest/openseachest lite.
NB: This could be a warning sign of a drive failure (it's classified by Ubuntu and others as "old-age" and not "pre-fail", however).
I'm using this in a NAS drive as part of my primary backup strategy, so I wanted to be absolutely sure that this drive is reliable. I backed up needed files and emptied out the drive for further testing (in case it failed the tests and files became unrecoverable).
You're fixing SMART errors, so take a photo etc. of what the SMART status is. In my case, I have errors in 0x197 and 0x198. My goal is to see 0x197 go down (to zero?) by writing every byte of the disk, thus triggering the drive to mark each sector as good or bad.
fsckI used ubuntu live 24.04. I started the gui Disks app to determine the /dev/sdX/ location of the drive.
sudo fsck -yfv /dev/sdX1
y: for some filesystem-specific checkers, the -y option will cause the fs-specific fsck to always attempt to fix any detected filesystem corruption automatically. Sometimes an expert may be able to do better driving the fsck manually. Note that not all filesystem-specific checkers implement this option. In particular fsck.minix(8) and fsck.cramfs(8) do not support the -y option as of this writing.
f: Force checking even if the file system seems clean.
v: Verbose mode.
I got:
Inode 18 extent tree (at level 2) could be narrower. Optimize? yes [from -y]
[snip]
/lost+found not found. Create? yes
Mount the drive (I used Ubuntu Disks).
# cding to the path makes the dd command simpler
cd /path/to/drive
dd if=/dev/zero bs=8M count=$((1*1024*1024)) | dd of=emptyfile.bin bs=8M
dd = copy a file
dev/zero = empty bytes
bs = block size (allegedly fastest, per SE; but this is drive and phase of moon specific, feel free to do your own tests)
count = 1 TB
of = filename
bs = block size
I monitored that the transfer was working through System Monitor and listening to HDD sounds of the computer. You could probably use iotop on the terminal. I got 80+ MBps which is only a bit below the 100-150 I might see on a good day. It's fast enough for me to not try to fix it.
This is theoretical for me so far. After filling the disk (7.9 TB total, 7.5 TB used, 0 bytes free) I see the same results.
At some point, I got 0x05 Reallocated Sector Count up to 1 from 0. Ubuntu Disks shows 417 bad sectors but the pending sector count is 416.
I've tried a SMART self test (quick) but haven't noticed any changes.
I originally filled 7 of the 8 terabytes without fsck. But I kept getting no space left on device. Fsck allowed me to continue. This drive was pulled from an OpenMediaVault 5.x install and it's possible that the extant tree error started there.
https://serverfault.com/questions/786648/when-is-fsck-dangerous
Difference between S.M.A.R.T. error 0x05 (Reallocated sector) and 0xC6 (Uncorrectable sector)