On Tue, 19 May 2009 12:32:44 -0700 Joel Becker <Joel.Becker@xxxxxxxxxx> wrote: > I considered that, but really a process specifying > REFLINK_ATTR_ALL wants a complete snapshot. So if we add things to our > inodes later, and then you have an old program asking for "a complete > snapshot", it won't get it. It'll get a partial snapshot, missing the > things we added later. > Conversely, a newer program that knows about the new things will > get an error on an older kernel when it asks for the complete snapshot. Yep, that's why I'd suggested carving out a set of bits rather larger than the ones specified now. That would allow any future flags to be included in the REFLINK_ATTR_ALL "space" if that seemed like the right thing to do. It would be forward and backward compatible. Anything added outside that bit range would, presumably, be a more significant change which should not carry forward or backward automatically. > You'll note I called this 'preserve', not 'flags'. It's not a > set of behavioral flags, it's a mask of attributes to preserve. Understood, but that may not stop somebody else from trying to extend the API in different directions in the future. It seems like a way to make life easier for that person when the time comes. Just a thought, anyway; not something I'd make a fuss about. jon -- 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
