Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> Most importantly: once the trimtester (or *any* "corruption detecting" > tool) claims that a certain corruption is found, you look at what supposedly is > corrupt, and double check if it in fact is. > > Before doing anything else. > I did that, but I don't know what a "good" file is supposed to look like, so I can't tell whether it is really corrupted. The last time TrimTester reported a corrupt file, I checked it manually and it looked fine to me, but I don't know what I'm looking for. For it to be reported as corrupted by trimester, it would need to contain at least one aligned 512 byte sector full of zeroes. Did it? Did it contain even two zero bytes next to each other? Or simply the same 256 byte cyclic pattern that is written by this tool? If so, then obviously the tool in error claimed to find a corruption that clearly was not there. Feel free to keep using that tool, but fix it first, change the unsigned i and j to size_t or uint64_t. And maybe have it really check all files, before removing them. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20171017/e176d7b0/attachment.htm>