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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list