Build is green
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 19 2021
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).
Oct 18 2021
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"
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