On 9 Sep 2017, Coly Li spake thusly: > When bcache does read I/Os, for example in writeback or writethrough mode, > if a read request on cache device is failed, bcache will try to recovery > the request by reading from cached device. If the data on cached device is > not synced with cache device, then requester will get a staled data. > > For critical storage system like database, recovery from staled data may > result an application level data corruption, which is unacceptible. But > for some other situation like multi-media stream cache, continuous service > may be more important and it is acceptible to fetch a staled chunk of data. > > This patch tries to solve the above conflict by adding a sysfs option > /sys/block/bcache<idx>/bcache/recovery_from_staled_data > which is defaultly cleared (to 0) as disabled. Now people can make choices > for different situations. 'Staled' is not a word, though perhaps it should be. You probably want to call it recovery_from_stale_data. But given the description below... > With this patch, for a failed read request in writeback or writethrough > mode, recovery a recoverable read request only happens in one of the > following conditions, > - dc->has_dirty is zero. It means all data on cache device is synced to > cached device, the recoveried data is up-to-date. > - dc->has_dirty is non-zero, and dc->recovery_from_staled_data is set > to 1. It means there is dirty data not synced to cached device yet, but > option recovery_from_staled_data is set, receiving staled data is > explicitly acceptible for requester. ... this name is also unclear. It sounded to me like it was an option that recovers *from* stale data (as if the stale data was a problem to recover from), not an option that uses stale data to *allow* recovery. Perhaps, instead, something like stale_data_permitted or allow_stale_data_on_failure would be better? -- NULL && (void) -- 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
