On Tue, 9 Nov 2004, [ISO-8859-1] Bj?rn Steinbrink wrote:
On Tue, 9 Nov 2004 12:56:32 -0500 (EST) "Gregory (Grisha) Trubetskoy" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 either.
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.
Hmm... haven't thought about this, good point. Well how about this:
The key here is that a file belongs to a context other than 0. The actual xid doesn't matter.
So perhaps another fs flag would solve this. (As far as I understand there is no xid flag right now, IATTR_XID is an artifact of whether MS_TAGXID is there).
If I am in context 0 don't bother with counters.
If I am in context X and removing a file, then:
If the file belongs to a context other than 0:
decrement counterIf I am in context X and creating a file:
Set the xid flag to 1Grisha _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
