On Wed, Sep 20, 2017 at 3:28 AM, Coly Li <colyli@xxxxxxx> 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 filesystem data is cached. E.g. the data structures representing what space is free on disk, or a directory, or a database btree. Some examples: Free space handling-- if a big file /foo is created, and the active free-space datastructures are in cache (and this is likely, because actively written places can have their writeback-writes cancelled/deferred indefinitely)-- and then later the caching disk fails, an old version of this will be read from disk. Later, an effort to write a file /bar allocates the space used by /foo, and writes over it. Directory entity handling-- if /var/spool/foo is an active directory (associated data structures in cache), and has the directory /var/spool/foo/bar under it, and then /bar is removed... the backing disk will still have a reference to bar. If the space for bar is then used for something else, the kernel may end up reading something very different from what it expects for a directory later after a cache device failure. Btrees, etc-- the same thing. If a tree shrinks, old tree entitys can end up pointing to other kinds of data. I think this change is harmful-- it is not a good idea to automatically, at runtime, decide to start returning data that violates the guarantees a block device is supposed to obey about ordering and persistence. Mike
