On 2017/7/12 上午10:01, tang.junhui@xxxxxxxxxx wrote: >>I meant "it is very necessary for data base applications which always >>use *writeback* mode and not switch to other mode during all their >>online time." ^_^ > > I know, it is necessary, but not enough. who can promise they will not > switch during online time? This patch is logical imperfectly. Yes, I agree with you. Since Eric mentions dirty data map, an improved fix shows up in my head, When cache device disconnected from system, 0) If in non mode, do nothing. 1) If in writeback/writethough/writearound mode, and dirty map is clean, - switch to non mode - continue to handle I/O without cache device 2) If in writeback mode, and dirty map is not clean, - return -EIO immediately for WRITE request - return -EIO immediately for READ request (*) 3) If not in writeback mode, and dirty map is not clean. It means the cache mode is switched from writeback mode with dirty data lost, then - returns -EIO immediately for WRITE request - returns -EIO immediately for READ request (*) (*) NOTE: A sysfs entry "recovery_io_error" can be add here, which is disabled as default. If it is enabled, if a READ request does not hit dirty map, bcache will provide it from backing device. By the above method, if no dirty data lost and cache device disconnected, bcache steps back to non mode. If we have dirty data lost, always returns -EIO to notify application to handle the failure as soon as possible. And there will be a little more failure tolerance if "recovery_io_error" is enabled. Eric, Junhui, How do you think about the above idea ? Thanks in advance for your comments. Coly -- 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
