Wunschkonzert, Ponyhof und Abenteuerspielplatz

Last October we published a wishlist for plumbing related features we'd like to see added to the Linux kernel. Three months later it's time to publish a short update, and explain what has been implemented in the kernel, what people have started working on, and what's still missing.

The full, updated list is available on Google Docs.

In general, I must say that the list turned out to be a great success. It shows how awesome the Open Source community is: Just ask nicely and there's a good chance they'll fulfill your wishes! Thank you very much, Linux community!

We'd like to thank everybody who worked on any of the features on that list: Lucas De Marchi, Andi Kleen, Dan Ballard, Li Zefan, Kirill A. Shutemov, Davidlohr Bueso, Cong Wang, Lennart Poettering, Kay Sievers.

Of the items on the list 5 have been fully implemented and are already part of a released kernel, or already merged for inclusion for the next kernels being released.

For 4 further items patches have been posted, and I am hoping they'll get merged eventually. Davidlohr, Wang, Zefan, Kirill, it would be great if you'd continue working on your patches, as we think they are following the right approach^[1] even if there was some opposition to them on LKML. So, please keep pushing to solve the outstanding issues and thanks for your work so far!

Footnotes

[1] Yes, I still believe that tmpfs quota should be implemented via resource limits, as everything else wouldn't work, as we don't want to implement complex and fragile userspace infrastructure to racily upload complex quota data for all current and future UIDs ever used on the system into each tmpfs mount point at mount time.

posted at: 21:26 | path: /projects | permanent link to this entry | 5 comments

Posted by Anonymous at Sun Jan 22 03:55:32 2012
Request for new item:
"Support for SCTP is missing in SELinux"

Would it be possible to add the above item to the list? There are some pointers in https://bugzilla.redhat.com/show_bug.cgi?id=517676 .

tia.

Posted by Anonymous at Thu Jan 26 12:18:08 2012
While I do agree that the current quota approach won't work for tmpfs, I wonder if that suggests the need for a slightly more general solution. You mentioned two major issues: "racily upload" and "all current and future UIDs".

The first problem seems like the same issue as setting other mount options at mount time: you need a way to set quota at mount time, or at least to do so before the mount point becomes accessible to anyone else. Could systemd do this early enough in the boot process that nothing else can run? Or, could you mount with no permissions for anyone but root, add quotas, then expand the permissions? Alternatively, could the kernel just support quota information as a mount option?

The second problem seems like a problem common to almost any filesystem with quotas: you don't want to specify a different quota for each user, you want to specify one quota for all users with some potential exceptions. That seems generally useful.

Would solutions for both of those problems address this issue for you?

Posted by Lennart at Thu Jan 26 23:11:50 2012
Anonymous: I see the usefulness of labels on SCTP, but I am not sure this would fit well under a "plumbers" wishlist...

Other Anonymous: the problem is that apps (i.e. most of the desktop stack) use poll() on /proc/self/mounts to watch what gets mounted and what not, and they expect (rightfully) to be able to access everything that shows up as it shows up. Trying to keep them off that is just going to be messy and is simply not how the system was designed nor is it desirable. And passing in the quotas as mount options isn't really doable, since at mount time one has little clue about which users might be created later on, and the quota data could get extensive and not really nice to include in the mount options. People would really hate us if we serialized quota info for 50.000 user in the mount options of /tmp! Think how the output of /bin/mount would look like then!

Posted by Anonymous at Sat Jan 28 16:15:33 2012
Lennart: No, I didn't mean that you should have to provide quota data for umpteen users in the mount options of /tmp. I meant that the quota mechanism should support generic quotas that apply to broad swaths of users, so that you could do something as simple as mount -t tmpfs -o stdquota=50M tmpfs /path/to/some/tmpfs. Does that seem reasonable?

Posted by Lennart at Sun Jan 29 15:47:08 2012
Anonymous: something like that would be better than nothing. However, I think in the long run this won't suffice, since users are different, and administrators will most likely want to configure different quotas for them, without having to remount all tmpfs all the time... But if somebody preps a patch for this I am going to support it, even though I wonder if it makes sense adopting a half-way solution in the kernel, if it is clear from the beginning that it is a half-way solution only. (Also, sincde we mount some tmpfs (i.e. /run) already in the initrd, so if we don't want to remount it during normal path we'd have to encode policy in the initrd which we try to avoid)

Leave a Comment:

It should be obvious but in case it isn't: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

Please note that I take the liberty to delete any comments posted here that I deem inappropriate, off-topic, or insulting. And I excercise this liberty quite agressively. So yes, if you comment here, I might censor you. If you don't want to be censored your are welcome to comment on your own blog instead.

レナート Wunschkonzert, Ponyhof und Abenteuerspielplatz ﻟﻴﻨﺎﺭﺕ

Fri, 20 Jan 2012

Plumbers Wishlist, The Third Edition, a.k.a. "The Thank You Edition"