hi Kir, thanks a lot for the hint. however, in our cases, we didn't put anything in the user's container. is it possible for a user to bypass vzquota through writing files in /vz/private directly? on the other hand, once we restart the container, the disk utilization gets down. is it possible that an unclosed but removed file eats out the storage, at large off the quota control? we doubt it is possible but we cannot replay it: when we dd a file, suspending the process, rm the file and fg the process again, the quota for the test container soon plays the role.
any further idea? thanks and regards, maoke 2013/7/8 Kir Kolyshkin <[email protected]> > > On Jul 7, 2013 11:57 PM, "Maoke" <[email protected]> wrote: > > > > hi all, > > > > we recently discovered twice that actual disk usage of a certain > container exceeds the quota setting but the vzquota doesn't show the exact > usage and doesn't work to stop the usage. df in the host shows continuously > increasing growth though. > > > > do anyone have the similar experience? kernel is 2.6.18-based. thanks! > > This is usually the case when you write to container filesystem from the > host bypassing vzquota — to /vz/private rather than /vz/root. > > To fix, you need to reinitialize the quota. Stop container, do vzquota > drop $CTID and start it again. vzquota drop removes quota file, so they > have to be re-created on container start. > > > > > maoke > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > https://lists.openvz.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
