On 11/06/2014 09:51 AM, Qu Wenruo 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.
for the long term its better if (some critical) offline tools are
moved into the kernel and operate on the disks through the
/dev/btrfs-control ioctl which in case the disks doesn't have to
be mounted. btrfs is also a volume manger there should be a way
to manage the disks in the kernel not necessary only when the device
is mounted.
Thanks, Anand
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
--
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
