|
|
Subscribe / Log in / New account

How to cope with hardware-poisoned page-cache pages

How to cope with hardware-poisoned page-cache pages

Posted May 6, 2022 5:51 UTC (Fri) by epa (subscriber, #39769)
Parent article: How to cope with hardware-poisoned page-cache pages

If a write-back page is poisoned, it shouldn’t be written to disk, corrupting the original file, but neither should it be thrown away. It should be saved somewhere so any useful data can be recovered. After all if some writes to a file succeed and some don’t because of poisoning, the file will be corrupt anyway. If it was important, you might want to apply part or all of the changes that were poisoned to a scratch copy of the file and manually compare them.

I guess in data centres full of ‘cattle’ nobody is going to manually fix up a disk image that was corrupted but for user data it seems the right thing to do. Like the old lost+found directory made by fsck.


to post comments

How to cope with hardware-poisoned page-cache pages

Posted May 6, 2022 8:56 UTC (Fri) by taladar (subscriber, #68407) [Link]

Maybe a user-space handler program similar to the coredump mechanism would be a good idea for this. Something that could compare the poison version of the page with the old file version and display the differences to the user for resolution.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds