From: Björn Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Tue 09 Nov 2004 - 18:10:46 GMT
On Tue, 9 Nov 2004 12:56:32 -0500 (EST)
"Gregory (Grisha) Trubetskoy" <grisha_at_ispol.com> wrote:
> On Tue, 9 Nov 2004, [ISO-8859-1] Bj?rn Steinbrink wrote:
> > On Tue, 9 Nov 2004 12:01:33 -0500 (EST)
> > "Gregory (Grisha) Trubetskoy" <grisha_at_ispol.com> wrote:
> > I don't see any reason why it should behave like that, would only
> > cause trouble. Example: xid 10 is limited to 500MB and has 300MB in
> > use. xid 0 deletes some 50MB file. Now there are files worth 250MB,
> > but still the kernel assumes that 300MB are in use.
> I think this is fine. There is no way for context 0 to up the counter
> for another context (even chxid won't increment it), by the same token
> it seems more consistent if there would be no way to decrement it
> > Where's the sense behind that? You would have to adapt the usage
> > statistics every now and then.
> You'll just have to be mindful of this, and make sure to switch into a
> context when deleting files if you want the counter to be updated. The
> disk limits are "volatile" anyway (you have to set them upon bootup),
> so it's not like it is something that is an "unnatended operation" in
> the first place.
> The upside of this is that there are no special mount options that
> make things like backups difficult.
What about unification? You normally don't want the unified files to
lower the usage values upon removal of those files, since actually no
space is freed. You could of course say that you simply account
everything below /path/to/vserver for context X, but then you would have
to update the statistics for all vservers that use unified files upon an
update of the unified files.
Vserver mailing list