sped up sim step by about 200%

Noticed that it was quite slow compared with things like action
sendwanted. Guessed that the slowdown is largely due to every step
doing a simulated git pull/push.

So, rather than always doing a pull/push, only do those when no actions
are found without doing a pull/push.

This does mean that step will sometimes experience a split brain
situation, but that seems like a good thing? Because step ought to
explore as many possible scenarios as it reasonably can.

added sim of sizebalanced in a splitbrain situation

allow complex shell commands

fix sizebalanced empty size bug

Fix bug that prevented anything being stored in an empty repository whose
preferred content expression uses sizebalanced.

adds sims collection

sim visit as first-class command

Allows using it in a sim file.

sim: Fix size tracking for balanced preferred content

update

sim: fix state loss bug

puzzling bug

invalidate caches after log changes

This seems like something Annex.Sim would need to happen. And generally
a really good idea.

avoid adding redundant present/notpresent to sim history

bugfixes

sim stabilization works now

sim: better step

On each step, find all the actions that could be done, and pick one of them
to do.

Should detect stability, but that is broken.

set simRootDirectory on restore

It's a relative directory and the cwd may be different. Or the repo
could have been moved.

remove sim log file

update

update

update

sim: implement addtree

sim: tested concurrency over actions

This demonstrates concurrent behavior that looks right. And with a
random seed, the results are deterministic.

init foo
init bar
init backup
connect foo <-> bar
connect foo <-> backup
addmulti 10 testfiles 1mb 1gb foo backup
action foo gitpull backup
wanted foo nothing
wanted bar anything
wanted backup anything
action bar gitpull foo
action foo dropunwanted while action bar getwanted foo

sim: fix get bug

When getting from a remote, have to check that the repo doing the
getting thinks the remote contains the key, but also that the remote
actually does. Before this bug fix, it would get from a repo that used
to have the key, but that had dropped it since the last git pull.

record initial seed in sim log

Unless the log starts with a command that records a seed.

git-annex sim log

sim: implement dropunwantedfrom

fix ActionDropUnwanted

Now tested working

sim: add missing parser for action sendwanted

sim: fix changing settings bug

addmulti

move pull/push/sync into getSimActionComponents

As well as being a more pleasing implementation than I managed
yesterday, this allows for those actions to be run concurrently in the
sim.

sim concurrency

add

implement ActionPull/Pull/Sync

Somewhat unsatisfying implementation, but all the alternatives were
worse.

sim: add action repo sync command

sim command fixes

git-annex sim command is working

Had to add Read instances to Key and NumCopies and some other similar
types. I only expect to use those in serializing a sim. Of course, this
risks that implementation changes break reading old data. For a sim,
that would not be a big problem.

implemented ActionDropUnwanted

Not tested yet. This emulates the same checking that is done when
dropping. Note that when dropping from a special remote it is not able
to make a locked copy.

convert simRepoState to use UUID as key

fully preserve input format of connect and disconnect commands

Just lifted the sim file as a DSL into the type level for that.

sim file parser and generator

The generator doesn't emit the best possible connect commands,
but it does output something valid. Eg, an input like:

connect A <-> B <-> C <-> D

becomes:

connect A <-> B <-> C
connect C <-> D

Also:

connect A -> B <- C

becomes:

connect A -> B
connect C -> B

Which could be improved.

Also disconnect commands are not prettified at all, but probably there's
no reason to.

started on sim file parser

implemented ActionSendWanted

The simulation is nearly finished. Only CommandAddTree and dropping
remain to do.

ActionGetWanted working

The sim is now basically working!

sim: implement ActionGitPush and ActionGitPull

These don't actually need to do any git actions, instead they just merge
the simLocations.

Had to make simLocations use a vector clock, because it is possible for
two simulated repositories to end up with different opinions about the
location of a key. Just like with real git-annex, whichever location
change was made most recently wins out.

The vector clock is simply advanced each time the simulation is run for
a step. Since there is no real parallelism in the sim, that's
sufficient.

implement randomAction

implement CommandStep

and record each SimCommand in simHistory, except for CommandStep where
instead the actions that are generated are recorded.

add action command to git-annex sim

step just picks a random action, and this allows finer control over what
happens in the sim

set location logs in simulated repos

fix removing simulated file

create simulated files

set descriptions for all simulated repos

simulated repository construction working

finish updateSimRepoState

Converted maps to use UUID as key.

Also added mincopies to the sim.

maxsize of 0 to disable

implemented cloneSimRepo

Started on updateSimRepoState

more work on applySimCommand

When using an existing repo, copy over all of its config into the sim.

Added CommandTrustLevel.

Start at creating a git clone for a simulated repo, but it's not done
yet.

rethought sim a bit

prevent overwriting a repo in the simulation

almost finished with applySimCommand

Added checks that repo names are ones that have been added to the sim.

Implemented preferred content etc setting. It does not need to parse the
expression in applySimCommand, instead that can be done when running the
sim. This keeps it pure.

