Re: container disk quota

Hi Kirill,

On 06/02/2012 11:21 PM, Kirill Korotaev wrote:

quoted

quoted

quoted

quoted

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.

1. OpenVZ doesn't use mount namespaces and still has quotas per container.

AFAICS, OpenVZ has self-released quota tools to supply this feature.

but standard quota tools work inside container w/o any modifications.
This is very important for us, cause we run unmodified distros inside.

Yes, am agree.
I can work out a new patches regarding quota tools based on mount namespace w/o any modification.

Actually, this is unrelated. I meant that OpenVZ needs ability to have group quotas w/o mount namespaces.

quoted

quoted

2. BTW, have you seen Dmitry Monakhov patches for same containers quotas via additional inode attribute? it allows to make it journaled.

You means the directly/project quota on ext4?
If yes, I have observed this feature back to the end of last year in
EXT4 mail list.

yes

quoted

quoted

How quotas are stored in your case?

It simply cached at memory for now, it also can be tweak up to journaled
I think, if introducing corresponding routines quota_read/quota_write to
particular journal file system.

just cached quotas are bad - you never sure they are correct.
journaled quotas (as standart) are much better.

Exactly.

quoted

quoted

3. I tend to think nowdays such quotas maybe of less need. Quota code doesn't scale well. And it's easier to put container in image file (as OpenVZ recently introduced).

There have such requirements dropped to LXC mail list nowadays.
Directory quota is pretty cool and it also useful to containers perspective.

However, that's two different quota mechanism.

"Quota code doesn't scale well".
Do you means it have global locking mechanism and only quota structure
to bill up quota for all file systems with VFS quota enabled?

yes.

That's also means there has a potential opportunity for improvement in terms of scalability.

Thanks for your info!
-Jeff

Kirill