New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider official Btrfs support in R4.0 #2340

Open
andrewdavidwong opened this Issue Sep 29, 2016 · 7 comments

Comments

Projects
None yet
6 participants

@andrewdavidwong andrewdavidwong added this to the Far in the future milestone Sep 29, 2016

@andrewdavidwong andrewdavidwong changed the title from Consider official Btrfs support in Qubes to Consider official Btrfs support in R4.0 Sep 29, 2016

@nrgaway

This comment has been minimized.

Show comment
Hide comment
@nrgaway

nrgaway Nov 29, 2016

Here are my experiences with BTRFS and issues I have run into that may want to be taken into consideration when considering adding full support. I use BTRFS for most of my systems except QubesOS.

For the first year or two I used BTRFS with QubesOS. During that period I was building and testing many templates I kept running into issues with the disk becoming full due to COW which resulted in needing to run a balance every week or two. It becomes a PITA to fix a system when all blocks had been allocated resulting in a disk full message. but I have written scripts to do so.

I found the best option when working with BTRFS was to disable COW for the virtual machine images as recommend for virtual machines which then one loses the ability to quickly snapshot any images. I figured then there was no benefit to using BTRFS if I did not want to actively balance the system and disabled COW so I have been running with the defaults for the last year or so.

nrgaway commented Nov 29, 2016

Here are my experiences with BTRFS and issues I have run into that may want to be taken into consideration when considering adding full support. I use BTRFS for most of my systems except QubesOS.

For the first year or two I used BTRFS with QubesOS. During that period I was building and testing many templates I kept running into issues with the disk becoming full due to COW which resulted in needing to run a balance every week or two. It becomes a PITA to fix a system when all blocks had been allocated resulting in a disk full message. but I have written scripts to do so.

I found the best option when working with BTRFS was to disable COW for the virtual machine images as recommend for virtual machines which then one loses the ability to quickly snapshot any images. I figured then there was no benefit to using BTRFS if I did not want to actively balance the system and disabled COW so I have been running with the defaults for the last year or so.

@csirac2

This comment has been minimized.

Show comment
Hide comment
@csirac2

csirac2 Nov 29, 2016

In my experience with server workloads and btrfs, shipping a system with file-backed VM storage on a snapshotted btrfs volume is a recipe for disaster.

I would suggest snapshots within the guests, and a mechanism to send/receive them to other storage. However, btrfs receive is completely unsuited to receiving data across security domains. A full solution would require btrfs receive running in a dvm attached to dedicated block device per domain. A btrfs dom0 shouldn't be required.

Curious to hear others thoughts on this.

csirac2 commented Nov 29, 2016

In my experience with server workloads and btrfs, shipping a system with file-backed VM storage on a snapshotted btrfs volume is a recipe for disaster.

I would suggest snapshots within the guests, and a mechanism to send/receive them to other storage. However, btrfs receive is completely unsuited to receiving data across security domains. A full solution would require btrfs receive running in a dvm attached to dedicated block device per domain. A btrfs dom0 shouldn't be required.

Curious to hear others thoughts on this.

@mfc mfc referenced this issue Jan 31, 2017

Closed

create GSOC 2017 Ideas List #2607

2 of 2 tasks complete
@ideologysec

This comment has been minimized.

Show comment
Hide comment
@ideologysec

ideologysec Feb 27, 2017

Benefits of btrfs: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

separate from being able to make backups of VMs on a system instead of individual level, and the deduplication features potentially helping template VMs take up even less space, booting into snapshots gives the ability to test potentially even more destructive/radical configuration changes, without worry of permanent harm.

Benefits of btrfs: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs

separate from being able to make backups of VMs on a system instead of individual level, and the deduplication features potentially helping template VMs take up even less space, booting into snapshots gives the ability to test potentially even more destructive/radical configuration changes, without worry of permanent harm.

@tasket

This comment has been minimized.

Show comment
Hide comment
@tasket

tasket Mar 2, 2017

I have been using Btrfs as my root and VM storage volume since Qubes R3.0 RC1. I've had one problem with "running out of space" which caused the fs to go into read-only mode. This was fairly easy to recover from. Since then I have kept at least 40GB "free" on the volume.

BTW, balancing doesn't seem to help a non-raid configuration. If anything, it reduced the amount of shared exents between files, leaving less free space.

I run with everything under COW and the performance is fine. I haven't bothered with setting NOCOW on images because I keep snapshots, which makes NOCOW files behave like COW anyway.

Anecdotally, Btrfs gets a bad rap because it has attracted early adopters who like to experiment and are very vocal (every alternative Linux fs suffers from this). But I understand that systematic testing of storage failure modes shows Btrfs to be much more reliable than Ext4 overall.

The plusses for Btrfs so far outweigh the negatives, especially after Kernel 3.17. The tools have also improved since then, and so has the performance. The only negative that bothers me is the free-space reporting; there has been improvement here and I expect it to get better.

tasket commented Mar 2, 2017

I have been using Btrfs as my root and VM storage volume since Qubes R3.0 RC1. I've had one problem with "running out of space" which caused the fs to go into read-only mode. This was fairly easy to recover from. Since then I have kept at least 40GB "free" on the volume.

BTW, balancing doesn't seem to help a non-raid configuration. If anything, it reduced the amount of shared exents between files, leaving less free space.

I run with everything under COW and the performance is fine. I haven't bothered with setting NOCOW on images because I keep snapshots, which makes NOCOW files behave like COW anyway.

Anecdotally, Btrfs gets a bad rap because it has attracted early adopters who like to experiment and are very vocal (every alternative Linux fs suffers from this). But I understand that systematic testing of storage failure modes shows Btrfs to be much more reliable than Ext4 overall.

The plusses for Btrfs so far outweigh the negatives, especially after Kernel 3.17. The tools have also improved since then, and so has the performance. The only negative that bothers me is the free-space reporting; there has been improvement here and I expect it to get better.

@rustybird

This comment has been minimized.

Show comment
Hide comment
@rustybird

rustybird Mar 3, 2017

@tasket:

I haven't bothered with setting NOCOW on images because I keep snapshots, which makes NOCOW files behave like COW anyway.

IIRC btrfs has an internal mode called COW1 or similar, which is causes "the least possible amount of COW" and is used automatically in this situation (snapshotting NOCOW files).

rustybird commented Mar 3, 2017

@tasket:

I haven't bothered with setting NOCOW on images because I keep snapshots, which makes NOCOW files behave like COW anyway.

IIRC btrfs has an internal mode called COW1 or similar, which is causes "the least possible amount of COW" and is used automatically in this situation (snapshotting NOCOW files).

@andrewdavidwong

This comment has been minimized.

Show comment
Hide comment
@rustybird

This comment has been minimized.

Show comment
Hide comment
@rustybird

rustybird Jan 23, 2018

I've opened pull request QubesOS/qubes-core-admin#188 - "file-reflink, a storage driver optimized for CoW filesystems".

I've opened pull request QubesOS/qubes-core-admin#188 - "file-reflink, a storage driver optimized for CoW filesystems".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment