<davidlt[m]>
I am not ready to read those in the morning, need ☕️
<davidlt[m]>
Jeff Law email is also something
<Entei[m]>
Do only koji builders have to be running on native architecture (for the arch they are building)? Everything else like the kojihub, psql db stay on a foreign arch?
<davidlt[m]>
Yeah, only builders need to have target arch.
<davidlt[m]>
Infrastructure bits can be on any arch.
<davidlt[m]>
Our infra runs on aarch64.
<Entei[m]>
I see. That seems like a great way to scale up builders
<davidlt[m]>
To scale just add more builders + might need to tweak infra to handle more load.
<Entei[m]>
So where does the directory /mnt/koji stay? I am confused as to where things are being built where the repository is being maintained
<davidlt[m]>
We have it as "local drive" on the main server, but in real life (with a lot of action) that NFS server + mount on the main server.
<davidlt[m]>
That holds all the logs, RPMs, temporary koji repos, etc.
<davidlt[m]>
kojira is in charge of cleaning those up (default is 2 weeks IIRC)
<davidlt[m]>
These are Koji internal (think working) repos, not the final user repos. Those have different COMPS setttings.
<davidlt[m]>
In Fedora/RISCV I have a repo file to allow folks to pull directly from Koji repos (faster for testing).
<Entei[m]>
So say I have my host (x86_64) with kojihub, psql, kojira and the big drive to store RPMs. Then I start instances of QEMU to run as builders. Then those builders are downloading packages from the main server over internet. Is that correct?
<davidlt[m]>
Yeah
<davidlt[m]>
We pushed petabytes of data :)
<Entei[m]>
davidlt[m]: Wow. We might not have that big of disk. What would be a realistic disk size for me (including qemu instances that would also need some)
<davidlt[m]>
Well, I would advice not running QEMU builders on the main server.
<davidlt[m]>
I would strongly advice only using NVMe drives, no spinning rust.
<davidlt[m]>
We right now are probably at 6-7 TBs after many years.
<davidlt[m]>
Just put a 2TB NVMe drive which are cheap these days and you should be good to go.
<davidlt[m]>
But in general more is better.
<davidlt[m]>
Why? Well, depending on your configuration it's easy to eat a few 100GBs a day!
<Entei[m]>
Yeah the recommendation for NFS drive is making sense to me now.
<davidlt[m]>
Like all those tiny repositories that are kept for 2 weeks or so take space. The faster you build, the more import as-is (e.g. noarch packages) and do not disable kojira you will create tons of small incremental repos.
<davidlt[m]>
I think Fedora itself is something 70-80TBs.
<davidlt[m]>
But that's long term.
<davidlt[m]>
So again, a lot will depend on your configuration. You might have tons of short-lived data.
<davidlt[m]>
You don't want to be harsh on configuration too. E.g. if you send too much data the repository assigned to the task might vanish before the tasks start building.
<davidlt[m]>
Or if you want to debug a build locally the repository used for the build might be already gone.
<davidlt[m]>
So something like 10-14 days is really very minimal for riscv64 these days.
<davidlt[m]>
Also these days we use Btrfs. I have a compression enabled, which works very nicely for the logs.
<davidlt[m]>
It also makes it easier to make snapshots (readonly) and to make backups.
<davidlt[m]>
Way nicer than LVM + XFS.
<davidlt[m]>
If you can make sure you have some redundancy or/and backup if you want to avoid loosing data.
<Entei[m]>
Yeah the server is running Fedora with BTRFS, so that should be good to go.
<davidlt[m]>
Don't worry too much, expect that things will not go as you expect :)
<conchuod>
davidlt[m]: Hopefully they do not use opensbi code, and implement SBI themselves. RustSBI feels a wee bit on the "two men in a shed" side
<davidlt[m]>
It sounds that they plan to implement SBI.
<conchuod>
I strongly dislike that OpenSBI is the defacto SBI implementation & others are rarely considered
<davidlt[m]>
OpeSBI is now under RVI IIUC. Most development, experimentation, spec discussion happens there.
<davidlt[m]>
I don't know if anyone is posting spec drafts for comments in other implementations mailing lists.
<conchuod>
It is fine for it to be the *reference* implementation, but we need other "first class" SBI implementations too so that developers do not operate under the assumption that SBI == OpenSBI
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
fuwei has quit [Remote host closed the connection]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
fuwei has joined #fedora-riscv
unlord has quit [Server closed connection]
unlord has joined #fedora-riscv
zsun has joined #fedora-riscv
<davidlt[m]>
Pioneer idles at ~116W right now.
<davidlt[m]>
EVB idles at ~half of that.
<davidlt[m]>
This will not be that great for electricity bill :D
jednorozec has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
<conchuod>
Do you invoice $dayjob for that!
<davidlt[m]>
I wonder if their NVMe timeout issues are related (somehow) to ASMedia PCIe switch overheating.
<conchuod>
davidlt[m]: I need to convince RVI that I need one
<davidlt[m]>
64-core system?
jednorozec has joined #fedora-riscv
jednorozec_ has joined #fedora-riscv
jednorozec has quit [Remote host closed the connection]
jednorozec_ is now known as jednorozec
<conchuod>
Ye
<davidlt[m]>
That should not be a difficult task given how much work you do on the kernel side.
jcajka has quit [Quit: Leaving]
<conchuod>
davidlt[m]: Do you have one of them? If so, cat /proc/cpuinfo please :)
zsun has quit [Quit: Leaving.]
<davidlt[m]>
I don't have one. fuwei could you share cpuinfo on pastebin?
<davidlt[m]>
I also asked folks on MilkV matrix space.
<conchuod>
👍
<davidlt[m]>
Pioneer issues are actually tracked on GH issues in public (all in Chinese).