In order to make the scratch NFS use a proven and more reliable failover method, an rsync to a new volume without deletion was necessary. That left behind already cleaned up files.
As a result of this, video2commons is using 1.1 TB of scratch space at the moment. Can you please help clean it up?
If an automated process will take care of it in a few, feel free to close up the ticket.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • Bstorm | T216208 ToolsDB overload and cleanup | |||
| Resolved | aborrero | T216769 wmcs: audit old hardware | |||
| Resolved | bd808 | T216747 Decommission outdated and risky hardware | |||
| Resolved | Jclark-ctr | T187456 Decommission labstore100[123] and their disk shelves | |||
| Unknown Object (Task) | |||||
| Open | None | T209530 Build user data backup service based on remote sync rather than NFS | |||
| Resolved | • Bstorm | T193655 rack/setup/install cloudstore1008 & cloudstore1009 | |||
| Resolved | • Bstorm | T209527 Set up scratch and maps NFS services on cloudstore1008/9 | |||
| Declined | None | T283385 Upgrade labstore1004, labstore1005, cloudstore1008 and cloudstore1009 to Debian Buster | |||
| Resolved | • Bstorm | T224747 Move maps and scratch on cloudstore1008/9 to a DRBD failover similar to labstore1004/5 | |||
| Resolved | • Bstorm | T285981 /data/scratch NFS space too high | |||
| Resolved | zhuyifei1999 | T285982 video2commons needs cleanup on /data/scratch following NFS changes |
The automated process cleans up old files in /data/scratch/video2commons/uploads/ after 360 days and /data/scratch/video2commons/ssu/ after 60 days. Do you need it shrunk right now or do you mean a rolling cleanup process is okay?
Well, I screwed up the rolling process to some extent via rsync, so if the 60 day one could be run right away, that would be lovely!
I think I'll close this as resolved as it may have resolved itself when the cronjob was able to succeed and tidy things up.