On Sat, Sep 05, 2020 at 09:07:10PM +0900, Simon Walter wrote:
> On 9/5/20 3:34 PM, golinux@??? wrote:
> ...
> > Yes we do! I checked a log I had saved from before I did the e2fsck and
> > those values are identical to the post-e2fsck log.
>
> If they are identical, then it would seem that the fsck did not trigger the
> reallocation. However, what caused the corruption and what caused the
> reallocation *may* be something different. They may be two separate
> unrelated events. The runtime of the disk is low. So it is likely that it is
> the same event. The way to know would be to idenitfy that is if the sectors
> that were reallocated to are the same area where fsck found the corruption.
>
> That's just a bit too much to get into. I would only worry about it if the
> reallocated sector count keeps rising.
>
> For always connected disks, smartd is your friend.

In the old days, bad blocks were a matter for the file system to find
out about and avoid, by simply putting files elsewhere.

Nowadays the hardware replaces individual bad blocks without bothering
the file system.

This seems to say we now have two independent levels of bad block
checking.

When the low-level one fails, the other takes over. I't expect the
file system to be unlikely to see bad blocks until the drive is hosed.

-- hendrik
k