Thread (31 messages) flat view 31 messages, 7 authors, 2021-08-15

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

From: Sun Chao <hidden>
Date: 2021-07-15 16:50:13

2021年7月16日 00:42,Taylor Blau [off-list ref] 写道:

On Fri, Jul 16, 2021 at 12:30:18AM +0800, Sun Chao wrote:
quoted
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 :-).
quoted
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
Oh, Maybe I didn't understand caching well enough, let me check it again,
and thanks for your and Ævar's answers, they are really helpful.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help