John Goerzen <jgoer...@complete.org> writes: > Hi Russ! It is good to visit with you again. Thanks for what you do > with inn.
Julien does most of the work, but thank you! > So I should mention why I switched. I was getting lines like this in the > news.daily report: > innd: tradindexed: index inode mismatch for local.test > ... > expireover: tradindexed: index inode mismatch for control > expireover: tradindexed: index inode mismatch for control.cancel > expireover: tradindexed: index inode mismatch for > control.checkgroups > ... > I am running inn2 inside a Docker container atop zfs. I believe inodes > should be internally consistent (eg, tar can properly detect hardlinkes) > but due to the bind mount (and possibility of running atop a zfs clone > or whatnot), I suspect -- but have not verified -- that at least st_dev > if not st_ino also (from stat(2)) are not guaranteed to be consistent > across restarts. I'd guess the most common reason for that would be > st_dev changes due to the bind mount that Docker does. However, looking > at the code, I don't think it uses st_dev, so perhaps st_ino is also not > stable across restarts. (conjecture at this point) Yeah, it only uses st_ino because it assumed that (a) st_ino would be stable, and (b) the data file and index file would always be on the same device. I think (b) is correct, but it sounds like (a) may not be correct. FWIW, tradindexed uses that inode number as an optimization. When expireover rewrites the data file, it does so in a way that changes the inode number (and updates that field in the index file), which communicates to any other process such as running nnrpd instances with open maps that the data file has changed and should be re-opened to pick up the new data file. Therefore, these error messages shouldn't result in any incorrect behavior (I think); it will just make things slower because the data file may be re-opened unnecessarily even when it hasn't changed. I'm surprised that a file system doesn't maintain stable st_ino values. That seems vaguely broken to me, but I'm not sure if anything guarantees that behavior. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
