On Wed 03-02-10 08:38:15, Dmitry Monakhov wrote: > Jan Kara <jack@xxxxxxx> writes: > > > On Tue 02-02-10 18:00:24, Dmitry Monakhov wrote: > >> During some quota oparations we have to determine quota_id for given inode > >> according to quota_type. But only USRQUOTA/GRPQUOTA id are intermediately > >> accessible from generic vfs-inode. This patch introduce new per_sb quota > >> operation for this purpose. > > Hmm, but you do not intend to ever change what is returned for USRQUOTA > > and GRPQUOTA, do you? So we could just have something like > Hmm... In fact i've considered this option. For example: > In case of containers(trees), each container administrator want > user/group quota to work inside it's container. I've considered > following approach: > 1) enlarge qid_t to u64 > 2) encode quota_uid and group_uid like follows: > quid = treeid << 32 + uid > qgid = treeid << 32 + gid > 3) Introduce new 64-bit quota format file to support wide qid_t. > > Currently i dont know better way to support user/group quota > inside tree. It does not affect old fs-internal code, just replace > all hard-coded (int => u64) in fs/quota-XXX. Old 32-bit quota users > not affected because qid_t will be shrink ed on quota-save for > old(most of) users. I see. But from what you write it seems to me that actually you'd like a separate filesystem for each container - you'll get a separate quota files for each container (so no need for id mapping) and a natural total limitation of how much the container can use (the filesystem size). Now I understand that having really a separate filesystem for each container is impractical when you want to change sizes of each container and also the overhead of separate filesystem might be too big. But I'd like to understand your needs... Because it might be feasible to introduce a support for lightweight "subfilesystems" of a filesystem if that would solve your case... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
