Subject: Re: [PATCH v2] packfile: freshen the mtime of packfile by configuration

From: Taylor Blau <[email-masked]>
Date: Thu, 15 Jul 2021 12:42:20 -0400

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