OpenVZ Forum


Home » General » Support » *SOLVED* Plesk 7.5 user - what happens at disk quota limit?
*SOLVED* Plesk 7.5 user - what happens at disk quota limit? [message #11628] Thu, 29 March 2007 17:16 Go to previous message
BrianBatson is currently offline  BrianBatson
Messages: 1
Registered: March 2007
Junior Member
Hi OpenVZ,

Please indulge and if necessary forgive the newbie post. I have not encountered this software until recently.

I am a customer of a PLESK 7.5 Reloaded system with a 10gb disk quota. Something happened to my server (perhaps a "glitch/error") that caused it to hit disk quota limit. I did not get to investigate the reports of du or df at that moment. I did remove about 500MB and then saw my PLESK report say about 3.6gb used - jumping from 100% to about 36% utilization. I saw in the messages log a comment

My question is - with the disk quota limit in place, I believe it is hard limit. You can't borrow or temporarily use a little extra. And there is no warning - no code that should have been run to notify the administrator of the pending issue. Is that correct?

In my recent experience, the memory limit, if not a glitch, was the result of an incoming email message that pushed the memory over the limit. That implies I must have had the system at 9.999 gb when the mail came in. In any case, Linux couldn't write system files and during reboot it "zeroed" a fair number of xinetd services - and crashed/failed - requiring a complete system rebuild. I never saw anything about a memory allocation problem until I reviewed the messages log (which itself became truncated).

I'd like to avoid this in the future. Can I get the hosting company to configure a soft limit? Can I turn on any kind of reporting? Do I need to check often?

Thank you for your time and help.

[Updated on: Wed, 04 April 2007 12:20] by Moderator

Report message to a moderator

 
Read Message
Read Message
Previous Topic: *SOLVED* download site down
Next Topic: *SOLVED* VE capabilies
Goto Forum:
  


Current Time: Thu Jul 11 02:19:26 GMT 2024

Total time taken to generate the page: 0.02549 seconds