Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?

[449f09c92]

Thank you for your clarification.
Also, many thanks for maintaining the file-reflink storage driver.

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/978266fe-07db-32a1-ba3f-23552919b298%40cock.li.

Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> Disabling CoW and hence checksums (besides being specific to Btrfs -
> file-reflink is filesystem agnostic)

Although for volatile volumes in particular it might be possible to
get away with (optionally, configured per-volume) attempting to set
the nocow flag and ignoring any failures. Not sure if even that is
worth implementing though, when it's already possible to configure a
dedicated nocow pool for those volumes.

The filesystem specificity I was thinking of is a bigger issue with
other (snap_on_start or save_on_stop) volume types. E.g. on Btrfs you
can only do a reflink ioctl if the source and destination files have
the same nocow status - a notion that is perfectly captured by making
the whole pool directory nocow or not, without any convoluted logic in
the file-reflink driver.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmQDUo5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/1/RAAjTRYmolu9M59E72mNyEbuQa9eKbPQVK1GVmeqmTOxsFkFUSUMTGYwdtK
yWKDotQapfj/5DpRFVUF8//95ylmVb0il2UGL4dfx/oOEEnJmen/BN0mA7xcti9e
VNzf2VFjqjAiYQVtCO75/ICcc5RjWa1U3XLyjDmwSZVH+EinDxENQBGl6IV2he2x
A89K5skgYPgtHT+4ppUe0DLScBgzpD9Jhd4TwvRs7tb/yG+sMK3qk+H97KcD7Ohv
jnGubMnY1ypoZ700EICxZn9b9pZRDV0zlJZ7lbwbpKEQq8Sf29UhwDDySqiHJGkU
+cGhzd4Uq75o3OLTEtr+blh4gERj5W+AfoWQ3yXqkohSeMAAXtnYfXNvFc5NftDQ
jf0hV3Kqz1VlnxDarQ1YtWziEp8+fP2yfWJx5vDj+OZJ6lPAxX93ozR1uXJ2+1I1
wtRpTFmH+VDB/n2R8ArdnSaqa9FBCK4tfp0ljXOXc1u7Bt5wCDsItm/z4591L7IL
9ZClUPb144qZtCX8Bwv8tMmUHferFL4u+aVvPP7dfRKgtpAGeRWURIHRqs2VfmAC
+3PfK4vPMvk5WJg1djk9y74EG1ihTuAPpzu2NwcHnnx5J8Amm34iPEI9xzV4hrfE
QM8wdQLflFimUh3r4la1xIDdHHZ5GoWjuqb/FVaUGYSZw+eCWdU=
=7lz0
-END PGP SIGNATURE-

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ZANSjtEd6cUEfaZX%40mutt.

Re: [qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

449f09c92:
> had to edit the relevant code to disable CoW when volatile.img is
> created

file-reflink doesn't inherently do CoW for volatile volumes, it just
defaults to whatever the underlying location on the filesystem does.
For Btrfs, to get nocow non-checksummed volatile volumes you could set
that up like:

# mkdir /var/lib/very-volatile
# chattr +C /var/lib/very-volatile
# qvm-pool add -o dir_path=/var/lib/very-volatile very-volatile file-reflink
# qubes-prefs default_pool_volatile very-volatile

Although it will only apply to *new* VMs created after that. To point
*existing* VMs' volatile volumes to the new pool, you'd currently have
to shut down qubesd and manually edit /var/lib/qubes/qubes.xml
(because the property is not exposed through 'qvm-volume config').

> Is there any reason why copy-on-write is enabled on volatile volumes
> that are mostly used as swap?

Disabling CoW and hence checksums (besides being specific to Btrfs -
file-reflink is filesystem agnostic) means losing protection against
on-disk bit rot. But storing data on the volatile volume doesn't mean
it is unimportant or even short-lived: It's not that unusual to have a
long-running VM with weeks of uptime. Corruption in its swapped memory
(or in diverged 'root' volume data, which too is stored on the
'volatile' volume) could be devastating.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmQDQg9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt86Og/+PufuJZNM8DcIfIOq1nMqqM8WP5NTF5j/7XyUGkMJYIQBk5O9rv01FNtK
ceOvWqGRPasHRU1WvCQmL5hrV2DndViNkjWJXW2AMxQgXUaR0lzR5yjTGwA3NmiL
orilLnW/zfgq+uBjdhsLSY/r8NAQQu2qYuPlzr3Ra0I96YGH9JG1N+5whXtI7vAF
IHvI6B1LgbQuS5CNp5E+5ewXmfSl3biw2QPaC/n07YDZbqFHUR701Oh+ZelqiYiZ
MAvSVlasTPo/8gJpLrjBtIw9hx2x/tzNuEE0bgXCQ3r0YAql084EO7JqV85QKikD
63X3U+2KrSiGHLppf2Q9IjS6JDT0Y7rdQUIdWeK3OFQX/8B/7eOe+lMUqMpDKAEo
8McMH/4jfdX6Kf/Z/tywOpVR2ioRi7xbgEejMfMIddNnEAPGvcXs5BTi+Azd4HR5
dvpQcFTrwS/VQ0pRbBVe0IfUDI1BwuTwD0xbij9zMBT+ZQ+S53Eu1y5XvAXlWrmd
PvueRhUK4Wef+Nrj+okDreDW4VZV927I4EDlceAK5srbrX4g62vDSidzmaj9u4O1
wCrHt3zgEyIbUsbWvu8dE31olTzt8gGX0bpZjVrHb4/ov75wVwBrRZSe2usMJw9N
XNlN6R5slFhJaq8OgKlUZQPEat6SlaoR04uqfP7CgrrzpLDpNL4=
=Suy+
-END PGP SIGNATURE-


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ZANByPUMlA4PLqW4%40mutt.

[qubes-users] Btrfs (file-reflink): Why is the CoW on a volatile.img enabled?

[449f09c92]

I have /dev/xvdc configured as a 10GB swap and had to edit the relevant 
code to disable CoW when volatile.img is created to avoid overloading 
dom0 by checksum calculation when swapping out occurs in the VM.


Is there any reason why copy-on-write is enabled on volatile volumes 
that are mostly used as swap? Just curious.


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/db2302d3-8a9b-3dd8-4b3f-96ba31e065c4%40cock.li.

Re: [qubes-users] btrfs for template/appvm

[donoban]

Hi,

On 12/12/20 1:36 AM, 'keyandthegate' via qubes-users wrote:
> I want to use btrfs for the snapshots feature in my appvms.
> 
> I know Qubes supports btrfs for dom0:
> https://github.com/QubesOS/qubes-issues/issues/2340
> 
> 
> Does Qubes support using btrfs in individual appvms?
> 
> If not is there some other way I can get snapshots? It would make me
> less afraid to make a mistake while using my computer.

Qubes creates a "snapshot" when you start a VM using reflink copies.

If you look at "/var/lib/qubes/appvms/" (or other btrfs pool)
on dom0 you will see some "private.img.XX@-XX-". This files are
snapshots from that date before the AppVM was started.

Currently you can use 'qvm-volume' for revert some image to an older
state but you will lose the present image. If you want to start an older
image you can create a new VM and overwrite his 'private.img' with some
"private.img.XX@-XX-".

Hopefully in the future this could be improved, I would like to just
start a DispVM based in a snapshot using few mouse clicks or a single
command.

In any case I recommend you to do regular backups ;)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/69433d29-a02b-5f94-86b4-420826c74b3b%40riseup.net.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] btrfs for template/appvm