But, it can't be entirely pure because of CommandAddTree. So made it
return an Annex action when necessary.

Moved makeMatcher into Annex.FileMatcher in preparation for using it,
but it's not used yet. Also moved checkPreferredContentExpression.

implement CommandUse in Annex.Sim

Refactored Remote to keep it pure.

started Annex.Sim

Have most of the sim command handler, but to keep it pure while implementing
the rest will need some refactoring.

It seems likely that running the simulation itself will not be able to be
entirely pure. Preferred content evaluation runs in Annex after all.

Note that the somewhat awkward randomWords is because the i386ancient
build depends on a version of random too old to support generating a
random ByteString on its own.

documentation for git-annex sim

command not implemented yet

update

sim design

correct comment

This is not related to v5 versus newer versions.

fix typo

treat "not present" in preferred content as invalid

Detect when a preferred content expression contains "not present", which
would lead to repeatedly getting and then dropping files, and make it never
match. This also applies to "not balanced" and "not sizebalanced".

--explain will tell the user when this happens

Note that getMatcher calls matchMrun' and does not check for unstable
negated limits. While there is no --present anyway, if there was,
it would not make sense for --not --present to complain about
instability and fail to match.

Fix --debug display of onlyingroup preferred content expression.

update

2 level toc

Merge branch 'master' of ssh://git-annex.branchable.com

fix number of headers

add news item for git-annex 10.20240831

releasing package git-annex version 10.20240831

use Utility.PID

fixes build on i386ancient

fix liveupdate locking

This fixes the build on windows.

Changed it to use lock pools, which will behave better if two threads
call getLiveRepoSizes at the same time.

Also this should make it work when annex.pidlock is set. In that case,
once the current process locks this file, or anything, any other process
will have to wait on the pid lock. So checkStaleSizeChanges will
correctly identify any other live changes in the database as stale,
since there can only be one git-annex process running.

fix paste oops

Wow, I pasted a big thing into entirely the wrong file, but it was in a
comment so it compiled anyway.

mention sizebalanced as well as balanced

avoid locking the journal in readonly repository

The test suite flagged that git-annex info in a readonly repository was
no longer working.

.git/annex/journal.lck: openFd: permission denied

This fixes it, however, in a case where .git/annex/reposize/ is
writable, but .git/annex/journal/ is not, there will still be a
permission denied error. The solution would just be to use consistent
permissions I suppose.

update

document using balanced preferred content in a cluster

Merge branch 'master' into balanced

lookupkey: Allow using --ref in a bare repository.

Added a comment

err on the side of larger repository size

When a live update is removing a key, it might fail. So only count those
once they have succeeded. When a live update is adding a key, count it
immediately to avoid over-filling a repo.

This also makes the 1 minute delay between stale live changes checks
more defensible, because a stale live change can only cause us to err
more on the side of caution.

remove stale live changes from reposize database

Reorganized the reposize database directory, and split up a column.

checkStaleSizeChanges needs to run before needLiveUpdate,
otherwise the process won't be holding a lock on its pid file, and
another process could go in and expire the live update it records. It
just so happens that they do get called in the correct order, since
checking balanced preferred content calls getLiveRepoSizes before
needLiveUpdate.

The 1 minute delay between checks is arbitrary, but will avoid excess
work. The downside of it is that, if a process is dropping a file and
gets interrupted, for 1 minute another process can expect a repository
will soon be smaller than it is. And so a process might send data to a
repository when a file is not really going to be dropped from it. But
note that can already happen if a drop takes some time in eg locking and
then fails. So it seems possible that live updates should only be
allowed to increase, rather than decrease the size of a repository.

combine 2 queries

avoid reposize database locking overhead when not needed

Only when the preferred content expression being matched uses balanced
preferred content is this overhead needed.

It might be possible to eliminate the locking entirely. Eg, check the
live changes before and after the action and re-run if they are not
stable. For now, this is good enough, it avoids existing preferred
content getting slow. If balanced preferred content turns out to be too
slow to check, that could be tried later.

Added a comment

Added a comment: Needed to retrieve single file metadata from bare repo

Added a comment

fix a deadlock when not using --auto

Live update never gets started, but then it still waited for it to
finish.

This only deadlocked with -J4 or so, not without -J. Unsure why.

avoid nub

There will not usually be many live changes, but usually does not mean
ever, and O(N^2) is best avoided.

thoughts

locking in checkLiveUpdate

This makes sure that two threads don't check balanced preferred content at the
same time, so each thread always sees a consistent picture of what is
happening.

This does add a fairly expensive file level lock to every check of
preferred content, in commands that use prepareLiveUpdate. It would
be good to only do that when live updates are actually needed, eg when
the preferred content expression uses balanced preferred content.

closing in on finishing live reposizes

Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.

Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.

The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.

The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.

use live reposizes in balanced preferred content

fixed the build

Manually tested getLiveRepoSizes and it is working correctly.