summaryrefslogtreecommitdiff
path: root/src/rmd_cache.c
AgeCommit message (Collapse)Author
2021-02-12cache: _rmdCacheFileClose should always NULL handlesVito Caputo
The existing code would leave the internal handle non-NULL when the underlying close failed. In the event of a transparent close when chapters switch failing, a subsequent explicit close is expected, and the handles must be NULLed out for that explicit close to not blow up because fclose() leaves the handle undefined after errors. It's basically a use after free bug.
2020-11-09cache: overload syncer thread to also pre-allocateVito Caputo
This changes the syncer thread to always be created for writers, and makes it posix_fallocate() the cache file to the maximum size. When the syncer is disabled w/ms=0, it simply returns after the posix_fallocate. posix_fallocate errors are ignored, this is simply an opportunistic optimization. I have some concern about the glibc emulation mentioned in the man page, but writers are opened O_WRONLY which the notes say cause the emulation to fail with EBADF which is preferable, and I'm using O_WRONLY for the writers.
2020-11-09cache: introduce "syncer" thread for cache writersVito Caputo
This adds a new flag: --periodic-datasync-ms with a default of 100ms. When a new CacheFile is created for writing, and the datasync period is non-zero, a thread is created for the sole purpose of calling fdatasync() on the underlying fd in a loop separated by sleeps of the specified duration. The purpose of this is to prevent a large backlog of dirty buffers from accumulating until the operating system's normal background dirty sync kicks in. Depending on how the underlying filesystem and storage stack is configured, these bulk writebacks can result in very long stalls on a subsequent write operation. This is easily observed on ext4+lvm+dmcrypt setups, even using a simple test like `dd if=/dev/urandom of=testfile bs=8M`. Despite having plenty of available buffers, once ext4's internal journal fills while a bulk writeback is underway, dd's progress will completely stall until the entire writeback is completed, usually it's in the jbd2 wchan of do_get_write_access(). When this occurs during a recording by recordMyDesktop, the result is dropping frames for the entire duration of the stall. One thing recordMyDesktop could do to insulate from this is perform its own buffering of sampled frames at the YUV stage, with the cache writer consuming from this pool of buffered frames. Then when the cache writer gets stalled on jbd2/dmcrypt holdups, the buffer pool just grows instead of frames being dropped. I may explore this option in the future, but for now simply syncing regularly has been sufficient in my usage, as it keeps the storage subsystem more continuously utilized and spreads out the writebacks so they don't completely back up the journal.
2020-11-08cache: pivot to new CacheFile APIVito Caputo
This minimally switches all the ad-hoc image cache files handling over to using CacheFile. I left the audio cache alone for now as it seems to not be compressed. It might make sense in the future to switch that over as well, especially if I start adding features to CacheFile like preallocating and async periodic fdatasync.
2020-11-08cache: introduce rudimentary CacheFile APIVito Caputo
Throughout the existing cache-related code there's constant checking if compression is active or not. This commit introduces a CacheFile ADT with the intention of replacing all the open coded stuff with simple calls into rmdCacheFile* functions operating on CacheFile instances. The management of split up cache files has also been implemented behind this API, so the reads and writes will transparently handle the split files. These have been named "chapters" in new code. No callers have been changed, this only adds the new facility. A subsequent commit will migrate things over.
2020-10-08*: more cosmetic formatting cleanupsVito Caputo
Making things a bit more consistent
2020-07-11*: drop {gtk,qt}-recordmydesktop subdirsVito Caputo
This restores the recordmydesktop/ subdir as root from the mirror I cloned by fork from. I have no particular interest in the gtk/qt frontends and it doesn't appear they were part of a single tree in the past. But I will probably preserve backwards compatibility of the cli so they can continue to work with this fork installed.
© All Rights Reserved