[libvirt] [PATCH 0/2] Filesystem limits for containers

[Eric Blake]

On 04/24/2012 01:37 PM, Guido Günther wrote:
> Hi,
> the following two patches are a first stab at filesystem limits for
> containers. They're not ment for detailed review just to start the
> discussion. With these two patches space and inode limits in openvz
> containers are printed in the domain config as:
> 
> <filesystem type='template' accessmode='passthrough'>
>       <source name='debian'/>
>       <target dir='/'/>
>       <hardlimit>1153024</hardlimit>
>       <softlimit>1048576</softlimit>
>       <inodes_hardlimit>220000</inodes_hardlimit>
>       <inodes_softlimit>200000</inodes_softlimit>

I agree that we need all four limits (is the difference between hard and
soft limits the amount of space reserved only for privileged users, so
that regular users can't starve root out from ENOSPC cleanup that
requires just a bit more filesystem usage?).  But <hardlimit> seems
ambiguous compared to <inodes_hardlimit>.  Should we use
size_hardlimit/inode_hardlimit instead (and likewise for softlimit)?

And we want to let the user provide scaling on input (reusing some of
the same code as <memory> handling).  I guess inodes aren't really
bytes, though, so a unit='KiB' looks a bit weird in conjunction with an
inode limit.

Are there any kernel constraints on use of limits?  For example, can
softlimit appear in isolation, or must it appear with hardlimit; and if
it _can_ appear in isolation, does that mean the hardlimit matches the
softlimit or that the hardlimit is unlimited?  Should an explicit limit
of 0 be treated as unlimited?

> 
> Guido Günther (2):
>   domain_conf: add filesystem limits to virDomainFSDef
>   openvz; support file system quota reporting

Your patches came through unthreaded, which makes it harder to follow.
It helps when all of the child patches are in-reply-to the 0/n cover letter.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120424/f4136303/attachment-0001.sig>