On 2017/9/20 下午5:40, Michael Lyle wrote:
> On Wed, Sep 20, 2017 at 3:28 AM, Coly Li wrote:
>> Even the read request failed on file system meta data, because finally a
>> stale data will be provided to kernel file system code, it is probably
>> file system won't complain as well.
>
> The scary cas
On 2017/9/20 下午6:07, Kent Overstreet wrote:
> On Wed, Sep 20, 2017 at 06:24:33AM +0800, Coly Li wrote:
>> 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 devi
On Wed, Sep 20, 2017 at 06:24:33AM +0800, Coly Li wrote:
> 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
On Wed, Sep 20, 2017 at 3:28 AM, Coly Li wrote:
> Even the read request failed on file system meta data, because finally a
> stale data will be provided to kernel file system code, it is probably
> file system won't complain as well.
The scary case is when filesystem data that points to other fil
On 2017/9/20 上午8:59, Michael Lyle wrote:
> Coly--
>
> It's an interesting changeset.
Hi Mike,
Yes it's interesting :-) It fixes a silent database data corruption in
our product kernel. The most dangerous point is, it happens silent even
in-data checksum is used, this issue is detected by out-of-
Coly--
It's an interesting changeset.
I am not positive if it will work in practice-- the most likely
objects to be cached are filesystem metadata. Won't most filesystems
fall apart if some of their data structures revert back to an earlier
point of time?
Mike
On Tue, Sep 19, 2017 at 3:24 PM,
