You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When @ericzty demoed try installing rust at the recent pash retreat, try was fast but the summary was painfully slow and very noisy. The problem is in the summary() routine.
We should not be slow or noisy.
Less noise
If a directory is new, just give its name, the number of files under it, and the total space consumed. A user can use try explore to see details if they care.
If a whole subtree is deleted, just give its name, the number of files under it, and the total space taken up by the files deleted.
Give full detail on everything else.
Less slowness
There are three key stages in summarizing:
The call to find in find_upperdir_changes
The diffing with the root filesystem in process_changes
The reporting in summary
I suspect the diffing and reporting are the slow part. (Being less noisy means less printing, which of course means less slowness. Still waters run fast.) But we should profile this and find out. It may be necessary to replace process_changes with a short C program.
The text was updated successfully, but these errors were encountered:
This should be relatively easy to achieve with fts, which we can use in the following way:
fts_open the upperdir
Walk through, comparing against the lowerdir. (Cf. overlayfs-tools traverse function.)
a. On a new directory in the upperdir, use fts_children to compute # of files and their total disk usage.
b. On a whiteout of what was a directory in the lowerdir, a separate call to fts_open on the lowerdir (or simply calling out to du) will tell else how many files were deleted.
Generate the summary and---if requested---a shell script that does the merge. Then the commit routine can just directly call this script.
When @ericzty demoed
try
installing rust at the recent pash retreat, try was fast but the summary was painfully slow and very noisy. The problem is in thesummary()
routine.We should not be slow or noisy.
Less noise
try explore
to see details if they care.Less slowness
There are three key stages in summarizing:
find
infind_upperdir_changes
process_changes
summary
I suspect the diffing and reporting are the slow part. (Being less noisy means less printing, which of course means less slowness. Still waters run fast.) But we should profile this and find out. It may be necessary to replace
process_changes
with a short C program.The text was updated successfully, but these errors were encountered: