3

I manage some unix systems, and users on my system are creating a lot of junk and littering their work areas. I am running into filesystem full every day. There are many terabytes locked up and is just waste.

There are cleanup processes that are cron'd running every day or so, but some types of files, like backup of a very large ear file, a database dump will not get identified by pattern matching. I am even considering to nuke their accounts, but it may involve collateral damage.

What are some tools/processes/techniques to create work environment I can introduce to help from not continuing wasting disk storage without having to nuke them.

  • this question was earlier posted on stackoverflow. – user744166 Aug 19 '13 at 4:55
7

It is impossible to determine automagically which files might be important to your users and which don't. Even large and old log files which haven't been changed for weeks or months might still contain important information. Use disk quotas and let the users have to talk to you if they need more space.

Another thing I remember from my student time is a somewhat-public (but only within the local department) sheet of paper containing an ordered list of user names and their current home directory sizes. A more friendly version of a hall of shame. It makes your users realize whenever they use way more disk resources than others. But I guess this is only acceptable for a small group of people who know each other well.

| improve this answer | |
  • I agree. There is no magic solution. But I remember that as a developer my self, I would be very disciplined on how to make use of the resources. I see that completely lacking with users on my system when i am an Admin. I have not been able to come up with any thing intelligent (cron jobs or processes) to induce any practices that will ensure use the wastage reduces. Disk quotas have only added more load as I get more calls from users who are annoyed. – user744166 Aug 20 '13 at 13:02
2

You can try using logrotate, a daemon which will manage logs (and other files) based on rules you create. Many text files compress very well, logs for instance frequently hit 95%+ compression because they have the same terms over and over. Much safer than deletion since you have not removed the data, only compressed it.

As said before USER data is very tricky to archive/manage (although you may be able to, depending on your file system & settings, use Last Accessed Date to auto-archive some stuff) but I recommend first MOVING the data you are considering getting rid of, then COMPRESSING it and only deleting after a long enough period to know no one was depending on it. You can also consider using cheap storage as a low tier archive target instead of deleting. Move the file there and use a soft symlink to point at the new location.

| improve this answer | |
  • Logs are not the only source of misery for me. some users while working on their j2ee project create j2ee.bck or j2ee.back or j2ee.<date> as backup. each j2ee folder is a few GBs. there are users who create sql dumps and leave (litter) on the FS. – user744166 Aug 20 '13 at 12:57
2

I think you should introduce quotas to your users. That way they might run into the limit of their quota and can't upload more stuff, but they can't fill up your whole file system.

Here is a nice guide for howto do it:

http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-disk-quotas.html

| improve this answer | |
  • I could do that. with the soft quota, they could get alerts on logging in. I did consider it as an option, but still it will not solve the problem. My intent is to get them disciplined, and be better unix'ens. – user744166 Aug 20 '13 at 12:55
  • How will making your users aware of the problem not solve it? There is nothing better you can do instead of forcing them to handle this problem on their own. – scai Aug 20 '13 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.