On Sun, Sep 05 2021, Russ Allbery wrote:
We could, but it does indicate an actual problem, so I'd love to
understand more about why this is happening. If ZFS does change
the
inodes on every reboot, another possible solution may be to
ensure that
expireover fixes the inode references (I'm not sure that it does
right now
in cases where it didn't need to change anything during
expiration), which
means the messages will only happen once after each reboot.
This has been nagging at me, and after giving it some more
thought, I am remembering something now -- the exact timing is
lost, and I apologize for not thinking of it before.
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. The volumes were on a different ZFS
dataset so that would certainly have different inode numbers.
Again, I apologize for not thinking of this before.
I assume ZFS can't be changing them constantly without a reboot
or a
remounting of the file system, since presumably that would break
lots of
other software.
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.
- John