['keyandthegate' via qubes-users]

I want to use btrfs for the snapshots feature in my appvms.

I know Qubes supports btrfs for dom0:
https://github.com/QubesOS/qubes-issues/issues/2340

Does Qubes support using btrfs in individual appvms?

If not is there some other way I can get snapshots? It would make me less 
afraid to make a mistake while using my computer.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/n-zCjtVD66DquYM302g2mGEt9l22COrptU1e5PVmBVKG-0q2WAhirsuzF8M7gSzW7xUf0w9oehg1PxJT2cfypl-AS_Uf11GBSld4qW_zFKM%3D%40protonmail.com.

Re: [qubes-users] BTRFS?

[Chris Laprise]

On 09/23/2016 08:00 AM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Sep 23, 2016 at 07:42:07AM -0400, Chris Laprise wrote:

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.

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).

- -- 


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

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c91f4586-a8a3-255d-f5fb-d5a177e05355%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[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

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3b8adced-078d-8776-93b6-a212eed2e186%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[Franz]

On Thu, Sep 22, 2016 at 9:59 PM,  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.
>
> 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?
>

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+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@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.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAPzH-qCH2duRxvzUio4Dd7XRaexVnF0GAx5xnUf0N%2Bcv_H%2B%2B1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[johnyjukya]

> -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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@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.

Re: [qubes-users] BTRFS?

[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-

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20160922231248.GR31510%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[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?"

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/faba39bf-b1fb-4071-a361-a99a0dcf0366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[Chris Laprise]

On 09/22/2016 02:08 PM, se...@redhat.com wrote:

On Thursday, September 22, 2016 at 1:39:20 PM UTC-4, Chris Laprise wrote:

On 09/22/2016 01:05 PM, johnyju...@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

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


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

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/abe9a791-1a01-87cb-28b0-92b932caad46%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[sejug]

On Thursday, September 22, 2016 at 1:39:20 PM UTC-4, Chris Laprise wrote:
> On 09/22/2016 01:05 PM, johnyju...@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

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8030aad2-e53f-43b5-8b7a-c0ff744e4686%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] BTRFS?

[Chris Laprise]

On 09/22/2016 01:05 PM, johnyju...@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

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5650a036-675e-a335-10d8-bab71a6c1d15%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] BTRFS?

[johnyjukya]

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a7878e26a6480acbc6add8e18a73c303.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] btrfs vs lvm?

[Chris Laprise]

On 05/30/2016 11:35 AM, Rusty Bird wrote:

Bahtiar `kalkin-` Gadimov:

IMHO you should use LVM. Because btrfs is IMHO not mature enough. (Personal
anecdote warning) I used it for backups until the partion become read-only and
throw out of space warnings, for no obvious reason.

On Qubes 3.0, I had the same issue: More than a couple of dozen whole-fs
snapshots made the fs readonly. Booting a newer kernel and removing some
of the snapshots fixed it then.

Rusty



IIRC, kernel 3.17 and later are considered safe bets for btrfs.

Chris

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/574CA281.2020200%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.