Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

[Jorge Peixoto de Morais Neto]

Hi.  I own a Dell Inspiron 5570 laptop with 1 TB SATA internal HDD, a
new 250 GB NVMe SSD¹, 16 GiB RAM and an external 1.5 TB USB3 HDD.  I
seek reliability, durability, performance and power efficiency.

* Doubts
** Strong compression during install
For lifetime and space saving, I intend to install Debian to the SSD
with compress-force=zstd:12, but after installation adopt compress-
force=zstd.  Installation will be slow---I'll do something else while
the installer works---but the installed system will be efficient, right?

** HDD Compression
Both HDD have a lot of already-compressed data: videos, audio, photos,
compressed archives and disk images; `compress-force' would force
Btrfs to recompress it all, only to discard the recompressed data and
store the original.  Therefore compress=zstd:4 would be better, right?

** Fragmentation
Is the [Gotchas][] article accurate on fragmentation?

[Gotchas]: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

How should I address fragmentation on my laptop?  I do use Mozilla
Firefox (and GNU IceCat), ungoogled-chromium, GNOME and Evolution.  I
intend to put them all on the SSD.  Should I mount with autodefrag, or
would it decrease SSD lifetime?  Would it be better to manually defrag
these databases (not the whole partition) once in a while?  Or should I
seek application-specific means to defrag/compact their databases?

I also have a QEMU-KVM VM with a qcow2 disk image currently weighting 24
GB.  Should I convert the qcow2 image to raw format?  Or should I
convert it to a new qcow2 image with the nocow option?  I do not use
disk encryption and I rarely snapshot the VM disk.

* More context
I do weekly duplicity backups to external 1.5 TB USB3 HDD.  I'll start
also daily rsyncing some of the SSD data to the SATA HDD.

The SSD will have 50 GB extra over provisioning and a 200 GB partition,
besides the special UEFI partition.  The SATA HDD will start with 16 GiB
swap partition then a big partition.  I'll put system and /home on the
SSD but all XDG user dirs² on the HDD, and tmpfs on /tmp.  All three
drives will have Btrfs with space_cache=v2, noatime, zstd compression
and reasonable free breathing space.

I use Gnome and:
- GNU Emacs
- notmuch and offlineimap (I may switch to mbsync)
- GNU IceCat, Mozilla Firefox and ungoogled-chromium
- Gajim and GNU Jami
- Evolution
- Gnome Boxes or Virtual Machine Manager running a QEMU-KVM VM with
  2 GiB RAM and one qcow2 disk image currently weighting 24 GB.
- mpv
- Nextcloud (always running but rarely syncing changes)

I use zswap:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet zswap.enabled=1 zswap.zpool=z3fold
zswap.compressor=lzo-rle"

I use Debian stable with only official repositories, including
bullseye-backports.  I manually installed GNU Guix package manager and
have 163 packages on main Guix profile.


* Footnotes
¹ A 250 GB WD Blue SN550 rated for 150 TBW.
² See the xdg-user-dir manpage.

Kindest regards,
  Jorge

Re: Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

[Vadim Akimov]

Hi!

On Mon, 20 Dec 2021 at 12:11, Jorge Peixoto de Morais Neto
<jpeixoto@stj.jus.br> wrote:

> For lifetime and space saving, I intend to install Debian to the SSD
> with compress-force=zstd:12, but after installation adopt compress-
> force=zstd.  Installation will be slow---I'll do something else while
> the installer works---but the installed system will be efficient, right?

From my limited experience, it would be better installing at some
(extra) HDD in "normal" mode and then copying everything to newly
formatted btrfs volume with all options as you like. After that, you
do usual 'chroot, grub-install' thing et voila.

> I also have a QEMU-KVM VM with a qcow2 disk image currently weighting 24
> GB.  Should I convert the qcow2 image to raw format?  Or should I
> convert it to a new qcow2 image with the nocow option?  I do not use
> disk encryption and I rarely snapshot the VM disk.

Also from my experience, it's better not to use btrfs for qemu images
at all. If you have to, use raw file format AND prepare image file
like this:
1. touch filename.img
2. chattr +C filename.img
3. dd if=old_img_file.img of=filename.img
That ensures the file will be in 'nodatacow' mode, i.e. data in it
will always be inplace without CoW updates.
Even with such file you'll get synchronous writes in the VM 3-4 times
slower than you'd have with image on ext4.
Not doing 'nodatacow' exercise makes them even slower than that and
degrading over time.

By speaking 'synchronous writes' I mean even the simple things as
doing 'apt upgrade' inside VM. It really becomes slower with image on
btrfs.

> The SSD will have 50 GB extra over provisioning and a 200 GB partition,
> besides the special UEFI partition.  The SATA HDD will start with 16 GiB
> swap partition then a big partition.  I'll put system and /home on the
> SSD but all XDG user dirs² on the HDD, and tmpfs on /tmp.  All three
> drives will have Btrfs with space_cache=v2, noatime, zstd compression
> and reasonable free breathing space.

I'd keep swap on HDD for all times except when swap is extensively
used due to real memory shortage. In all other times swap could nicely
sit on HDD dumping some really not used memory pages in the
background. And anyway, you still can have swap in a file over btrfs,
no need for separate partition.

Re: Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

[Jorge Peixoto de Morais Neto]

Hello,
On Mon, 2021-12-20 at 13:29 +0300, Vadim Akimov wrote:
> From my limited experience, it would be better installing at some
> (extra) HDD in "normal" mode and then copying everything to newly
> formatted btrfs volume with all options as you like. After that, you
> do usual 'chroot, grub-install' thing et voila.

Is that experience from before Bullseye?  I heard that the Bullseye
installer has better Btrfs support.

> Also from my experience, it's better not to use btrfs for qemu 
> images at all.
> [...]
> Even with such file you'll get synchronous writes in the VM 3-4 times
> slower than you'd have with image on ext4.

Does Btrfs unsuitability to QEMU VM images relate exclusively to
synchronous write *performance*, or does it also harm SSD lifetime
(assuming nodatacow and raw format)?  I intend to give my VM a second
disk image.  One image will be on the SSD (holding system files) and the
other on the SATA HDD (holding user files).  The NVMe SSD is probably
fast enough that the VM will have overall good performance even with the
synchronous write slowness you mentioned; but would it excessively wear
the SSD?  Do I have to create an ext4 partition on the SSD just for the
QEMU VM disk image?

> you still can have swap in a file over btrfs, no need for separate
> partition.

I am aware Btrfs has official support for swap files (with some
restrictions), but is it reliable, efficient and light on the SSD
lifetime?  The Debian wiki recommends against swap file on Btrfs
(although some parts of Debian wiki are visibly outdated).

Thank you for your help!

Kindest regards,
  Jorge

Re: Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

[Vadim Akimov]

Hi!

On Mon, 20 Dec 2021 at 16:45, Jorge Peixoto de Morais Neto
<jpeixoto@stj.jus.br> wrote:

> Is that experience from before Bullseye?  I heard that the Bullseye
> installer has better Btrfs support.

This is my experience moving from ext4 to btrfs on several laptops,
desktops and servers. Probably your distro has the support right
enough for you, I don't know. If it doesn't, however, you can always
redo it the proper way afterwards.

> Does Btrfs unsuitability to QEMU VM images relate exclusively to
> synchronous write *performance*, or does it also harm SSD lifetime
> (assuming nodatacow and raw format)?  I intend to give my VM a second
> disk image.  One image will be on the SSD (holding system files) and the
> other on the SATA HDD (holding user files).  The NVMe SSD is probably
> fast enough that the VM will have overall good performance even with the
> synchronous write slowness you mentioned; but would it excessively wear
> the SSD?  Do I have to create an ext4 partition on the SSD just for the
> QEMU VM disk image?

Sorry, I haven't got any spare SSDs to perform my tests on them.

> I am aware Btrfs has official support for swap files (with some
> restrictions), but is it reliable, efficient and light on the SSD
> lifetime?  The Debian wiki recommends against swap file on Btrfs
> (although some parts of Debian wiki are visibly outdated).

AFAIK kernel uses file swap as a list of extents on the disk not
accessing FS for the IO. Therefore, btrfs is perfectly OK for file
swap, provided the file is 'nodatacow'.

Re: Recommendation: laptop with SATA HDD, NVMe SSD; compression; fragmentation

[Matthew Warren]

> Does Btrfs unsuitability to QEMU VM images relate exclusively to
> synchronous write *performance*, or does it also harm SSD lifetime
> (assuming nodatacow and raw format)?  I intend to give my VM a second
> disk image.  One image will be on the SSD (holding system files) and the
> other on the SATA HDD (holding user files).  The NVMe SSD is probably
> fast enough that the VM will have overall good performance even with the
> synchronous write slowness you mentioned; but would it excessively wear
> the SSD?  Do I have to create an ext4 partition on the SSD just for the
> QEMU VM disk image?

I was running with VM images on an SSD formatted with btrfs with COW
and didn't see much in the way of performance issues, but they weren't
disk-heavy VMs in the first place. I did have an issue with
fragmentation though, so I'd recommend storing them on a separate
partition formatted as either xfs or ext4.

Matthew Warren

On Mon, Dec 20, 2021 at 7:48 AM Jorge Peixoto de Morais Neto
<jpeixoto@stj.jus.br> wrote:
>
> Hello,
> On Mon, 2021-12-20 at 13:29 +0300, Vadim Akimov wrote:
> > From my limited experience, it would be better installing at some
> > (extra) HDD in "normal" mode and then copying everything to newly
> > formatted btrfs volume with all options as you like. After that, you
> > do usual 'chroot, grub-install' thing et voila.
>
> Is that experience from before Bullseye?  I heard that the Bullseye
> installer has better Btrfs support.
>
> > Also from my experience, it's better not to use btrfs for qemu
> > images at all.
> > [...]
> > Even with such file you'll get synchronous writes in the VM 3-4 times
> > slower than you'd have with image on ext4.
>
> Does Btrfs unsuitability to QEMU VM images relate exclusively to
> synchronous write *performance*, or does it also harm SSD lifetime
> (assuming nodatacow and raw format)?  I intend to give my VM a second
> disk image.  One image will be on the SSD (holding system files) and the
> other on the SATA HDD (holding user files).  The NVMe SSD is probably
> fast enough that the VM will have overall good performance even with the
> synchronous write slowness you mentioned; but would it excessively wear
> the SSD?  Do I have to create an ext4 partition on the SSD just for the
> QEMU VM disk image?
>
> > you still can have swap in a file over btrfs, no need for separate
> > partition.
>
> I am aware Btrfs has official support for swap files (with some
> restrictions), but is it reliable, efficient and light on the SSD
> lifetime?  The Debian wiki recommends against swap file on Btrfs
> (although some parts of Debian wiki are visibly outdated).
>
> Thank you for your help!
>
> Kindest regards,
>   Jorge
>