On Fri, Jul 16, 2021 at 12:30:18AM +0800, Sun Chao wrote:
> I'm sorry to reply so late, I work long hours during the day, and the
> company network can not send external mail, so I can only go home late
> at night to reply to you.
There's no need to apologize :-).
> Thanks for your reply again, My explaination for 'why the mtime is so
> important' lost some informations and it is not clear enough, I will
> tell the details here:
Let me see if I can summarize here. Basically:
- You have a number of servers that have NFS mounts which hold large
repositories with packs in excess of 10 GB in size.
- You have a lot of clients that are fetching, and a smaller number of
clients that are pushing, some of which happen to freshen the mtimes
of the packs.
...and the mtimes being updated cause the disk cache to be invalidated?
It's the last part that is so surprising to me. Ævar and I discussed
earlier in the thread that their understanding was that you had a backup
system which had to resynchronize an unchanged file because its metadata
had changed.
But this is different than that. If I understand what you're saying
correctly, then you're saying that the disk caches themselves are
invalidated by changing the mtime.
That is highly surprising to me, since the block cache should only be
invalidated if the *blocks* change, not metadata in the inode. It would
be good to confirm that this is actually what's happening.
Thanks,
Taylor
