Thanks for the great answer Sitsofe :) Will stick to md5 verification while testing FS data integrity. Thanks Samuel On Sun, Apr 12, 2015 at 1:06 AM, Sitsofe Wheeler <sitsofe@xxxxxxxxx> wrote: > 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
