Что заставит tripwire найти 11000 файлов, измененных только в количестве блоков?

Глядя на последние запуски tripwire, однажды ночью, около недели назад, tripwire неожиданно обнаружил 11042 измененных файла, которые изменились только по количеству блоков, а не по размеру, CRC32, MD5, inode или чему-либо еще. Все файлы, которые были изменены таким образом, что я проверил в журнале tripwire, на восемь блоков больше. Если я игнорирую файлы, которые изменились только в количестве блоков, все остальные изменения - это ожидаемые изменения, которые, как я знаю, я сделал, или ожидаемые изменения, такие как изменение файлов журнала.

Для контекста, этот сервер внезапно вышел из строя 19 июня, поэтому я заменил материнскую плату, но сохранил диски. (Все диски намного новее, чем была на материнской плате.) Эта система установлена ​​на Fedora 23. Во время запуска tripwire в 3 часа ночи 20 июня таких различий не было. 20 июня я снова открыл компьютер, чтобы заменить сетевую карту, которая не работала после замены материнской платы. Tripwire, запущенный в 3 часа ночи 21 июня, первым обнаруживает все файлы с измененным количеством блоков.

rkhunter ни на что не жаловался, ни на что это стоит.

Учитывая, что для рассматриваемых файлов абсолютно ничего не изменилось, кроме количества блоков, и что все типы объектов получили 8 блоков больше (файлы, каталоги, даже символические ссылки), я вполне уверен, что это не взлом. Но я не уверен, что это доброкачественно. Как символическая ссылка может идти от 0 до 8 блоков? Но, кажется, все работает просто отлично.

Что может вызвать это? Должен ли я беспокоиться? Мое последнее полное резервное копирование (rsync на внешний диск) было сделано вечером 20-го, поэтому, скорее всего, после того, что что-то здесь изменилось. Ни один из измененных файлов не находится в /boot или /home или /var (все они являются отдельными файловыми системами, чего бы это ни стоило). Фактически, только файлы на / изменились таким образом. Файловая система / - это рейдовое зеркало, если это имеет значение.