Hello Nix, Thursday, January 25, 2018, 9:57:25 PM, you wrote: > On 25 Jan 2018, Pavel Goran told this: >> Hello Nix, >> >> Thursday, January 25, 2018, 1:23:19 AM, you wrote: >> >>> This feels wrong to me. If a cache device is writethrough, the cache is >>> a pure optimization: having such a device fail should not lead to I/O >>> failures of any sort, but should only flip the cache device to 'none' so >>> that writes to the backing store simply don't get cached any more. >> >>> Anything else leads to a reliability reduction, since in the end cache >>> devices *will* fail. >> >> It's one of those choices: "if something can't work as intended, should it be >> allowed to work at all?" > Given that the only difference between a bcache with a writearound cache > and a bcache with no cache is performance... is it really ever going to > beneficial to users to have a working system suddenly start throwing > write errors and probably become instantly nonfunctional because a > cache device has worn out, when it is perfectly possible to just > automatically dissociate the failed cache and slow down a bit? > I would suggest that no user would ever want the former behaviour, since > it amounts to behaviour that worsens a slight slowdown into a complete > cessation of service (in effect, an infinite "slowdown"). Is it better > to have a system working correctly but more slowly than before, or one > that without warning stops working entirely? Is this really even in > question?! Well, there is the "Fail-Fast" principle [1] and all that. For a home user (which is my case, for example), this approach doesn't make much sense. However, large-scale users, like cloud providers, can have a different point of view. It's just a speculation on my part, but consider a bunch of bcache devices that serve as parts of a RAID6 array. It may be desirable to deactivate the bcache device that lost its caching capabilities, so that (1) the array would not slow down, (2) the array would report its degraded state to administrators. Anyway, probably the author of this patch could explain it better. Maybe I completely misunderstand the intention. Pavel Goran [1] https://en.wikipedia.org/wiki/Fail-fast -- 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
