Build is green

the return value of mmap is -1 on error, not NULL

There is an error on mmap which was not detected, therefore no information on why it failed. This was fixed.

• time tox -e py3 -- --basetemp=/mnt/pytest -s --shard-size $((100 * 1024)) --object-max-size $((4 * 1024)) -k test_build_speed number of objects = 45973118 baseline 163.73826217651367, write_duration 300.58917450904846, build_duration 26.01908826828003, total_duration 326.6082627773285

Build is green

return on error if the write method exceeds the file capacity

Running benchmarks directly on grid5000

• oarsub -I -l "{cluster='dahu'}/host=1,walltime=1" -t deploy
• kadeploy3 -f $OAR_NODE_FILE -e debian11-x64-base -k
• ssh root@$(tail -1 $OAR_NODE_FILE)
• mkfs.ext4 /dev/sdb1
• mount /dev/sdb1 /mnt
• apt-get install -y python3-venv libcmph-dev gcc git
• git clone https://git.easter-eggs.org/biceps/swh-perfecthash/
• python3 -m venv bench
• source bench/bin/activate
• pip install -r requirements.txt -r requirements-test.txt
• cd swh-perfecthash
• tox -e py3
• time tox -e py3 -- --basetemp=/mnt/pytest -s --shard-size $((100 * 1024)) --object-max-size $((100 * 1024)) -k test_build_speed
• rm -fr /mnt/pytest

/opt/jFed/jFed-Experimenter works but I'll have to wait on the approval of the account before proceeding further.

Created a project in https://portal.fed4fire.eu/ with the intention of using grid5000. It is pending approval from an administrator (see T3670).

After a fight with zookeeper the new broker is nowfully functional on storage1.
It seems the zookeeper content was not synchronized between the 2 nodes. It was solved by stopping everything and copying the content of '/var/lib/zookeeper' to the second server. For example the credentials were not present on the second zookeeper.
After the battle, I realized I should have dig deeper to find the reason but I try to react fast to reduce the risk of corruption.

This is a duplicate of T3634

The draft implementation is available publicly at https://git.easter-eggs.org/biceps/swh-perfecthash/-/tree/wip-hash while D6424 is under review.

The implementation of the benchmarks is prepared at:

For the record I created a "draft" repository for contributions to https://forge.softwareheritage.org/source/swh-perfecthash/ at https://git.easter-eggs.org/biceps/swh-perfecthash. It is only meant to be a publicly available sandbox.

"rebase"

lgtm

lgtm

In T3627#72544, @douardda wrote:

B3 I am not convinced a "synthetic" flag on the Snapshot branch makes sense, or at least I find this name confusing, especially considering we already have a synthetic flag on Revision: it's not synthetic in the sense of it's not object crafted by SWH, it comes from the origin.

Build is now green again [1] [2]

Remove the journal0 alias for vagrant

indeed ;)
Thanks.

actually, before it starts leaking RAM, the Java process only uses 10% of the memory, so there is room to start a few more.

Looks good to me, plus it aligns the tests with production settings.

Done

this is old. I think this is resolved..
@ardumont , @anlambert ?

Build was aborted

Both build are now fixed.

@anlambert here is another task to improve the deposit moderation/admin view

@anlambert here is the task we have briefly discussed as step 2 this morning

rebase

https://docs.softwareheritage.org/devel/contributing/tutorial-docs-contribution.html#doc-contribution