On Wed, Feb 24, 2021 at 04:41:26PM -0700, Andreas Dilger wrote: > Since you would know that the page is bad at this point (not uptodate, > does not contain valid data) you could potentially re-use some other
Oh, we don't know that. We know _a_ read has failed. There could be up to 128 blocks that comprise this (64kB) page, and we don't want to prevent reads to those other blocks in the page to fail unnecessarily. > fields in struct page, or potentially store something in the page itself? > That would avoid bloating struct page with fields that are only rarely > needed. Userspace shouldn't be able to read the page at that point if > it is not marked uptodate, but they could overwrite it, so you wouldn't > want to store any kind of complex data structure there, but you _could_ > store a magic, an error value, and a timeout, that are only valid if > !uptodate (cleared if the page were totally overwritten by userspace). > > Yes, it's nasty, but better than growing struct page, and better than > blocking userspace threads for tens of minutes when a block is bad. The current state blocks threads for tens of minutes. I'm proposing reducing it down to 30 seconds. I'd want to see a more concrete proposal than this ... (also, a per-page data structure might blow up nastily if the entire drive is inaccessible, rather than just a single bad block)
