mv within the same filesystem doesn't free disk space
Data migrations and disk freeing — moving old data 'aside' as a safety quarantine before deleting
During a disk migration where data moves from one mount point to another, the natural safety pattern is 'rsync to the new location, then mv the OLD location to a quarantine dir so rollback is possible.' Catch: if your quarantine dir is on the SAME filesystem as the original (e.g. you mv from ~/apps/storyteller/data to ~/.storyteller-quarantine/data and both live under /), mv only renames inodes — the bytes don't move and the source filesystem doesn't recover any space. df -h after this mv shows the same usage as before. To actually free space, the quarantine must be ACROSS filesystems (e.g. mv to a directory on the new mount), OR you have to outright delete the quarantine after verifying. Lesson: the rule 'mv is fast because it's just renames' is the same rule that makes 'mv as quarantine' a NOP for disk usage. If you want both safety and freed space, copy to the new mount, then DELETE the source.
When designing a quarantine step in a disk migration, check stat -c %D on source and target directories — if the device IDs match, your quarantine mv won't free space. Either move quarantine onto the new device, or accept that 'verify-and-delete' is the only way to recover the disk.