Mailing List Archive

> Hi, are there any quota gurus around?
No ;-).
>
> I'm allocating a couple of raw disk blocks on ext2. Currently,
> quotas are ignored. What's the recommended strategy to count
> these blocks?
>
> In additon, these blocks are shared among potentially many users.
> Is there any agreed-upon way to account for this?
Quota takes care only about blocks attached to some inode. If this is
the case you can use DQUOT_ALLOC_BLOCK() as defined in include/linux/quotaops.h.
The blocks will be accounted to owning user and group. There is no legal way
in current system you can account one block to more than one user or
more than one group. If blocks aren't attached to any inode there is
neither any legal way to account this. But you can do a dirty hack and just
gain a proper quota structure from dqget() (defined in fs/dquot.c), update
the dq_dqb.dqb_curblocks (do needed checks for exceeding a limits -- see
alloc_alloc_block() in dquot.c), mark dquot dirty and put it through dqput()...
> Any ideas what it takes to make quotacheck count these blocks correctly?
>
> (Currently, it's not even easy to find out how many blocks are
> allocated for a particular user and inode.)
Uhh.. Quotacheck is just userspace tool... It would have to gain somehow
a user list to accout blocks to. I know too few about your problem to decide
how to do this...
Honza.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Jan Kara wrote:
>
> > I'm allocating a couple of raw disk blocks on ext2. Currently,
> > quotas are ignored. What's the recommended strategy to count
> > these blocks?
> >
> > In additon, these blocks are shared among potentially many users.
> > Is there any agreed-upon way to account for this?
> Quota takes care only about blocks attached to some inode. If this is
> the case you can use DQUOT_ALLOC_BLOCK() as defined in include/linux/quotaops.h.
> The blocks will be accounted to owning user and group. There is no legal way
> in current system you can account one block to more than one user or
> more than one group. If blocks aren't attached to any inode there is
> neither any legal way to account this. But you can do a dirty hack and just
> gain a proper quota structure from dqget() (defined in fs/dquot.c), update
> the dq_dqb.dqb_curblocks (do needed checks for exceeding a limits -- see
> alloc_alloc_block() in dquot.c), mark dquot dirty and put it through dqput()...
Maybe I have to do that; maybe I can also somehow link it to the inode
the block is associated with...
Each ext2 inode has an i_file_acl and an i_dir_acl `pointer'. These
point to blocks allocated `naked' on the ext2 filesystem; they are not
in the regular inode block map. (The blocks contain Access Control
Lists, obviously).
Whenever an ACL block is found to be reusable, it is linked to by
another
inode, and its refcount is incremented. Then, there are multiple owners.
This
goes up to 1024 references per ACL block, currently. (That number may be
too
high for reasonable fault-tolerance, I have to experiment a little.)
>
> > Any ideas what it takes to make quotacheck count these blocks correctly?
> >
> > (Currently, it's not even easy to find out how many blocks are
> > allocated for a particular user and inode.)
> Uhh.. Quotacheck is just userspace tool... It would have to gain somehow
> a user list to accout blocks to. I know too few about your problem to decide
> how to do this...
Maybe I can stuff this piece of information in struct stat.
The stat code is quite tricky, there are two stat structs, and
two sets of system calls. Also, conversion between the in-kernel
memory layout and the external one is done in userspace, which
means glibc might need to be rebuilt, etc.
Thanks,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, Vienna University of Technology
a.gruenbacher@infosys.tuwien.ac.at
Contact information: http://www.infosys.tuwien.ac.at/~agruenba
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> > > I'm allocating a couple of raw disk blocks on ext2. Currently,
> > > quotas are ignored. What's the recommended strategy to count
> > > these blocks?
> > >
> > > In additon, these blocks are shared among potentially many users.
> > > Is there any agreed-upon way to account for this?
> > Quota takes care only about blocks attached to some inode. If this is
> > the case you can use DQUOT_ALLOC_BLOCK() as defined in include/linux/quotaops.h.
> > The blocks will be accounted to owning user and group. There is no legal way
> > in current system you can account one block to more than one user or
> > more than one group. If blocks aren't attached to any inode there is
> > neither any legal way to account this. But you can do a dirty hack and just
> > gain a proper quota structure from dqget() (defined in fs/dquot.c), update
> > the dq_dqb.dqb_curblocks (do needed checks for exceeding a limits -- see
> > alloc_alloc_block() in dquot.c), mark dquot dirty and put it through dqput()...
>
> Maybe I have to do that; maybe I can also somehow link it to the inode
> the block is associated with...
>
> Each ext2 inode has an i_file_acl and an i_dir_acl `pointer'. These
> point to blocks allocated `naked' on the ext2 filesystem; they are not
> in the regular inode block map. (The blocks contain Access Control
> Lists, obviously).
>
> Whenever an ACL block is found to be reusable, it is linked to by
> another
> inode, and its refcount is incremented. Then, there are multiple owners.
> This
> goes up to 1024 references per ACL block, currently. (That number may be
> too
> high for reasonable fault-tolerance, I have to experiment a little.)
If I understood right you want to account ACLs. IMHO the easiest way to account
this would be to account block to every inode which points to it. There is no problem
to implement this with current system - simply when we link some inode to block we
do DQUOT_ALLOC_BLOCK(sb, inode, 1). When inode stops pointing to it we do DQUOT_FREE_BLOCK(sb, inode, 1).
This way is also perfectly legal without ugly hacks... I agree we will be inaccurate
but I don't think it matter much.
> > > Any ideas what it takes to make quotacheck count these blocks correctly?
> > >
> > > (Currently, it's not even easy to find out how many blocks are
> > > allocated for a particular user and inode.)
> > Uhh.. Quotacheck is just userspace tool... It would have to gain somehow
> > a user list to accout blocks to. I know too few about your problem to decide
> > how to do this...
>
> Maybe I can stuff this piece of information in struct stat.
>
> The stat code is quite tricky, there are two stat structs, and
> two sets of system calls. Also, conversion between the in-kernel
> memory layout and the external one is done in userspace, which
> means glibc might need to be rebuilt, etc.
Yes, the stat is the only clean way I see. But it's not pleasant...
Honza.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/