- 13 Mar, 2019 5 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 12 Mar, 2019 15 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 11 Mar, 2019 4 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
- 08 Mar, 2019 7 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
-
Kirill Smelkov authored
If we keep it activated, there could be a problem at Resync time - if Resync sees that old zhead.At is outside of DB.δtail coverage it will invalidate all zhead.cache objects, not only changed objects. That means that even non-changed and being kept active ZBigFile will be invalidated and oops - PInvalidate will panic. We could avoid it via deactivating all ZBigFiles on each transaction update, but that can be too expensive if there are many ZBigFiles. We could avoid the problem another way - add to ZODB/go API to request that DB.δtail covers particular connection. That in turn would mean we have to also extend ZODB/go API to release connection from affecting DB via such constraint. Even if first step could be done via e.g. another flag, the second step - release - is not very clear - we already have connection "release" on transaction completion and adding e.g. conn.Close() in addition to that would be ambiguous for users. Also, if wcfs is slow to process invalidations for some reason, such constraint would mean DB.δtail would ↑ indefinitely. -> we can solve the problem in another way: don't keep ZBigFile always activated and just do activation/deactivation as if working with ZODB objects regularly. This does not add any complications to code flow and from the performance point of view we can practically avoid the slowdown by teaching zodbCacheControl to also pin ZBigFile in live cache.
-
Kirill Smelkov authored
-
- 07 Mar, 2019 1 commit
-
-
Kirill Smelkov authored
-
- 06 Mar, 2019 1 commit
-
-
Kirill Smelkov authored
-
- 05 Mar, 2019 1 commit
-
-
Kirill Smelkov authored
-
- 04 Mar, 2019 3 commits
-
-
Kirill Smelkov authored
-
Kirill Smelkov authored
If we don't early-disable it, we can see a situation where when handling invalidations wcfs calls open("@revX/bigfile/...") to upload cache data there, go runtime tries to use epoll on that fd, and it gets stuck as described in the commit referenced in comments. In particular the deadlock was easy to trigger with nproc=1 environment (either a VM with 1 cpu, or e.g. under `taskset -c 0`) Bug reported by @romain.
-
Kirill Smelkov authored
-
- 01 Mar, 2019 1 commit
-
-
Kirill Smelkov authored
-
- 28 Feb, 2019 1 commit
-
-
Kirill Smelkov authored
* master: t/qemu-runlinux: Mount bpf and fusectl filesystems t/qemu-runlinux: Issue terminal resize before running program t/qemu-runlinux: Don't propagate $TERM in graphics mode
-
- 27 Feb, 2019 1 commit
-
-
Kirill Smelkov authored
bpf is needed for tools like bpftrace. fusectl is needed to observe things like /sys/fs/fuse/connections/X/waiting.
-