On 4/3/20 2:16 PM, Qu Wenruo wrote:
OK, attempt number 2. Now this time, without zero writing. The workflow would look like: (raid5 example) - Partial stripe write triggered - Raid56 reads out all data stripe and parity stripe So far, the same routine as my previous purposal. - Re-calculate parity and compare. If matches, the full stripe is fine, continue partial stripe update routine. If not matches, block any further write on the full stripe, inform upper layer to start a scrub on the logical range of the full stripe. Wait for that scrub to finish, then continue partial stripe update.
As you wrote below for a full-stripe write, there is no problem at all. For a partial update, I think that together to the write request from the upper layer, it must passed the checksum (for the data) and the generation nr, parent... info (for the metadata). A page (4k) contains the checksum for 4096/32 = 125 blocks; if you cache these checksums likely you don't have to read a further page to perform a rmw cycle.
^^^ This part is the most complex part AFAIK. For full stripe update, we just update without any verification. Despite the complex in the repair routine, another problem is when we do partial stripe update on untouched range.
Due to the nature of a cow filesystem, each chunk can be divided in two consecutive area: the first is the "touched" data, the second the "untouched data". So may be tracking a pointer would be sufficient... But I think that it is a fragile assumption....
In that case, we will trigger a scrub for every new full stripe, and downgrade the performance heavily. Ideas on this crazy idea number 2? Thanks, Qu
GB -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
