* Re: Moving over to use BTRFS - first time, needs encryption
2013-10-29 15:19 Moving over to use BTRFS - first time, needs encryption btrfs.nrb
2013-10-29 17:27 ` Moving over to use BTRFS - first time, needs encryption (btrfs: message 1 of 20) Nigel Bray
@ 2013-10-29 17:29 ` Duncan
1 sibling, 0 replies; 3+ messages in thread
From: Duncan @ 2013-10-29 17:29 UTC (permalink / raw)
To: linux-btrfs
btrfs.nrb posted on Tue, 29 Oct 2013 15:19:19 +0000 as excerpted:
> Hi, I would be pleased to get some help after I have looked and not
> figured out how this should work:
>
> Summary =======
> btrfs device add <LUKS encrypted container> <path>
> Returns - Inappropriate ioctl for device
> # btrfs --version
> Btrfs Btrfs v0.19
> # uname -a
> Linux 874-deb 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
[I've no particular personal knowledge on encrypted filesystem usage, but
this is a general reply...]
First, are you aware of the btrfs wiki and have you read its encryption
discussion (among other things)?
https://btrfs.wiki.kernel.org
Second, if you've read the wiki you know this already, but it's worth
repeating...
btrfs is still under heavy development and still labeled experimental.
As such, if you're running btrfs you are by definition testing an
experimental filesystem and should consider data reliability in that
regard. IOW, KEEP TESTED BACKUPS AND BE PREPARED TO USE THEM should your
btrfs tests go badly!
Further, every new kernel brings important fixes to known issues, and
anything older than two kernel series old is ANCIENT. Ideally, you're on
the latest stable kernel release at the OLDEST, and may well be running
mainline kernel rcs if not even the btrfs-next patch-set. (Personally, I
run a mainline git kernel, but don't normally update to the development
kernel until after rc1, but try to get to it before rc3, so if I notice
any regressions I can file bugs with time to have them fixed before
release.) Run anything older and not only are you very literally
needlessly risking your data on known bugs that are already fixed, but if
you do catch a bug and report it, your reports will be less useful
because your kernel is so old.
For btrfs testers, kernel 3.2 is "ancient as the hills!" There are
reasons people might want to be conservative and run older kernels, but
they really aren't compatible with the reasons people would want to test
new and potentially unstable filesystems such as btrfs. Please choose
one or the other, and if you're going to test btrfs, do so with a current
kernel, currently meaning a post-3.11.5 stable series kernel at the
oldest as I believe it had some critical btrfs patches, or 3.12 release
cadidates or live-git, since 3.12 is very close to release now.
Similarly but not /quite/ as critical, btrfs-progs v0.19 is /old/. Even
v0.20-rc1 is from late last year, IIRC, and according to the version
string I have here[1], 358 commits behind current. btrfs-progs
development policy is to keep the git master branch "release ready" and
do actual development in other branches which are only merged when
they're considered ready, so running "git-master" of btrfs-progs, updated
weekly or no less than monthly, should be your best and safest option.
---
[1] Btrfs-progs here, live-git updated less than a week ago, tho from
memory the latest commit was back in July or so:
btrfs --version
Btrfs v0.20-rc1-358-g194aa4a
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 3+ messages in thread