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

From: Alex Lyashkov (shadow_at_itt.net.ru)
Date: Wed 25 Dec 2002 - 19:15:21 GMT


> 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.
see unifity_old.sh. it's make hardlink and apply IMMUTABLE flag.

> > 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 ...
ok. say otherwise. files owned in on context. shared one inode in one 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 ...
Disk quota not work with files shared beetwen context.
it`s need return "true" from macros IS_NOQUOTA(inode) for files
with IMMUTABLE flag.
other files can separate by context.
for read/save/sync quota files we will can switch referenced super block
or filp = sb_dqopt(dquot->dq_sb)->files[type] per context.
other way save file strcut in context structure and switch that.
>
> - 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
is't not need do. only for disk quote operations.

> > 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 ...
static inline int const hashfn(kdev_t dev, unsigned int id, short type)
{
        return((HASHDEV(dev) ^ id) * (MAXQUOTAS - type)) % NR_DQHASH;
}
and
static struct dquot *dqget(struct super_block *sb, unsigned int id, short type)
{
        unsigned int hashent = hashfn(sb->s_dev, id, type);
        
use that
static int set_dqblk(struct super_block *sb, qid_t id, short type, int flags, struct mem_dqbl
k *dqblk)
....
        if (copy_from_user(&dq_dqblk, dqblk, sizeof(struct mem_dqblk)))
                    return error;
                        
        if (sb && (dquot = dqget(sb, id, type)) != NODQUOT) {
....

change it's
        if (copy_from_user(&dq_dqblk, dqblk, sizeof(struct mem_dqblk)))
                    return error;
+
        sb = currnet->s_context.sb;
+
                        
        if (sb && (dquot = dqget(sb, id, type)) != NODQUOT) {

and in
void dquot_initialize(struct inode *inode, short type)
{
change all inode->i_sb to inode->s_context.sb;

where inode->s_context pointer to context info structure.

in my version vserver all object have pointer to s_context, but in official
had context number.

>
> > 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 ...
only for quotacheck no use access to block device and read files withot countrol
device type.

>
> > 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 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 - 19:32:16 GMT by hypermail 2.1.3