Hi Serge, On 06/02/2012 12:04 AM, Serge Hallyn wrote: > Quoting Jan Kara (jack@xxxxxxx): >> Hello, >> >> On Wed 30-05-12 22:58:54, jeff.liu@xxxxxxxxxx wrote: >>> According to glauber's comments regarding container disk quota, it should be binded to mount >>> namespace rather than cgroup. >>> >>> Per my try out, it works just fine by combining with userland quota utilitly in this way. >>> However, they are something has to be done at user tools too IMHO. >>> >>> Currently, the patchset is in very initial phase, I'd like to post it early to seek more >>> feedbacks from you guys. >>> >>> Hopefully I can clarify my ideas clearly. >> So what I miss in this introductory email is some highlevel description >> like what is the desired functionality you try to implement and what is it >> good for. Looking at the examples below, it seems you want to be able to >> set quota limits for namespace-uid (and also namespace-gid???) pairs, am I >> right? >> >> If yes, then I would like to understand one thing: When writing to a >> file, used space is accounted to the owner of the file. Now how do we >> determine owning namespace? Do you implicitely assume that only processes >> from one namespace will be able to access the file? >> >> Honza > > Not having looked closely at the original patchset, let me ask - is this > feature going to be a freebie with Eric's usernamespace patches? It we can reach a consensus to bind quota on mount namespace for container or other things maybe. I think it definitely should depends on user namespace. > > There, a container can be started in its own user namespace. It's uid > 1000 will be mapped to something like 1101000 on the host. So the actual > uid against who the quota is counted is 1101000. In another container, > uid 1000 will be mapped to 1201000, and again quota will be counted against > 1201000. Is it also an implications that we can examine do container quota or not based on the uid/gid number? > > Note that this won't work with bind mounts, as a file can only be owned > by one uid, be it 1000, 1101000, or 1201000. So for the quota to work > each container would need its own files. (Of course the underlying > metadata can be shared through whatever ways - btrfs, lvm snapshotting, > etc) Do you means that we can not bind mount outside files to container for as general adquot.user/adquot.group purpose? If so, per glauber's comments, bind quota to mount namespace should be a generic feature, and container just one of users could make use of it. Again, if bind quota to mount namespace is on right direction, and it only does make sense to container for now, maybe we don't need such files. IMHO, container is a lightweight virtualization solution, maybe its fine to make it as simple as possible. If the server admin need to configure hundreds of user/group dquot per container, perhaps he should consider KVM/XEN. Thanks, -Jeff > > -serge > -- > 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 -- 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
