BTRFS?

[johny...@sigaint.org]

Has the Qubes team ever considered the use of btrfs?

https://en.wikipedia.org/wiki/Btrfs

It's been the default root FS for Suse since 2012:

https://www.linux.com/news/suse-linux-says-btrfs-ready-rock

While reading about its features (and using it) it seems like it would be
especially well-suited as a base for Qubes, giving unlimited snapshots,
nested overlays/unions (seeds), rollbacks, subvolumes, sparse files, plus
easy adding/removing of disks, raid, space balancing, and greater
reliability (with the raid and checksum of metadata/data). A win/win
situation.

It would make the template implementation a lot simpler, faster, and more
flexible. Instead of .img files, you'd just have subvolumes (and use of
seeds/unions). It seems like a more elegant, flexible, and extensible
solution.

Even doing things like multi-level templates would be possible (although
for root, I think package management would be problematic with more than
one level).

Cloning a given template or an appvm would be instant and require zero
disk space (due to the innate copy-on-write nature of btrfs) rather than
taking many minutes and doubling the disk usage. The only space used by a
cloned template/vm would be what was eventually modified. Booyeah.

If used as a rootfs, even without any further template integration, the
deduplication feature should automatically bring the same disk savings.

It also offers self-healing, online checking/shrinking/growth,
"deduplication" of blocks with the same content, ..., the list goes on.

The related btrfs support utility "Snapper" also seems like it would fit
in very nicely with Qubes:

https://wiki.archlinux.org/index.php/Snapper

Suse automatically creates a snapshot whenever packages are installed, so
it's easy to rollback any undesired changes. Again, that would be a great
feature for templates.

You can even convert an ext4 system to btrfs, and keep both available,
since btrfs keeps the data blocks in a compatible way and puts it metadata
in other unused space. It makes the existing ext4 metadata a separate
btrfs subvolume, you can later delete if you choose--very slick. (Or
similarly, you can revert to ext4-only as easily.)

I'm starting to use BTRFS for all my non-root/non-user devices, and I'm
loving it. The private.img/volatile.img structure seems primitive by
comparison. :)

I realize the ext* code is probably considered more mature, stable, and
safe for dom0, but btrfs seems to have been put through its paces quite
well over the years (and I'm sure ext4 itself has been having a lot of
code changes over the years, possibly making it no more secure than
btrfs?)

(I haven't checked if the Qubes install allows it as an option for root.
Even if it does allow its basic use, going further and leveraging the
seed/subvolume/snapshot for templates/appvms is the more exciting part to
me.)

I realize such a change would be non-trivial, but it does seem like a
natural way for Qubes to evolve.

Thoughts?

JJ

[johny...@sigaint.org]

> Has the Qubes team ever considered the use of btrfs?

I do see Qubes does indeed support btrfs as a root fs during install. Cool.

JJ

[Chris Laprise]

On 09/22/2016 01:05 PM, johny...@sigaint.org wrote:
> Has the Qubes team ever considered the use of btrfs?
>

Qubes tools will even utilize btrfs reflinks where possible, so hardly
any extra space is used when you clone a template or other vm.

Chris

[se...@redhat.com]

Now that's cool, how do you enable that? Just install Qubes with btrfs root vol?

[Chris Laprise]

Qubes uses a variation on the copy command that causes Linux to do it
whenever possible. It's not a condition of installation or a setting or
anything like that.

Chris

[Connor Page]

I have root, home and var as subvolumes on a btrfs volume. I intended to create snapshots before updates. The tricky bit was to put it on a LUKS partition as somehow the installer encrypted only the swap partition. Maybe it was my fault, not sure now. Anyway, if you do it check that it is on top of an encrypted partition. If not, you're in for some practice in manipulating btrfs volumes and manual setup of dm-crypt ;)

[Connor Page]

In fact, I think the right question is "Will Qubes 4 be compatible with btrfs root if vm storage is expected to reside on a LVM thin pool?"

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 22, 2016 at 03:56:57PM -0700, Connor Page wrote:
> In fact, I think the right question is "Will Qubes 4 be compatible with btrfs root if vm storage is expected to reside on a LVM thin pool?"

