| nanonyme | Jürg Billeter: I reworded the case to be about supporting C++17. We got grpc build with C++14 so the original issue is kind of invalid. | 18:24 |
|---|---|---|
| nanonyme | (as the original assumption was new grpc could not be used with buildbox at all, this was incorrect) | 18:25 |
| nanonyme | Jürg Billeter: actually I was supposed to ask you: how does buildbox-fuse talk to buildbox-casd? Or does it? If it does, does it use grpc? | 19:14 |
| JrgBilleter[m] | <nanonyme> "Jürg Billeter: actually I was..." <- As it's normally used right now, buildbox-fuse doesn't talk to buildbox-casd at all. buildbox-fuse has support for downloading from a CAS server (which could be buildbox-casd or any remote CAS server), either on startup or on demand, however, that's not used when buildbox-fuse is spawned by buildbox-casd. | 19:50 |
| nanonyme | I see. So how does the staging mechanism actually work? | 19:51 |
| nanonyme | I assume there are no actual copies, it's too fast for that | 19:52 |
| JrgBilleter[m] | buildbox-casd passed the path to its storage directory to buildbox-fuse | 19:52 |
| JrgBilleter[m] | I.e., they use the same directory layout. buildbox-casd ensures that all objects are available before starting buildbox-fuse | 19:53 |
| JrgBilleter[m] | s/passed/passes/ | 19:53 |
| nanonyme | Ok. So it's really just more or less direct file access with no IPC or whatever. | 19:56 |
| JrgBilleter[m] | Yes, the main overhead comes from the FUSE interface itself. Zero-copy is used but there is still some overhead, e.g., context switching. buildbox-fuse also has to read the Directory protobuf messages but that overhead should typically be fairly small. | 20:02 |
| JrgBilleter[m] | Capturing (at the end) is handled by buildbox-casd and involves checksumming and copying, optimized away when unmodified files are captured. | 20:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!