Thank you guys for this status ! I think you should add it somewhere in the documentation cause I'm pretty sure this is a repeated question from users. -- Cyril SCETBON
> On 06 Nov 2014, at 02:51, Qu Wenruo <quwen...@cn.fujitsu.com> wrote: > > > -------- Original Message -------- > Subject: Re: Compatibility matrix kernel/tools > From: Hugo Mills <h...@carfax.org.uk> > To: Cyril Scetbon <cyril.scet...@free.fr> > Date: 2014年11月06日 05:45 >> On Wed, Nov 05, 2014 at 09:57:31PM +0100, Cyril Scetbon wrote: >>> Hi, >>> >>> Where can I find the compatibility matrix to know which btrfs-tools version >>> should work with a chosen linux kernel ? >> Any of them should work with any kernel. >> >> For normal operation, if the tools are too old, they may not >> support newer kernel features -- but that will simply mean you can't >> access the feature, not that anything will be broken. >> >> If you're doing recovery work (btrfs check and friends) then using >> the latest released version of the tools is strongly recommended. >> >> Hugo. >> > As Hugo mentioned, overall any kernel/user tool combination should be OK and > won't cause disaster. > > [Online operations] > More specifically, online(btrfs mounted) operations mostly depend on the > kernel. > Like subvolume/snapshot device add/remove/replace balance/scrub and > send/receive should mainly depend on the > kernel version. > > [If version not match] > 1. Kernel ver > progs ver. > It may happens that progs don't know the new added ioctls, so some bleeding > edge functions may not be available, > but everything should work fine without problem.(except some known/fixed > progs bugs) > > 2. Progs ver > kernel ver. > It may happen some ioctl not supported by kernel, if there is a fallback > method everything should work without problem, > or progs should prompt the fact that some bleeding edge function is not > supported by kernel. > Everything should also works fine except some known/fixed kernel bugs, which > maybe worse than progs bugs. > > [Offline operations] > Offline operations includes mkfs, btrfsck and all its > friends(btrfs-find-roots btrfs-show-super btrfs-debug-tree ...) > Since offline operations needs to do some dirty job like reading/writing the > superblock, it may cause big compatibility problem > if using some new incompact features. > > [If version not match] > 1. kernel ver > progs ver. > There maybe some btrfs filesystems that kernel can mount but offline tools > can't open. > For example, before v0.20-rc1 progs doesn't support skinny metadata, and 3.17 > kernel supports it, > a btrfs created with skinny metadata can't be fscked using v0.20-rc1, but > kernel can still mount it, > and online operations should be fine. > > If not using the new features, it would be OK. > > 2. kernel ver < progs ver > This maybe even worse. > If you create a fs with latest progs, which may enable some new feature like > big metadata on *DEFAULT*, > kernels before v3.3 will be unable to even mount it since it can't understand > the new incompact features. > > > [Conclusion] > If not using offline operations often, compatibility won't be a big problem. > If using offline operations often, better keep kernel/progs version from > differing too much. > > Also if you want to keep a matrix for it, it may take some time to git > blame/log/describe... > Tips will be focus on INCOMPACT flags in fs/btrfs/ctree.h and ioctls change > in fs/btrfs/ioctl.c. > > Thanks, > Qu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
