Skip to content

Commit

Permalink
virtualization: add new builtin command to print hydration level (#659)
Browse files Browse the repository at this point in the history
GVFS users can easily (and accidentally) over-hydrate their enlistments.
This causes some commands to be very slow.

Create a command to print the current hydration level. This should help
our support team investigate the state of their enlistment.

This command will print something like:

```
% git virtualization
Skipped: 2
Hydrated: 3
Total: 5
Hydration: 60.00%
```

and log those values to Trace2 in a `data_json` record of the form:

```
{"skipped":2,"hydrated":3,"total":5,"hydration":60.00}
```
  • Loading branch information
dscho authored Jun 25, 2024
2 parents 78b268c + e774223 commit 7975c98
Show file tree
Hide file tree
Showing 3 changed files with 42 additions and 5 deletions.
2 changes: 1 addition & 1 deletion .github/workflows/scalar-functional-tests.yml
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ jobs:
fail-fast: false
matrix:
# Order by runtime (in descending order)
os: [windows-2019, macos-11, ubuntu-20.04, ubuntu-22.04]
os: [windows-2019, macos-13, ubuntu-20.04, ubuntu-22.04]
# Scalar.NET used to be tested using `features: [false, experimental]`
# But currently, Scalar/C ignores `feature.scalar` altogether, so let's
# save some electrons and run only one of them...
Expand Down
2 changes: 2 additions & 0 deletions t/t1093-virtualfilesystem.sh
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,8 @@ test_expect_success 'verify status is clean' '
git status > actual &&
cat > expected <<-\EOF &&
On branch main
You are in a partially-hydrated checkout with 75% of tracked files present.
nothing to commit, working tree clean
EOF
test_cmp expected actual
Expand Down
43 changes: 39 additions & 4 deletions wt-status.c
Original file line number Diff line number Diff line change
Expand Up @@ -1604,10 +1604,15 @@ static void show_sparse_checkout_in_use(struct wt_status *s,
{
if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_DISABLED)
return;
if (core_virtualfilesystem)
return;

if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_SPARSE_INDEX)
if (core_virtualfilesystem) {
if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_SPARSE_INDEX)
status_printf_ln(s, color,
_("You are in a partially-hydrated checkout with a sparse index."));
else
status_printf_ln(s, color,
_("You are in a partially-hydrated checkout with %d%% of tracked files present."),
s->state.sparse_checkout_percentage);
} else if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_SPARSE_INDEX)
status_printf_ln(s, color, _("You are in a sparse checkout."));
else
status_printf_ln(s, color,
Expand Down Expand Up @@ -2560,6 +2565,36 @@ void wt_status_print(struct wt_status *s)
s->untracked.nr);
trace2_data_intmax("status", s->repo, "count/ignored", s->ignored.nr);

switch (s->state.sparse_checkout_percentage) {
case SPARSE_CHECKOUT_DISABLED:
break;
case SPARSE_CHECKOUT_SPARSE_INDEX:
/*
* Log just the observed size of the sparse-index.
*
* When sparse-index is enabled we can have
* sparse-directory entries in addition to individual
* sparse-file entries, so we don't know the complete
* size of the index. And we do not want to force
* expand it just to emit some telemetry data. So we
* cannot report a percentage for the space savings.
*
* It is possible that if the telemetry data is
* aggregated, someone will have a good estimate for
* the size of a fully populated index and can compute
* a percentage after the fact.
*/
trace2_data_intmax("status", s->repo,
"sparse-index/size",
s->repo->index->cache_nr);
break;
default:
trace2_data_intmax("status", s->repo,
"sparse-checkout/percentage",
s->state.sparse_checkout_percentage);
break;
}

trace2_region_enter("status", "print", s->repo);

switch (s->status_format) {
Expand Down

0 comments on commit 7975c98

Please sign in to comment.