I had forgotten more about this structure than I thought and should have
re-read the source. The inode number in question isn't the link between
the index and data file; it's between the top-level group.index file and
the index file for a specific group. It's still correct that it's used to
detect when the group has been expired so that the index can be remapped.
John Goerzen <jgoer...@complete.org> writes:
> This was running inside a Docker container. Initially I installed some
> things, then tar'd up /var/{lib,spool}/news in preparation for making them
> into Docker volumes. I did make the volumes, and unpacked the tarball
> over them. Was this coinciding with the log messages? That I don't know,
> but it's the most plausible explanation I have right now.
Oh, okay. Yeah, this is probably underdocumented, but if you move the
overview spool, you probably want to run tdx-util -A to check the results
and tdx-util -F to fix any problems. It will correct all of the inode
references.
> I'm sure this is right. I will note that people may like to be able to
> mount a ZFS snapshot -- which would certainly have a different st_dev or
> st_ino -- without 50,000 errors. But it may well be that I had
> forgotten this.
Different st_dev is fine. It would be nice if the snapshot preserved the
inode number, but I have no idea if it would.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
