On Tue, Apr 15, 2014 at 7:10 PM, Josef Bacik <[email protected]> wrote: > Just make a SUPPORTS_V2 flag that userspace can pass in through the existing > flags to make the kernel spit out V2 commands. We don't want to break old > user space, I still have to see distro guys in real life ;). Thanks,
So would this flag named like "supports_v2" imply to send fallocate commands and data size computation/command? Right now I made data size optional, sent only if a new ioctl send flag is set, because for large fs trees it can take some time to compute data size. Also, would new btrfs-progs version send that flag (support_v2) always, without any option to use old v1, or not really that useful? thanks > > Josef > > Mark Fasheh <[email protected]> wrote: > > > On Tue, Apr 15, 2014 at 06:57:17PM +0100, Filipe David Manana wrote: >> >> > Are these changes compatible with software using the old stream >> >> > version? We >> >> > have snapshotting tools that are using send/recieve and it would be bad >> >> > to >> >> > change the ABI in incompatible ways underneath them. >> >> > --Mark >> >> >> >> New versions of btrfs-progs (send stream v2 support) will still be >> >> able to read and process v1 streams. Older btrfs-progs (v1 only) won't >> >> be able to process the new commands. >> >> Does this answers your question Mark? >> > >> > Yes it does thanks. Unfortunately though this is unacceptable behavior - >> > kernel upgrades are not supposed to break existing userspace interfaces. >> > >> > In particular what will happen here is that the user will grab a new kernel >> > and then find out that their fancy snapshotting software won't work any >> > more. >> >> Good point. I followed this approach based on Josef's comments on a >> previous rfc at >> https://urldefense.proofpoint.com/v1/url?u=http://www.spinics.net/lists/linux-btrfs/msg32999.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0A&m=wUTU%2FIE4hdC77M9gBWyPgg1QcqkuVHjEMjOGfI79alY%3D%0A&s=4d77650ee86676b158e0f54ff93c700300f098ae6d86f36fcf61feb70fa2ac78 > > Apparently Josef doesn't get those sorts of bugs in his queue ;) > > >> The only alternative I can think of right now is to use new send ioctl >> flags instead, so that new clients able to process the new commands >> will pass these flags explicitly, while old clients would continue to >> work without changes (and not bumping the stream version, as >> btrfs-receive refuses versions higher than 1 currently). This seems to >> be similar to what was done here: >> https://urldefense.proofpoint.com/v1/url?u=https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id%3Dcb95e7bf7ba481c3d35b238b1cd671b63f54238a&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=cKCbChRKsMpTX8ybrSkonQ%3D%3D%0A&m=wUTU%2FIE4hdC77M9gBWyPgg1QcqkuVHjEMjOGfI79alY%3D%0A&s=0e82acdd655c133f52a9717216f7038a09afa1bfefaa91c4d332530a5be4c3d6 > > Yeah that works for me - any client that understand the new features just > sends some flag that indicates it can process them. Then we know that old > clients will continue to work unaffected. > > Thanks Filipe, > --Mark > > -- > Mark Fasheh -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
