On Fri, 27 Oct 2017, Michael Lyle wrote: > On Fri, Oct 27, 2017 at 2:13 PM, Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx> wrote: > [snip] > >> > Can KEY_DIRTY facilitate this? > >> > >> Don't we only have the metadata to know if the key is dirty on the > >> cache if we have the cache device? ;) > > > > Certainly if this is for removal or a missing cache (perhaps I missed > > that). > > > > However, I thought this was just a recovery on an IO error where the disk > > might be mostly dead--but partly alive! > > > > Of course if the metadata lookup fails subsequently, then you would need > > to fall back to the dc->has_dirty flag. > > Seems like something that's a lot of effort for little gain. It'll > only help when A) everything you need isn't dirty, and Indeed! > B) all the associated btree nodes are in memory. Is the dirty key map not memory resident? > Since bcache tries to keep 10% dirty by default, and it's likely to be > heavy on filesystem metadata-- I don't know how often this would help > anyone in the real world. Perhaps not---but if it is easy to implement, then this would provide the most optimistic recovery. -- Eric Wheeler > > Mike > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >