Skip to content

Conversation

@dcantah
Copy link
Collaborator

@dcantah dcantah commented Jan 23, 2021

…n the final snapshot

For LCOW currently we copy (or create) the scratch.vhdx for every single snapshot
so there ends up being a sandbox.vhdx in every directory seemingly unnecessarily. With the default scratch
size of 20GB the size on disk is about 17MB so there's a 17MB overhead per layer plus the time to copy the
file with every snapshot. Only the final sandbox.vhdx is actually used so this would be a nice little
optimization.

For WCOW we essentially do the exact same except copy the blank vhdx from the base layer.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
(cherry picked from commit a91c298)
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Currently we would create a new disk and mount this into the LCOW UVM for every container but there
are certain scenarios where we'd rather just mount a single disk and then have every container share this one
storage space instead of every container having it's own xGB of space to play around with.

This is accomplished by just making a symlink to the disk that we'd like to share and then
using ref counting later on down the stack in hcsshim if we see that we've already mounted this
disk.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
(cherry picked from commit 3e5acb9)
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
@dcantah
Copy link
Collaborator Author

dcantah commented Jan 23, 2021

@dcantah
Copy link
Collaborator Author

dcantah commented Jan 23, 2021

Not sure if this should be against master and we'd pull it in from there afterwards or just against our release branch like here

@dcantah dcantah changed the title Cherry pick snapshot Cherry pick LCOW snapshot work Jan 26, 2021
@katiewasnothere
Copy link
Collaborator

Not sure if this should be against master and we'd pull it in from there afterwards or just against our release branch like here

@dcantah From what Kevin has described before:

Basically, fork/master is the main development branch. Work unique to our fork goes directly into it, and it should occasionally merge in upstream master.
...
Once a fork/release/xx branch is created, we should never merge master or fork/master into it. The only changes it should take are things that are merged from release/xx, or cherry-picks of specific changes we want to make that we can't get backported upstream.
...
For now we can cherry-pick features to fork/release/1.4

Copy link
Collaborator

@katiewasnothere katiewasnothere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dcantah dcantah merged commit e8cf51e into kevpar:fork/release/1.4 Jan 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants