Replies: 3 comments 4 replies
-
Nope. It would always, I think, be some integer amount of records of whatever record size the file that was copied from was, but that might not be the same record size as the destination, since you're not trying to clone into that, so...practically you could probably often use that as a heuristic, but it's not an absolutely accurate thing. |
Beta Was this translation helpful? Give feedback.
-
Found https://github.com/0x5c/zfs-bclonecheck digging through the threads but haven't tried it yet. Needs an updated version of zdb to be able to dump the BRT. |
Beta Was this translation helpful? Give feedback.
-
Its worth noting that this should be a pretty difficult bug to hit. Just casually copying files is unlikely to trip anything. Its more likely when there's a lot of copying (cloning) and modification of the same files or clones of files in parallel. This is why we've only seen it in things like parallel build systems, and why its so difficult to reproduce reliably. If you're just copying existing files around at no great pace, you're probably fine. |
Beta Was this translation helpful? Give feedback.
-
Is there any script or other method that can detect files corrupted by the block cloning feature bug (#15526) in v2.2.0? Zpool scrubs do not appear to be able to catch this silent data corruption.
It looks like you'd need to search for blocks of zeroes, but I wasn't clear if there was any known signature (ex, always 32 blocks, etc) that would help in locating potentially damaged files.
Beta Was this translation helpful? Give feedback.
All reactions