I may get your point, and answer is replay guard ensure clone_range not do again, so this problem will not happen. 2017-03-11 5:24 GMT+08:00 Gregory Farnum <gfarnum@xxxxxxxxxx>: > On Fri, Mar 3, 2017 at 3:08 AM, Wangwenfeng <wang.wenfeng@xxxxxxx> wrote: >> Hi, all >> I have a trouble with in EC overwrite. In the function ‘generate_transactions’, using the clone_range to prepare the rollback data of EC overwrite. The clone_range is clone NO_GEN data to version data, and the new date will write after it. >> If a transaction contain the clone_range and write, and it has submit to journal, now is applying to data disk. >> If the Host power off suddenly, the transaction has apply to data, but the journal not know this. When the Host power on, maybe journal will replay the transaction which contain clone_range and write date to data disk. If this happen, the second clone_range’ data is error, it is the write data. >> The rollback to the object will cause the data error. >> Would you explain this will happen or not? And the rollback to object will cause the data error or not? > > I don't understand the problem you're describing. If we replay the > journal, it will clone_range from the original (i.e., untouched) data > and just redo all the work. Where does cloning the wrong thing come > in? > (You can come up with more complicated scenarios that involve > overwriting the data we originally cloned from, but that is all > protected by versions we store in the filesystem that let us detect > these scenarios and account for them.) > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" 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 ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
