Robert Watson wrote:
On Tue, 26 May 2009, Menshikov Konstantin wrote:
Yes. But jail cannot allocate block and inode above root path. In
allocation functions, whether for example ffs_alloc we have access
to ucred process and we can check up there is a process in jail.
Yes, you can check this for jailed process. Think about non-jailed
processes that can do allocation below the jail root.
Processes out of jail are not considered. I do not understand, these
processes have what relation to disk to quotas for jail. Please
explain more in detail
Historic UFS quotas are actually not interested in processes at all,
really, except in as much as processes are where exception states are
exposed. UFS quotas count blocks and inodes owned by users based on
the 'uid' and 'gid' fields in the inode. There's now 'jailid' field,
so quotas on this model can't capture the notion of per-jail quotas.
In fact, quotacheck relies on being able to walk the file system
looking only at file system data in order to establish initial usage
accounting. You can imagine adding one, or managing the uid spaces
across jails such that all uids are unique, etc, but all of these
require some amount of rethinking.
Or, some other model of quota. Frankly, I've always been a fan of the
AFS model, now accessible locally via ZFS, in which lightweight
volumes with quota limits are used for individual user home
directories, virtual machines, etc. This was hard to do in FreeBSD
before ZFS because (a) UFS didn't want to resize trivially and (b)
having lots and lots of mountpoints and file systems wasn't something
we made administratively easy.
Robert N M Watson
Computer Laboratory
University of Cambridge
Actually realisation of quotas for jail, is reduced to realisation of
quotas on catalogue contents. And it is difficult, it is not necessary.
Many thanks for answers and explanations.
Menshikov Konstantin
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
