Ну и вкратце реальный источник ошибки - успехов местным васянам найти его "git blame" - как найдете, свистните. Тут в freebsd 12 очень нужно (к ней не подойдет 15571).При копировании файла большинство реализаций cp (а заодно tar и дофига кто еще) используют специфический метод для обнаружения в нем дыр и создания вместо нулей нераспределенных блоков которые копировать или сохранять незачем. Это НЕ чтение и сравнение с нулем, такое бы сработало как надо, но читать пару гигабайт ничего чтобы убедиться что там нули - немного глупо, и у большинства fs есть для этого отдельная фича в lseek.
Вот в ее реализации - обмишулились чуток. Да, во времена иллюмоса еще. Или даже швятога sun - но это неточно. И если дергать SEEK_HOLE на файле половина которого еще висит где-то в кэшах и не долетела до диска - можно ненароком найти несуществующую. (так что таки привет hole_(re)birth - реинкарнировалась десять лет спустя, падла)
Т.е, существующие данные потерять таким образом _нельзя_, повреждена будет только копия. Чтобы получить такую поврежденную копию - нужно скопировать файл ДВАЖДЫ - второй раз - сделав копию копии, причем достаточно быстро чтобы вторая копия еще не успела до конца дописаться - тогда третья оказывается несовпадающей.
Рефлинки никак с этим не связаны. Если там и есть баг - он отдельный.
Нули необязательны как признак поврежденного файла - может точно так же неправильно сработать и SEEK_DATA (т.е. наоборот - вместо законных нулей получить билиберды)
dmu_offset_next_sync связана только тем, что это оказалось вредное "улучшение", не улучшавшее как думали, а ухудшавшее производительность при множественной параллельной записи (т.е. просто оставляло больше шансов на возникновение race, но он таки возникает и при 0, просто надо сильнее грузить систему)
Сборка игого попала под раздачу именно потому что без конца копирует одни и те же файлы, их много, и параллельная сборка сильно грузит fs, игого и рач не виноваты, странно но тоже факт.
