On 11 April 2015 at 17:48, Samuel Shapiro <samuel.sh79@xxxxxxxxx> wrote: > Thanks Sitsofe, > It make sense, if previous block meta isn't really saved.... > So maybe the right question to ask, in which scenarios should I prefer > "meta" verification method over "md5" etc...? Without looking at the source I would guess they will catch different issues and have different overheads. For example, if I use md5 I write a header to each "block" that tells me what the data should be. When it comes to verification time I read the header and check the body matches the checksum. Reading the body and calculating the checksum take time and CPU. If the error is that two blocks of the same size (including their headers) have been switched I won't catch that because the checksum of the body is still correct with respect to the header (this is speculation on my part)... If I use meta my header contains things like timestamp, block number, io sequence number. I don't need to spend time verifying the body and unless I used verify_pattern I don't even know what the correct data in the body would look like if I were to check/checksum it. I can detect identically sized block swaps because the block number and io sequence number in the header will be wrong. If a problem is detected I've got a better chance of working out where the problem header came from (because more meta data is available to me). If I'm using same sized blocks and I'm worried about entire block swaps or I want to do a minimal a check as possible I think you could use meta. If I'm more worried about sub block sized data being wrong I would say you are better off with one of the checksum routines (preferably one that is hardware accelerated). If I'm overwriting my data within the same pass and I probably can't use meta any more. meta may give me more information about where bad data came from if the header is intact and I know how to decode it. However, this is all speculation on my part! -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
