Ken Dreyer writes: > Hi folks, > > I just had a developer fill up my Gitorious partition with a very > large git repo. The problem was compounded by the fact that I > neglected to put /var/gitorious on its own partition... whoops. I > remedied that in hindsight :)
Ouch! > I'm trying to brainstorm the best way to prevent one repo or project > from filling up and blocking service for any other projects. I still > want the project and repo provisioning process to be as close to > self-service as possible - I'd rather not babysit something if I can > help it. > > I was wondering if anyone had any information or tips in relation to > enforcing quotas? Interesting question. From an application standpoint, there's one situation where such a thing could be enforced. After pushing to a repository, the PushProcessor will calculate the disk space used by a repository. You wouldn't be able to stop the push from being received, but at least we could trigger some alarms at this point. Another approach could be to use eg. btrfs and set up subvolumes for new projects in the repository root, assuming you're running with un-sharded paths. Let's say a user creates a project "gitorious" and the first repository "mainline": when generating the repository on disk in Gitorious we could set up a subvolume for the project, so: /var/www/gitorious/repositories/gitorious would become a btrfs subvolume where we could enforce quotas. Achieving this would require a hook inside the routine where a repository is created in Gitorious, but it would definitely make sense (as long as you're ready to trust btrfs with your data). Zfs could be an alternative to btrfs, but the license situation is a little problematic here. Cheers, - Marius -- -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
