What would cause tripwire to find 11000 files changed only in block count?

Question

Looking at recent tripwire runs, one night about a week ago, tripwire suddenly detected 11042 changed files that all changed only in block count, not in size, CRC32, MD5, inode, or anything else. All the files that changed this way that I checked in the tripwire log are eight blocks bigger. If I ignore the files that changed only in block count, all other changes are expected changes that I know I made, or expected changes like log files changing.

For context, this server failed abruptly on June 19th, so I replaced the motherboard but kept the disks. (The disks are all much newer than the motherboard was.) This system is on Fedora 23. The tripwire run at 3am Jun 20th didn't find any such differences. On June 20 I opened the computer again to replace a network card that wasn't working after the motherboard change. The tripwire run at 3am Jun 21 is the first one to detect all the files with a changed block count.

rkhunter didn't complain about anything, for what it's worth.

Given that for the files in question, absolutely nothing has changed except block count, and that all types of objects got 8 blocks bigger (files, directories, even symbolic links), I'm reasonably sure that this is not hacking. But I'm not confident that it's benign. How can a symbolic link go from 0 to 8 blocks? But everything seems to be working just fine.

What could cause this? Should I worry? My most recent full backup (rsync to external drive) was made the evening of the 20th, so most likely after whatever changed here. None of the changed files are in /boot or /home or /var (all of which are separate file systems for what it's worth). In fact, only files on / have changed in this fashion. The / filesystem is a raid mirror, if that matters.