On Mon, 2010-10-18 at 21:30 -0400, Christoph Hellwig wrote: > I do not like this at all. It bloats the inode with three unsigned > long values for a feature no sane person would ever use. And given > that distros are sweet-talked by IBM to enable it the world will pay > a huge penality for those 0.5% of the userbase that use IMA. > > Please reorder your series to have patch to disable IMA unless > explicitly enabled on the kernel command line first, and then second > use the rbtree from your last patch. More cryptic command line options and complexity is not the solution. I have no plans to send (a fixed/"working" version of) Kyle's patch which would cause a userspace regression since working machines would magically stop working. The right solution is to provide features without unreasonably impacting those who do not want those features. At the moment my patch series reduces memory usage by a factor of at least 40 and eliminates the locking contention and serialization of bringing inodes into and out of core. It does so without introducing ANY additional overhead or complexity. If there is a general consensus that 24 bytes per inode is too large we can move forward from here and drop the 'opencount' and save 8 bytes (while eliminating the debugging and verification this code has helped to provide in the past) If there is a general consensus that 16 bytes per inode is too large we can travel down the much more complex route of attempting to collect this information dynamically by freezing userspace, scanning every open file, and calculating the information. We would then have a 2 stage integrity structure, the first with just counters and the second would contain integrity information if needed. I'm willing to add those next 2 steps to my todo list if there is a consensus that the situation at hand is untenable, but those cannot be my highest priority. We are talking about a feature which has been enabled without massive complaint (aside from having bugs fixed in the kernel, in IMA, and in out of tree modules) in Fedora kernels for over a year. Obviously I think Dave's report is a big deal. Things were really really wrong, and I'm willing to fix it when things are wrong, but eventually I hit the point of diminishing returns. -Eric -- 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
