From 17a31f8e1bcf7812c753922fbbe1e9fc5710d671 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 1 Oct 2021 11:49:12 -0400 Subject: [PATCH] analysis --- ..._43f5ed4a319fcf63387395f32a345852._comment | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment diff --git a/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment new file mode 100644 index 0000000000..eaf370fd6e --- /dev/null +++ b/doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment @@ -0,0 +1,38 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 10""" + date="2021-10-01T14:57:11Z" + content=""" +The second hash is done by isUnmodifiedLowLevel, and +is indeed done because the inode cache does not verify. + +The inode cache does not verify because for some reason, +it does not have any inode cached for the object file +when that is called. + +The reason this only happens in sync and not get is that sync also sends +files it received to other remotes, and to do that it needs to check if +their content is present. Which is normally inexpensive, so not a problem. + +It so happens that sync calls inAnnex even when +there are no other remotes to send the content to. Which is unncessary, and +avoiding that could be used to fix this problem. But there would still be a +problem if there were some other remote that the content ought to be sent to, +if it still called inAnnex in that case. Maybe it's possible to avoid it calling +inAnnex at all though, since it knows when it's gotten the content. + +The inode cache gets written to the database before sync calls +inAnnex. And queued writes get flushed to the database before reading +from it. I've confirmed all this is happening. +So why does getting the inode cache from the db not see the previously +written data? + +I suspect this is where NTFS enters the picture. Perhaps +something about it is causing changes to the sqlite database to not +be visible immediately to a reader. Might involve whatever locking +sqlite is or is not able to do on NTFS, or something like that. + +(Interestingly, at the end of the sync, the smudge clean filter +gets called, and it is able to read the inode cache from the db +at that point. So another process run just a bit later can see the data.) +"""]] -- 2.30.2