This is a good question. The new storage handling is flexible enough to
allow writing a module to handle btrfs even better than in Qubes 3.x.
But it is unlikely that we'll manage to write such module for 4.0. If
someone would contribute such module, then yes - it will be supported.
Otherwise, probably somehow around 4.1 or later.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX5GVwAAoJENuP0xzK19csk+8H/iTHdf8HHg1hdegkOomh4Mip
yX65o+td3tDgpaODsZSjmAYPO/tIHkFPqheuHb6Hm+KvUvmplbh6b49T3A+ZYZS0
Fvsq29znmxqV7Xx/AZ/hmmIXjVEqs4ZYfmBWEzC8Oke91PLjMoMfcxvfCEbbDn0S
z5jYqiK0Ld3qligwzWTqj7Na/tAUeXZC4vAEZfyq5XtPsMEIpMniG4CGptLUBcht
x82ZbKBtl2oYA25gb2g+mK/KE5z2yQMVbeuxisMYUGsnmU0Tu7tfFa87TaDuBwgD
1qC8x8YCCJxAo9pkGQ/atjNDyV7N/HJYDfKCcursooti1F0td7vKzDw3aqi++mI=
=oY6G
-----END PGP SIGNATURE-----

[johny...@sigaint.org]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, Sep 22, 2016 at 03:56:57PM -0700, Connor Page wrote:
>> In fact, I think the right question is "Will Qubes 4 be compatible with
>> btrfs root if vm storage is expected to reside on a LVM thin pool?"
>
> This is a good question. The new storage handling is flexible enough to
> allow writing a module to handle btrfs even better than in Qubes 3.x.
> But it is unlikely that we'll manage to write such module for 4.0. If
> someone would contribute such module, then yes - it will be supported.
> Otherwise, probably somehow around 4.1 or later.

4.0 will be less flexible in this respect?

LVM thin volumes sound interesting (just read up on them today) and handy
for allocation, but they'll be mandatory for VM storage??

(Again, as mentioned in my earlier post, btrfs seems like it would meet
the same needs and then some.)

Why is it that so many things I hear about 4.0 are concerning to me?

I realize one must make sacrifices and architectural choices in the name
of progress.

But so far what I know of 4.0 is that it won't run on any of my PCs, it
won't (initially at least) support btrfs root, and the "decomposition"
sounds like it's going to spread configuration stuff in various places
rather than in one spot, the Qubes Manager (well, and the menu), where
they're generally very easy to find.

(There was something else that didn't sit well with me, but it escapes my
feeble mind at the moment. Might have been something to do with hardware
or processor requirements.)

I know there are some incredibly talented people working on Qubes, and a
great community surrounding it, so my fears are probably largely
unfounded; but I'm a bit afraid to invest in fully settling into and
committing to a system (which has been great so far), if the next major
release won't work for me.

Once 4.0 comes out, what happens to 3.2? Will it be supported for awhile,
moved forward at all, or just marked as deprecated/EOL'd and more or less
abandoned?

JJ

[Franz]

Once 4.0 comes out it will be beta for some time and people will be discouraged of using it for production, as happened for past releases. But look here for an idea of support of previous releases: https://www.qubes-os.org/doc/supported-versions/

Best

Fran 

JJ

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/429588c1db7fa0d2df95a73160c305e5.webmail%40localhost.

For more options, visit https://groups.google.com/d/optout.

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Connor,

> The tricky bit was to put it on a LUKS partition as somehow the
> installer encrypted only the swap partition.

