On Thu, Apr 15, 2010 at 03:30:58PM +0400, Dmitry Monakhov wrote: > > As long as you still have the awkward ifdefs and different semantics for > About ifdefs style: > How can i avoid CONFIG_PROJECT_ID without bloating inode size? > embedded people will kill me for this. > I just act similar quota code, or you want protect prjid logic > via quota config option? > I don't remember, are we already talk about this? > If so please remind me your vision. You have way more ifdefs than just that. E.g. struct iattr ones are pure junk; it's not kept around for long time. Moreover, since ATTR_... is not userland-reachable, you can bloody well #define ATTR_PRJID to 0 and get rid of more ifdefs. Ifdefs due to accesses to i_prjid can be reduced to just two inlined helpers (get_prjid/set_prjid) and there you go... As for the ->i_prjid itself, I'd buy ifdef there, but _not_ in that place within structure. You are shoving it between two pointers; think of alignment. As for the isolation... Why do we care about link/rename at all? All stuff with the same project ID gets counted together, wherever in the tree it might be. It's not as if we'd been scanning a subtree and calculate the sum over it, after all. So what is the problem? Some bastard DoSing you by creating links from places you can't write to? Then you want as much isolation as possible anyway, TYVM, and bind-as-link-barrier is entirely appropriate there. > > "isolation" vs "not" there's still a NACK from me. But in the end Al > > will have to decide if he wants to take your patches or not. I want details on use cases and semantics for isolation stuff; as it is, it looks rather odd. Why move towards "neutral" part of the tree is allowed and links over there are not, for example? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
