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

From: Taylor Blau <me@ttaylorr.com>
Date: Jul 15, 2021, 16:42 UTC
Message-ID: <YPBlbNRoupMtT2dg@nand.local>
In-Reply-To: <ACFA1FCF-3F24-470D-A3AE-DBAA269E9E2C@163.com>

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