https://github.com/QubesOS/qubes-issues/issues/2294 has a workaround.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJX5OYjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfR4UP/R8OxIfFI7JyeIW6gazWUEkq
IBdlvShyY5piOKSQO5RrEpcS5GXHjPPN1HqPn1Bt6FFQln5MAKkQsD6AaPE8nrjD
OHzYU/G3fgXoPPJy8nupA3SANatESdKV+b2/JWP0o0+9/7HAYgzykeGlfaoa6BtH
UuLHBVloagCaVKLjwX61KXHzf5Q+PJTm1ZAF2f8b9vY1vNPPJ+QKvXXr89n76p7W
McQTVTrLuSzTLLL2KFXxC2uMuIlO1qxYDifUrHO1f//CmuF9XGP4pGLIfVigodbg
We+1+2FbUqB6oB/WTHGLvbXhdrdgJHcZn7iUyXIbKcmncgo1wFZ0RYFq/rjzpCkX
b3gyYTEBxBLj4AbIc28sqJm8bUjpinWAzWOv4j0dHKQqnBXX2N6YrCSsOPFkKpuv
2fGjIryyS1pPktpYS4Evv/mDquusnOIAqnEooNmz2MaC9kd6v2/Kl9IHpbXX9bSd
MfIVaiAuWhFaRe9SUW4kIG5+dIEMkBCz2kNImdwfH2rNLOGTU2BvfcfvbpKmOxJy
QDHKU5WixixM6KtuO9Gvh/UW9nT36RPtn2+1nev/HztDbTzItSBwqHhXCXUtfM9p
weLEntmvVdQCLoKN+tRBd9NNiC+jlZbZtkmzUasi2GzL5japwrn42OeGlz0oSlh/
wvwrGWyDVaYlPxzN6Lye
=7Jna
-----END PGP SIGNATURE-----

[Connor Page]

Thanks Rusty. People should be aware of this. I think I did reclaim all space but fiddled too much with the settings. Anyway, it was a good excercise, I learned about btrfs, LUKS and dracut, that wouldn't happen otherwise.

[Chris Laprise]

On 09/22/2016 07:12 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, Sep 22, 2016 at 03:56:57PM -0700, Connor Page wrote:
>> In fact, I think the right question is "Will Qubes 4 be compatible with btrfs root if vm storage is expected to reside on a LVM thin pool?"
> This is a good question. The new storage handling is flexible enough to
> allow writing a module to handle btrfs even better than in Qubes 3.x.
> But it is unlikely that we'll manage to write such module for 4.0. If
> someone would contribute such module, then yes - it will be supported.
> Otherwise, probably somehow around 4.1 or later.
>
> - --

You realize that some of us have been happily using btrfs features with
Qubes in a way that produces better work flows?

If ITL desires a modular storage layer, wouldn't the best approach be to
offer a general image file module *first* to emulate the current
architecture? That way, people can continue to have the same storage
choices and backup procedures they already do.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

File backend is also available, but we haven't added new features to it
(like multiple snapshots etc).
Probably it could be easily extended to proper btrfs module (for example
by dropping dm-snapshot over files and simply use cp --reflink=always).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX5RlQAAoJENuP0xzK19cs4aoH/05E83Jvm/cfoD8ZHmTRjRfF
1fhgf4BK1ErC38Vt2HlHjTM7aXO84uRrLI7t+gRkJ14KIPu+JAWh7PSwaTummI7j
MH3EYNNEW/dMhm3eODAeLygFx78uhSzBTta0Y84eboe/uO/pLF0DRF2IwMSHOhhc
UVLyRTD/rlJ/0Um95PV8XYd0ZqOyFNgh208yrB36YaxDxlTxeLdHijKsltjqYggh
Z9C+MRwUm1SbPZYHjVMd8FmqJwy8R3dVJcqQzIM1jnO8B5bVULBOYSCxFGO8pX0d
BC6qu92j1nFFELrUDhK/LZtuxbV0P8QMfP//cBAHM9G9Si3+Mjfu1Wgm6hkADCI=
=+F6s
-----END PGP SIGNATURE-----

[Chris Laprise]

Good to know there is a file back end.

I also was thinking about having qvm-backup reference a particular
'backup' pool which points to a subvolume containing all the vms the
user wishes to backup; Then differential backups could be done quite
easily with 'btrfs send' without a lot of overhead. And vms could very
easily be moved in/out of the backup pool/subvolume pairing.

But that may be too filesystem-specific for the new storage layer.

Chris