Is there a (recommended) maximum size for a qube disk image?

Background info: I want to use 2 or 3 offline qubes, each with up to 1 TB of data. Does it make sense to store the data within a qube or are there other / better ways to handle this?

Thatā€™s fine in principle. Depending on your usage patterns inside the qube you might have to deal with fragmentation leading to performance issues such as longer and longer qube startup or shutdown delays, which is relatively easy to remedy if the qube is stored in a file-reflink pool (because Btrfs/XFS have defragmentation tools) but trickier for LVM. Itā€™s often an issue with blockchain full node implementations, but probably not so much if youā€™re doing less write intensive stuff in your offline qubes.

1 Like

Thanks a lot for your answer! Good to know that the size should be fine.

So it seems that Btrfs would be a better choice than the default LVM when installing Qubes OS? On the other hand, since Iā€™m new to Qubes OS, I would prefer to stay with the default for now. Would that be a big disadvantage?
(Maybe there is no general answer to this and I should just try it out. But Iā€™m also interested in the experiences of other people.)

Itā€™s hard to predict. My vague sense is that (in a Qubes OS context) Btrfs may be more prone to fragmentation per se, while LVM may be more affected in practice by fragmentation if thereā€™s still ā€œtoo muchā€ of it (i.e. having that actually result in severe performance problems, possibly depending on the SSD hardware somehow). I donā€™t have much day-to-day experience with LVM though, and none with LVM storing terabyte range qubes.

2 Likes

Thanks again for your answer!
I guess Iā€™ll try LVM first and if that doesnā€™t work well, reinstall Qubes OS with Btrfs.

This is a version of what Iā€™ve been doing for years.

  1. Have a Kaisen Standalone HVM template.
  2. When you create an AppVM use Kaisen first. Use GParted to format xvdb to loop btrfs. Use gnome-disks to take ownership of xvdb.
  3. Shut down the VM and switch to a different Template.

Iā€™ve been a torrent freak for years and I keep xvdb (well estimated in advanced and do not change it) between 40-80GB. You can actually see from size of file and size on disk (Caja properties) who is a master and who is an impersonator (very relevant to iso).

Can you elaborate a bit more how this answers my questions? I donā€™t know Kaisen and didnā€™t intend to use torrent, so Iā€™m a bit confused ā€¦

  1. Download Kaizen ISO.
  2. Create a new TemplateVM kaisen. Qube-new qube-noTemplate.
  3. Go to settings of the new template and boot from kaisen iso and install.
    It will not have gnome-disks but it does have gParted. Follow the instructions that I gave before.

It really doesnā€™t. The in-qube filesystem on the ā€˜privateā€™ volume (ext4 by default) is not particularly related to your question of how large that volume can be (at least not in the low terabyte range) nor to my response about dom0 storage layouts.

Even if someone wanted to use a different filesystem like Btrfs inside the ā€˜privateā€™ volume for whatever reason, thereā€™s no need to ā€œdownload Kaisen Linuxā€ or anything like that. The simple way would be to run e.g. mkfs.btrfs in dom0 on the uninitialized volume, i.e. before the first start of a newly created qube or after clearing it.

1 Like

Oh thatā€™s a good hint! I was already thinking of using Btrfs in a qube. I like the snapshot feature of Btrfs and use it on my current desktop Debian to make hourly snapshots between the backups.

There are definitely benefits to using Btrfs on the volume, like the ability to create reflinks inside the qube too. Word of warning though, itā€™s a very uncommon setup, and a few things may require manual user intervention. E.g. automatic resizing of the filesystem after resizing the underlying volume only works with ext4 at the moment. CoW-on-CoW could be another performance concern, although less so if the inner filesystem is mounted with the nocow option. Iā€™m only mentioning this since you already seemed squeamish :wink: about the non-default nature of a Btrfs Qubes OS installation layout, which for comparison is fully supported (except the documentation is a bit more scattered across the forum).

1 Like

Thatā€™s the main reason why I prefer to stay with the defaults for now. It makes it easier to follow the main documentation while still learning the basics of Qubes OS.

Thanks for the warning. I will be extra careful when doing file system related changes. And of course always have good backups.

Thanks again for all the valuable information in this topic!

1 Like