Sync cached files and refuse ones left empty or partial (closes #252)
check / check (push) Waiting to run
check / check (push) Waiting to run
A crash could leave a cached source or transformed image empty or cut short, and pixa then served it, or fetched it again forever. Source and transformed image files, and the .meta file beside each transformed image, are now written under a temporary name, synced, renamed into place and their directory synced; a failed directory sync removes the renamed file. The reconciliation pass compares each cached file's size with the size its row records and removes a file that is empty or of another size, with its rows and a warning. Requests compare no sizes. Not verified by a test: the syncs, and the removal after a failed sync. Model: opus-5-5
This commit was merged in pull request #263.
This commit is contained in:
@@ -164,6 +164,14 @@ name.
|
||||
Multiple source paths may reference the same content blob; the database tracks
|
||||
references rather than using filesystem refcounting.
|
||||
|
||||
Source and transformed image files, and the `.meta` file beside each transformed
|
||||
image, are written under a temporary name, synced to disk, and only then renamed
|
||||
into place, so a crash leaves no file under its own name with part of its data.
|
||||
When pixa starts, and every five minutes after, it removes each cached source or
|
||||
transformed image whose file is empty, or not the size the database records for
|
||||
it, with a warning naming the file; the next request for it fetches the source
|
||||
or converts the image again.
|
||||
|
||||
pixa's target is 1-5k r/s, which has not been measured at that rate (see Load
|
||||
Test). Toward it, pixa keeps in memory the content types of the 10,000
|
||||
transformed images most recently cached or served, so a cache hit on one of them
|
||||
|
||||
Reference in New Issue
Block a user