About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 25 Dec 2002 - 17:46:27 GMT


On Wed, Dec 25, 2002 at 06:38:11PM +0300, Lyashkov Alexey wrote:
> Hello vserver,
>
> Me have 2 types of files
> 1) Files shared between contexts (some dir entry in different context
> to one inode) It's flagged by IMMUTABLE_LINK and this files is r/o
> in context other from owner.

not exactly, it is a hardlink (reference to inode,
which must reside on the same filesystem), and it
can be unlinked (removed) by permitted users in
any context.

> 2) Files are pirated for context (one dir entry in one context to one
> inode)

not sure what you mean, but the other files are
simple copies or new files created for/by the
"owning" context ...

> For per context disk quote we can scan vserver "root" directory for
> count disk space used for private files. After scan this sum send to
> kernel for start controlling disk quote. Control function insert in
> parallel original DQUOT* function, not in inside (because if
> CONFIG_QUOTA set to "n" all DQUOT* function will become inline).

as I started with per context quota implementation, my
concepts of the quota system where .. somewhat similar
to yours, but unfortunately, as I learned, the quota
system is much more complex than expected ...

- at any moment, the kernel can decide to fetch the
  stored quota information from the quota files
  (*.quota, *.aquota) or write it back (on quota sync)
- the kernel will not be able to separate one context
  from the other (rearding user/group quota) because
  this information only relies on the inode (de)alloc
  operations, so you'll have to track the migration
  from one context to the other ...

you might ask Jan "Honza" Kara if you do not understand
some details in the quota/quota-2 code ...

> For per user/group disks quote me must add super block (with dir entry
> pointing to real vserver root) member in kernel context structure for
> correctly read/save files with quotas.

as far as I know the vfs layer, you will not easily
add a fake superblock to an existing filesystem, because

- every inode stores a reference to it's superblock
- it's pure horror to modify each reference on the fly
- you will harm/disable the caching/reference counting

> It's similar as a result "mount -bind" command.

the --bind mount is a vfs feature and so does not have
any superblock or quota ioctls except for the underlying
filesystem ...

> For quote hash function me add context identifier as
> high 16 bit system device identifier. It's defending hash against
> collision.

please give some examples ...

> For "quotacheck" tools, we can change type fs in fstab/mtab from
> "ext2" to "nfs" ("none" is unknown for this tools) and patch stat
> function to return type disk type "0" (It's type for NFS disks.) to
> all requests from context other than zero.

nfs quota is done via a remote deamon reporting the
quota information over network, and I do not see how
this approach would help ...

> Paul, Herbert what you opinion ?

we really should work together, to find the "perfect"
solution for the following issues:

- disk space resource management (could be quota)
- virtual server root partition (fake or filesystem)
- per context user separation (uid/gid/???)
- template - clone relation (for updates, cloning, etc)
- root jail (could/should be related to the above)

best,
Herbert

> --
> Best regards,
> Lyashkov mailto:shadow_at_itt.net.ru
>


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 25 Dec 2002 - 18:05:09 GMT by hypermail 2.1.3