Oleg Drokin wrote: > Whoops, nevermind, it seems blkdev_issue_flush after commit does the barrier, I see it now. > It's just rhel5 kernel that is affected. rhel5 necessarily lags upstream, but updates will come. We still need to do a lot of actual real-world testing of lost caches in -all- ext4 journaling modes, I think. -Eric > On Dec 11, 2009, at 1:45 AM, Oleg Drokin wrote: > >> Hello! >> >> I think ext4 ASYNC_COMMIT feature is potentially pretty unsafe >> when write-back cache is enabled on the device. >> Since no barriers are ever done with this feature even if >> the barriers are enabled, we might end up in the situation >> where we write the journal blocks, then commit block, they >> hit the device write-back cache, after that actual metadata >> blocks would be allowed to go to disk and eventually they will. >> >> In the end the device might decide to reorder some of the >> actual metadata updates in front of journal updates and >> if metadata updates will hit the disk and a power or other >> failure occurs after that, we have inconsistent filesystem >> as a result. >> >> I do not see an easy way to remedy the problem in this case >> other than to insert empty barrier after the commit block >> and wait for it completion, but I think that would negate >> the entire gain from this feature. I wish we actually had >> real ordered writes implemented, not just barrier/FUA >> sent to the device before every ordered buffer. >> >> Am I missing something? >> >> Thanks. >> >> Bye, >> Oleg > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
