-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable the cache updater when doing the encryption migration #14573
Conversation
Refer to this link for build results (access rights to CI server needed): |
very nice. Unfortunately @schiesbn is out the next few weeks. I don´t know who can test this. |
I can. I did the benchmark 😄 |
@@ -74,6 +75,7 @@ public function reorganizeSystemFolderStructure() { | |||
$this->view->deleteAll('/owncloud_private_key'); | |||
$this->view->deleteAll('/files_encryption/share-keys'); | |||
$this->view->deleteAll('/files_encryption/keyfiles'); | |||
$this->view->getMount('')->getStorage()->getScanner()->scan(''); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to only rescan the "files_encryption" folder, not everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see it's done below.
Do we really need to rescan the root ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way we clean up owncloud_private_key
and there isn't much more then encryption files in the root storage afaik
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this also automatically index all the home folders inside the "root" storage ?
Maybe better run the scan explicitly on "files_encryption" and "owncloud_private_key" (or tell the cache to directly remove the entry)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this also automatically index all the home folders inside the "root" storage ?
It might, will change it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was running the test before you change this, and can confirm that the scanner goes into the user folder, the backup folders, etc...
868d0f4
to
ef91c0c
Compare
This with the benchmark diff with this fix: https://blackfire.io/profiles/compare/889f482d-7902-46c6-ac1b-fc2d64e9b139/graph (but without the last change that prevents rescanning root) It's now faster. |
Can you add a unit test that tests whether disabling the file cache really disables it ? (no effect) |
Nice, this saves another minute. Here is the updated comparison: https://blackfire.io/profiles/compare/079d0fd6-fe33-447b-9869-4b1ff100d302/graph |
Done |
@icewind1991 here is the report: https://blackfire.io/profiles/6fe2f304-dbc1-48b8-9113-9c2e98350a9c/graph It seems the hooks code is triggered too. It would probably make sense to disable hooks too when working on encryption keys. What do you think of that "is_dir()" that is called 1260992 times ? |
Note that in my test case there is only one share key for each file, because I only have a single user. I also see here that keys are copied instead of moved here: https://github.com/owncloud/core/blob/master/apps/files_encryption/lib/migration.php#L264 Not sure why @schiesbn decided to copy, especially that we already have a backup of all keys in the backup folder. |
I'm ok to merge this PR first as it already provides an improvement 👍 |
Refer to this link for build results (access rights to CI server needed): |
@icewind1991 I'll have a try changing "copy" to "rename" and see if it improves. |
Wow, replacing "copy" with "rename" reduced from 4 minutes to 2 minutes. (just pushed) |
43252aa
to
22bc622
Compare
Rebased. @icewind1991 can you thumbs up my commit and show enthusiasm about the last performance report ? 😛 I'll do some more testing, we need to make sure trashbin keys also still work. |
Tests
|
Nice job @icewind1991 @PVince81 !!! |
Something went wrong with the trashbin (it was a shared file that I deleted), but I suspect it's not related to this PR. Will check. |
|
Bääh... it's a bug in stable7, will raise separately. |
The trashbin bug about sharing is only in stable7 but not master, will need to find the PR that fixes it. But I can say that one user was able to restore the file from trashbin when not shared, so it works. If we all agree on the code changes I can submit a Jenkins PR ? |
@th3fallen can you review, too ? |
Raised trashbin issue here, it's stable7 only: #14588 |
The inspection completed: 1 new issues, 5 updated code elements |
|
👍 |
👍 for @PVince81's changes |
@owncloud-bot retest this please |
Refer to this link for build results (access rights to CI server needed): |
Disable the cache updater when doing the encryption migration
@karlitschek Backport to stable8 for 8.0.2 ? |
Note, this is "only" a performance improvement, so the question is whether it's acceptable to have slow OC7->OC8.0.2 encryption migration. |
Well - the user experience was pretty bad on this - we had user where the migration command was running over night. It would have been nice to have this fixed for 8.0.1 (especially because of EE release). We at least need a PR against stable8 to allow everybody to patch their installations is necessary. Long story short: please prepare a PR against stable8 - THX |
stable8: #14669 |
For #14012
Brings the time to do the migration in the unit tests down to <2s from ~11s on my local machine
cc @PVince81 @DeepDiver1975 @schiesbn