| *** tristan <tristan!tristan@223.62.204.133> has joined #buildstream | 02:59 | |
| *** ChanServ sets mode: +o tristan | 02:59 | |
| juergbi | nanonyme: the advantage of overlayfs on top of buildbox-fuse would be that only reads would be handled by buildbox-fuse and writes would be redirected to a regular filesystem (or tmpfs). avoiding the write performance hit of going through FUSE | 07:18 |
|---|---|---|
| nanonyme | Sounds definitely worth an experiment | 07:19 |
| juergbi | nanonyme: with setuid buildbox-casd, hardlink staging would be possible, avoiding the FUSE performance hit but making staging itself more expensive | 07:19 |
| nanonyme | But no more expensive than it was on bst1? | 07:20 |
| juergbi | no, would likely be similar | 07:21 |
| juergbi | there are various disadvantages of hardlink staging, though. no deterministic mtime, files cannot be modified. also e.g. chmod will fail on staged files. and the executable bit handling is problematic | 07:21 |
| nanonyme | So problematic for integration commands still | 07:22 |
| nanonyme | Okay, maybe it's not worth spending time on | 07:23 |
| juergbi | I'd rather not go down that path. overlayfs on top of (read-only) buildbox-fuse sounds pretty nice to me. reflinks would be another sensible option, if you can use a supported filesystem (although the staging performance is likely a bit worse than hardlinking) | 07:23 |
| juergbi | supporting reflinks in buildbox-casd would probably be fairly simple. but it only makes sense if is actually usable in CI | 07:25 |
| juergbi | implementing overlayfs support is not as simple (would have to think more about the details) | 07:26 |
| nanonyme | We suspect we could get XFS on x86_64 quite easily. Need to think about aarch64 and other runners | 07:41 |
| nanonyme | juergbi: why read-only buildbox-fuse? | 07:43 |
| juergbi | nanonyme: with overlayfs all writes would be redirected to the upper (regular filesystem or tmpfs) layer, effectively making the lower buildbox-fuse layer read-only | 07:44 |
| nanonyme | Oh yeah right | 07:44 |
| *** tristan <tristan!tristan@223.62.204.133> has quit IRC | 07:57 | |
| nanonyme | juergbi: how much work do you expect it to be to have a pilot on nested overlays? | 10:14 |
| juergbi | nanonyme: nested overlays as in one layer per dependency artifact? | 10:15 |
| nanonyme | Nested as in layer on top of buildbox-fuse | 10:15 |
| juergbi | ah ok. it might actually not be all that complicated but it's possible we would run into a blocker I haven't considered yet | 10:16 |
| juergbi | maybe I could take a quick stab at it next weekend | 10:17 |
| juergbi | the trickiest part is probably capturing the modified rootfs | 10:21 |
| *** tristan <tristan!tristan@223.62.162.207> has joined #buildstream | 13:16 | |
| *** ChanServ sets mode: +o tristan | 13:16 | |
| *** tristan <tristan!tristan@223.62.162.207> has quit IRC | 13:21 | |
| *** tristan <tristan!tristan@223.62.162.207> has joined #buildstream | 13:21 | |
| *** ChanServ sets mode: +o tristan | 13:21 | |
| *** tristan <tristan!tristan@223.62.162.207> has quit IRC | 13:36 | |
| nanonyme | juergbi: would it be part of buildbox-fuse or separate | 14:28 |
| juergbi | nanonyme: I'd expect it to be part of buildbox-run-bubblewrap | 14:29 |
| nanonyme | Ok | 14:29 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!