spatester

Appdata Backup plugin performance degradation / stalls when encountering sparse files with large logical size (LMDB/Meilisearch pattern) The Unraid Appdata Backup plugin appears to become very slow or stall when backing up Tunarr appdata due to a massively sparse LMDB database file (data.mdb) inside Meilisearch storage. The file reports a logical size of ~2TB but only ~44KB of actual disk usage, which likely causes the backup process to treat it as a large file and process it inefficiently. ``` ls -lh data.mdb -rw------- 1 root root 2.0T May 15 05:19 data.mdb du -h data.mdb 44K data.mdb ``` Sparse file (high logical size, minimal physical blocks) LMDB / Meilisearch backend storage What happened: Backup process slows significantly or stalls when reaching sparse files with large logical size Disk I/O spikes on backup destination Backup time disproportionately increases compared to dataset size (~141MB total appdata directory) No corresponding increase in actual data size (verified via du) What should happen: Sparse files should be handled efficiently (skip unwritten blocks) Backup time should correlate with actual disk usage, not logical file size No excessive I/O caused by sparse LMDB mappings The file is a sparse LMDB database used by Meilisearch: LMDB preallocates a large virtual address space File reports large logical size (2TB) Actual disk usage is tiny Backup plugin likely: Reads full logical file size Does not use sparse-aware copying (--sparse) Or calculates progress based on apparent size ls -lh /mnt/cache/appdata/*/data.mdb du -h /mnt/cache/appdata/*/data.mdb stat /mnt/cache/appdata/*/data.mdb tar cf /dev/null /mnt/cache/appdata/tunarr/data completes in ~1second, confirming real data size is small. The backup tool should use sparse-aware copying: rsync -S tar --sparse This is likely not a Tunarr bug directly, but a combination of: Meilisearch LMDB storage behavior Backup plugin not handling sparse files efficiently