seafile-gc: results — 24.9M->5.6M inodes, blocks -235G, 21h33 rm-fs

Documents library identified as commit-storm source (19M fs objects,
~4.9M commits for 2.9G of data); its commit store survives GC and is
retired by recreating the library after fixing the offending client.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

ks4/seafile-gc.md

@@ -1,7 +1,28 @@
 # seafile: garbage collection + history retention
 
-Status: **diagnosed 2026-08-26, GC not yet run.** All crontab backup
-jobs on ks4 are commented out until this completes.
+Status: **GC executed 2026-08-26/27.** Results:
+
+| metric | before | after |
+|---|---|---|
+| dataset inodes | 24,885,504 | **5,571,443** (~600 k once the Documents commit store is retired, see below) |
+| `storage/blocks/` | 867 G | **632 G** (−235 G) |
+| fs objects | ~19.3 M | ~100 k (19,207,400 removed) |
+| ghost library stores | 13 | 0 (blocks/fs eaten by GC; 4 empty commit husks removed manually — `--rm-deleted` couldn't see them, they predate `GarbageRepos`) |
+| wall time | | 16 min (blocks) + 0.2 s (`-r`) + **21 h 33 m** (`-R`) |
+
+**Root-root-cause found**: one library — Documents
+(`c4ec7247`, 2.9 G data) — held **19.02 M fs objects and ~4.9 M
+commits**: a client has been committing at extreme frequency for
+years. The ~4.9 M commit objects survive GC (CE never deletes commit
+objects) and are most of the remaining inodes. Remedy: identify and
+fix the committing client, then **recreate the library** (sync down
+current state → new library → delete old → GC `-r`, which works for
+12.x-era deletions) — that retires the commit store entirely and
+takes the dataset to ~600 k inodes, at which point per-file backup of
+seafile becomes ordinary.
+
+All crontab backup jobs on ks4 remain commented out until restart +
+validation completes.
 
 ## Root cause of the 24.9 M-inode / 933 G dataset