claude-botandClaude Bot
3a279d2dcd
Switches the Deployment's `data` volume from paperless-data (RWX, ceph-filesystem) to paperless-data-block (RWO, ceph-block). `consume` and `media` stay on CephFS -- the ftp-scanner writes to those from another node, so they genuinely need RWX. The copy is already done and verified byte-for-byte with paperless stopped: src files: 75 dst files: 75 IDENTICAL: name, size and mtime match for every file index segments: src 3, dst 3 mtime parity matters specifically because the Whoosh index segments carry their own consistency expectations; `cp -a` preserved them. (The "can't preserve" lines in the copy log were for the mount root /dst/. itself, not the files.) Why: only this Deployment ever mounted the volume, and its contents are single-writer state. Being on CephFS meant every access crossed the MDS -- measured with zero CI running, 22 requests/sec sustained and ~15 journal events/sec against 2 directory commits per 180s, i.e. cap/inode churn rather than file writes. That accounted for most of the constant 7-8 GB/day on cephfs-metadata, which is a size 3 pool. cephfs-metadata stays at size 3 deliberately: losing it destroys the entire filesystem rather than the objects on one OSD, and the 275 GiB in cephfs-data0 depends on it. paperless-data is retained (prune: disabled) as the rollback. It must NOT be deleted until search has been confirmed returning results -- that is what proves the index survived, not merely that paperless starts. Refs #434 Co-Authored-By: Claude Bot <noreply@anthropic.com>