Runtime filesystem consistency checking [LWN.net]

Runtime filesystem consistency checking

Posted Apr 13, 2012 10:33 UTC (Fri) by etienne (guest, #25256)
In reply to: Runtime filesystem consistency checking by nye
Parent article: Runtime filesystem consistency checking

> every couple of months scrub detects checksum errors in a block or a small handful of blocks, without any corresponding read/write errors being given by the device.

I am not sure to interpret exactly what is happening on my own PC, but I suspect something like:
- one block of sectors develop a bit fault in the magnetic data
- the ECC correct it each times the PC reads the sector resulting in a *very long* delay of few seconds
- the Linux driver do not noticed there was long ECC correction and do not decide to rewrite the sector identically to get the magnetic data corrected
- long term a second error will appear on the magnetic data and the ECC will no more be sufficient.

I do not know why the sector is not rewritten by the Linux driver, I know that I did solve same problem on another PC by touching a file in a directory, forcing the sector containing the directory entry to be rewritten.
I never noticed the problem when the "old" ATA/IDE driver was used, but I am not sure I interpret correctly what happens on my PC during the last few days...

to post comments

Runtime filesystem consistency checking

Posted Apr 13, 2012 12:34 UTC (Fri) by james (guest, #1325) [Link]

I understand that these days, it's the disk firmware's job to do this. It knows that there's a read error (which Linux doesn't, although it can sometimes guess ¹); it knows that sector is dodgy (which Linux doesn't, because it doesn't get told when the hardware remaps sectors), it can try re-writing the sector, and if that fails, it can remap in a spare sector (which Linux can't do, because it doesn't have access to the disk's spare sectors) if (and only if) it knows what that sector's contents should be, either because it's managed to read something, or the computer is overwriting that sector.

And it can do all of that without having to worry about which operating system is running, or it's a database using raw access, or if it's a light layer using BIOS calls but no filesystem. It can preserve this information across reformats.

In your case, by causing the sector containing the directory entry to be rewritten, the disk probably decided that this was a great time to remap in a spare sector, so it actually went to a different part of the disk. (Unless the filesystem you were using put the new directory entry somewhere else anyway.)

And ECC correction doesn't take seconds; re-reading the same sector repeatedly in the hope that you can get a last good read does.

¹ If you've got command queueing turned on, several requests outstanding, and there's a delay, which sector caused the problem?

Runtime filesystem consistency checking

Posted Apr 13, 2012 14:51 UTC (Fri) by jzbiciak (guest, #5246) [Link]

Adding to what James said above me, I think you might want to look into installing the SMART tools to query your drive. The "smartctl" tool will read out and display the various statistics the drive's been collecting about corrected errors and remapped sectors.

It will also let you fire up background health checks (these can take quite a long time to complete -- as long as a day, as I recall) that may help turn up other problems.