fedora-40-minimal install - message about fstrim

[Boryeu Mao]

For the template install command on Qubes release 4.2.3

   sudo qubes-dom0-update qubes-template-fedora-40-minimal

I received a message that

   fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard operation is not supported

The template appears to be running normally, so perhaps this is a warning message.  Please advise if there is anything to be done or to watch out for.  Thanks.

[Rusty Bird]

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

Boryeu Mao:

> For the template install command on Qubes release 4.2.3
>
> sudo qubes-dom0-update qubes-template-fedora-40-minimal
>
> I received a message that
>
> fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard
> operation is not supported

Did you maybe mount a tmpfs at /var/tmp? That would explain fstrim not
working. It also wouldn't matter then.

> The template appears to be running normally, so perhaps this is a warning
> message.

Pretty much. The fstrim invocation was added to inform the underlying
storage (LVM Thin by default) of the filesystem hosting /var/tmp that
the space previously used for temporary image files extracted during
the installation process can be freed:

https://github.com/QubesOS/qubes-core-admin-client/commit/4a9b57f91fdf3a2b35a5cf707970d05bf9cadba7

But it doesn't affect the installed template.

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

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcOSxFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/oVg/8CBMUFKZf9qgpJF90En3S9SFOq5B3pr32MZptzeVaN0FjyQzObQgx0ctK
vN0kPrUzwe8Djrp7CzT/eiC1eOGEcEGTHxkd1SrgcL0vFg+/SFs4QuXKZSjNwz/v
u6eW5x0Q+eMVRpIIfuR+2ctJnsrmIRp/rheRj68kmGq13H+m3NkWL3Tpb6WJayDl
sSOHtAW73UvQoAAOgfLAI/SB3RGlyD10E3AcUWQalJ4p3OwV0j9V0HPWZ+7QkAja
s+miDY/bTqsXkDyDr6Jz8VPBoOtyy1cDVAS3DLCSN7rLT/Scn1zSYRiCZMEc6JdN
McUEMjK4Cr3MoikrMPhWoDzpdgtPCHnnt+hJKC4Bsvp0PLYXGdcqn0Gm3AT5RJ6r
qzWGu6Q5rHIy7V6c9TMt6I+Yg4vp2w+Y5dG4uZ2d9xBJmOLZCUBDaJD48/6MTFnX
Z6h19+HzNlZHkby3+0u9DKoAYXV96dOhsC2DK9oNqskmwbiKHlsaQMnjVtYq2LTl
OKcEl3Xo9hjNBBgaWgvfZBbqzyvTBXDr+fmYX0hEjpCcsdG5f2iiEoYdtE0B9Dzc
cx0ylY9rkK8alRUmxg/v+DsJ/yTWhDhud1GKdORWCWB/TxdIoNGkmdwcTNHJ0cHK
Mdfi2xR4ULDxdjvPbyJMwakn1yEvftIGS8/BuVeFuAzb4+7rJOU=
=9zLR
-----END PGP SIGNATURE-----

[Boryeu Mao]

On Tue, Oct 15, 2024 at 3:59 AM Rusty Bird <rust...@net-c.com> wrote:

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

Boryeu Mao:
> For the template install command on Qubes release 4.2.3
>
>    sudo qubes-dom0-update qubes-template-fedora-40-minimal
>
> I received a message that
>
>    fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard
> operation is not supported

Did you maybe mount a tmpfs at /var/tmp? That would explain fstrim not
working. It also wouldn't matter then.

 

It was the stock qubes-dom0-update, so all tmpfs operations are what the stock script would do, no manual tmpfs mount.

> The template appears to be running normally, so perhaps this is a warning
> message.

Pretty much. The fstrim invocation was added to inform the underlying
storage (LVM Thin by default) of the filesystem hosting /var/tmp that
the space previously used for temporary image files extracted during
the installation process can be freed:

https://github.com/QubesOS/qubes-core-admin-client/commit/4a9b57f91fdf3a2b35a5cf707970d05bf9cadba7

But it doesn't affect the installed template.

In the qvm_template_postprocess.py (which the above link points to), fstrim is called only if the root user does the template install.  So I'd need to figure out:  

(1) why is it that there is no need to free space in the lvm thin volume if a non-root user does the install

(2) how would a root-installed template be different from one installed by a non-root user

And if fstrim warning means the space didn't get freed as it should, then perhaps I need to keep an eye on lvm volume usage.

 

Rusty

Thank you very much for helping.

 

[Rusty Bird]

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

Boryeu Mao:
> On Tue, Oct 15, 2024 at 3:59 AM Rusty Bird <rust...@net-c.com> wrote:
> > Boryeu Mao:
> > > For the template install command on Qubes release 4.2.3
> > >
> > > sudo qubes-dom0-update qubes-template-fedora-40-minimal
> > >
> > > I received a message that
> > >
> > > fstrim: /var/tmp/tmpsd1ns61v/var/lib/qubes/vm-template: the discard
> > > operation is not supported
> >
> > Did you maybe mount a tmpfs at /var/tmp?

> [...] no manual tmpfs mount.

I assume you're seeing the same "not supported" message if you run:

$ sudo fstrim /var/tmp/

The only thing I can think of is that you have custom partitioning,
and the storage layer immediately underneath the filesystem hosting
/var/tmp/ is dm-crypt (unusual for an LVM Thin installation), and
dm-crypt has been mapped with discard disabled.

Your storage tree (showing discard support) can be printed with:

$ lsblk --output +DISC-MAX

> > https://github.com/QubesOS/qubes-core-admin-client/commit/4a9b57f91fdf3a2b35a5cf707970d05bf9cadba7

> In the qvm_template_postprocess.py (which the above link points to), fstrim
> is called only if the root user does the template install.

To me this looks like something that was missed in the move to
qvm-template:

Previously, qubes-dom0-update (which had to be run as root) would
install templates as normal RPM packages. I guess the logic to skip
fstrim for non-root users might have been put there to ease testing
the qvm-template-postprocess tool? CCing Marek

Then qvm-template was created (which like other qvm- tools usually
runs as a regular user) and now fstrim is skipped unless someone
happens to invoke qvm-template as root. Skipping seems like a bug, but
on R4.2 systems it's mitigated by the installer adding the 'discard'
mount option for the dom0 root filesystem, making fstrim redundant.
Except for people who installed via qubes-dist-upgrade or removed the
mount option. For those, there's still the systemd fstrim.timer that
should release the space to LVM, hopefully soon enough (weekly).

Finally, you've used qubes-dom0-update, which nowadays calls
qvm-template for template related stuff. For this, qubes-dom0-update
can actually be run as non-root, but you ran it with sudo, so fstrim
was *not* skipped. (Which then failed on on your system.)

> Thank you very much for helping.

Happy to. It's interesting :)

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

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcP1btfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/L3xAAjs5MdAVStMB33Dzahh6/oinggSp5fT4f+FFLSb3gKPrzLApi3OxKNnIp
0AX/lGjFftbRcVCrwvFV5vZxMp3wAAKn68htEmvqZ3QA0hSr3aHrnu0gnVCnyGUG
f0KEFmv1pluSB4Af0s5euJOq5Rocd2HxnfNNIDG+8rOZ6KRLBVpaQXzRP4ejTAsS
H8XVCeB182n7RveSheyrXXr+Z980WM/xz7Qg88Wsmgi47fkulJ4ZbI2GI4z9MVHl
q76pVvdKxotMCtNad3ii/tbJCGDHxacRsQhDPE36a6x+Mvgq/OlMJqbJWIBaD7VP
Pxzj33Nspy8CFf585w6l3INCHz+qV9YV6/Hb674HyGHsn4O/nHF+IecdqZb19O8P
XjsFK3FrW1kqxj3/5nMurZ6NrlWC2qFqCQcr9ALCodJQDFHfdComnnFu25krDmBd
vl/nSEwcLpMtrtl4AUrekbHTrlDDW/096+FJlE+TNmYbD7YEK7qBxipulGwCg6Jf
NBL47gbIAYISKY1L+YDY7jGhEYMMaUZy8T5P4uTHQ4Zhqa5oXRts4dtkuuvuWmBS
wDfKzSGrmr694C1HnSGuTWP/a5psi5YhrGcHWILct2Ix6oUn5Q80rMbttjNnpmWT
DgLjPdlAXrDvQErn09TLE/YJ4BW5ORcZSfeNBboff1AUKfRqvG4=
=+Iy5
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Maybe? You do need root for calling fstrim. And not calling it isn't
really huge deal, as you explain below. And it failing shouldn't
interrupt install anyway (subprocess.call, not subprocess.check_call).
But the error message indeed may be confusing.
Theoretically, sudo could be used for this call and that would be fine
in dom0, but possibly less so in a qube (yes, you can install templates
via Admin API from a qube), especially is passwordless-root package is
not installed...

> Then qvm-template was created (which like other qvm- tools usually
> runs as a regular user) and now fstrim is skipped unless someone
> happens to invoke qvm-template as root. Skipping seems like a bug, but
> on R4.2 systems it's mitigated by the installer adding the 'discard'
> mount option for the dom0 root filesystem, making fstrim redundant.
> Except for people who installed via qubes-dist-upgrade or removed the
> mount option. For those, there's still the systemd fstrim.timer that
> should release the space to LVM, hopefully soon enough (weekly).
>
> Finally, you've used qubes-dom0-update, which nowadays calls
> qvm-template for template related stuff. For this, qubes-dom0-update
> can actually be run as non-root, but you ran it with sudo, so fstrim
> was *not* skipped. (Which then failed on on your system.)
>
> > Thank you very much for helping.
>
> Happy to. It's interesting :)
>
> Rusty
>
>

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmcP3XgACgkQ24/THMrX
1yx0oAf8CmXQL/mm/vsPN57Xi8ySBEYFlu83001Nb+A0h/kMj049C7zjHD2NfHED
8m6X4Pe6klhcxobcfNBEH9bixRYiuFr4OugFm8CCuuxr/un5q2z7ms90ocUNPPc7
+mF6saxkQ/3u8mPDS9950waw+tqd7HiYIh2PNm0V7J3miZKJeEH4ctyP7eowhl5t
RxcaxINAL/Vq8kDj+EqJefxmSOYukdaPUNoh0KTh2/hJPTFZbv37zIbUBcBiJ4p7
/qlFP23/oz9fa0LcFl01qrmVxlAASq1tWsa1vcSgaZlwPw8MG8+1zL/XohR5nqis
/HSUFF870coKPhJrMV4iDm6tgqiK8g==
=cj8g
-----END PGP SIGNATURE-----

[Rusty Bird]

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

Marek Marczykowski-Górecki:

> Maybe? You do need root for calling fstrim. And not calling it isn't
> really huge deal, as you explain below. And it failing shouldn't
> interrupt install anyway (subprocess.call, not subprocess.check_call).
> But the error message indeed may be confusing.
> Theoretically, sudo could be used for this call and that would be fine
> in dom0, but possibly less so in a qube (yes, you can install templates
> via Admin API from a qube), especially is passwordless-root package is
> not installed...

Ah okay, that answers why not 'sudo fstrim'. Also, on file-reflink
systems, where the dom0 root filesystem is storing (possibly many
terabytes worth of) VM volumes, fstrim can take really long. E.g.
here on my main Btrfs system, which is otherwise quite fast:

# time fstrim /var/tmp/
real 4m29.240s

So now I'm thinking fstrim is overkill just to install a template.
Instead, maybe Salt or something could ensure that everyone (including
people who installed via qubes-dist-upgrade) has the 'discard' mount
option (or 'discard=async' for Btrfs, where that would be the default
on modern kernels if not overridden by 'discard[=sync]') unless a user
has explicitly added 'nodiscard'.

> > Then qvm-template was created (which like other qvm- tools usually
> > runs as a regular user) and now fstrim is skipped unless someone
> > happens to invoke qvm-template as root. Skipping seems like a bug,
> > but on R4.2 systems it's mitigated by the installer adding the
> > 'discard' mount option for the dom0 root filesystem, making fstrim
> > redundant. Except for people who installed via qubes-dist-upgrade
> > or removed the mount option. For those, there's still the systemd
> > fstrim.timer that should release the space to LVM, hopefully soon
> > enough (weekly).

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

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcP6Z5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9Xhw/8C+Z2O/1cINMgc3mQFDCNQSKDNhXAlgCVixNUrvMm9m+mdr/NMvL1euRd
ndD6KH+ud5u04qLHHghXvzRZVnHtyRiGgKQOpM8/1Q/7ifG843brS+ataUWh7+Z8
e7oNt5Y1FQrFeLQGCLU1r/OqTVPrUXDzEOCatnZMX2AgnJSf2JS6pEh3o3S27x3y
ZZFeGsWiII6mGaHq38TWxwpu7WSM2K2ldSBRQKAF4UaDrWhzD+AtpyK1UYXzDlpz
FWNAPd7ELpx/kFoIOatum2LkUncCMsK+3kgUW9cXUnD/fquG4YUJpTamO00rBp2W
2s2PIFHVZkkf26sytq2xFV/NwjkvQHyj+TT/LnWtPTdy6v3NmLxpWAlYnFy4Rz17
d0qViaXn26EctkYimXPaM5gvnmrLlDOlhvsDEf0ZMnLlCXlvXf9+N2c2FXjifkNZ
TVjOQmiMJj5/aNFw+S02rDQxAHydra5RiaK+G/XCQ0xSuhKEVm72UWJILutyFeic
MUYyf0KKJFKxSPI8O11MmJNzOYCKGQu2p4XkvwLtmuRqQZcPG+eGYHSh+qgpLjiB
4sSbqj7tnmMoIcNn9Ckh+04F/kYN/TJ5pjWvC6U9Cf0NRE0YVbv/K8mT5hrZqYFC
2WHqBBd2Sa5CTKsiZ3yrS7TPmyqco+fuDpQhSWYa+88W0BD175o=
=wetx
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Wed, Oct 16, 2024 at 04:28:14PM +0000, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > Maybe? You do need root for calling fstrim. And not calling it isn't
> > really huge deal, as you explain below. And it failing shouldn't
> > interrupt install anyway (subprocess.call, not subprocess.check_call).
> > But the error message indeed may be confusing.
> > Theoretically, sudo could be used for this call and that would be fine
> > in dom0, but possibly less so in a qube (yes, you can install templates
> > via Admin API from a qube), especially is passwordless-root package is
> > not installed...
>
> Ah okay, that answers why not 'sudo fstrim'. Also, on file-reflink
> systems, where the dom0 root filesystem is storing (possibly many
> terabytes worth of) VM volumes, fstrim can take really long. E.g.
> here on my main Btrfs system, which is otherwise quite fast:
>
> # time fstrim /var/tmp/
> real 4m29.240s

But that takes long only if there is really a lot of data to discard,
no? If there is fstrim.timer, there shouldn't be that much to discard
(can be some GB, but that shouldn't take this long). Is it different on
btrfs?

> So now I'm thinking fstrim is overkill just to install a template.
> Instead, maybe Salt or something could ensure that everyone (including
> people who installed via qubes-dist-upgrade) has the 'discard' mount
> option (or 'discard=async' for Btrfs, where that would be the default
> on modern kernels if not overridden by 'discard[=sync]') unless a user
> has explicitly added 'nodiscard'.

If anything, maybe the dist-upgrade tool could take care of it.

> > > Then qvm-template was created (which like other qvm- tools usually
> > > runs as a regular user) and now fstrim is skipped unless someone
> > > happens to invoke qvm-template as root. Skipping seems like a bug,
> > > but on R4.2 systems it's mitigated by the installer adding the
> > > 'discard' mount option for the dom0 root filesystem, making fstrim
> > > redundant. Except for people who installed via qubes-dist-upgrade
> > > or removed the mount option. For those, there's still the systemd
> > > fstrim.timer that should release the space to LVM, hopefully soon
> > > enough (weekly).
>
> Rusty
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmcP/Z8ACgkQ24/THMrX
1yxDMAf6AxXjfV5Cf7YAxw/QLYCX+yiOh1ehSyOVBh7jPVbFk//9wv6uwokmi98V
JN+yrxDrRIFleWqGDdJwIdB05jXo9Uv/PVZdFXPMnWymcje61i9FYsdvvBuUQ3WJ
cQEiCrotTAlRn94j2j5w5SZ5OxLLixwyDXrBZLCr2vzNZoPkjeQiWGQSHMFFLTC2
wBzvUc8lqPRE2yjig52coa7tG/d2UTQFJoxePX+CR8u2P46j4/AxFhUp2LDCo+3D
ZLuhY6aBOMMuoY8dB8r6SjKUxaKAYh6OdS6emf67KBvFkRSSpJQLY5PwulYAzPss
WGNOFWbpogffVVnTgtSZ4cZo3+QpsQ==
=O16W
-----END PGP SIGNATURE-----

[Rusty Bird]

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

Marek Marczykowski-Górecki:

> On Wed, Oct 16, 2024 at 04:28:14PM +0000, Rusty Bird wrote:
> > Also, on file-reflink
> > systems, where the dom0 root filesystem is storing (possibly many
> > terabytes worth of) VM volumes, fstrim can take really long. E.g.
> > here on my main Btrfs system, which is otherwise quite fast:
> >
> > # time fstrim /var/tmp/
> > real 4m29.240s
>
> But that takes long only if there is really a lot of data to discard,
> no?

# for i in 1 2 3; do time fstrim /var/tmp/; done 2>&1 | grep real
real 4m24.308s
real 4m34.060s
real 4m29.806s

I don't see anything in Btrfs tracking which unused blocks it has
already issued discards for. Or in ext4, but it doesn't matter with
the small ext4 dom0 root fs in an LVM Thin installation. So a large fs
that's neither almost empty nor almost full has to at least generate a
gigantic list of (due to fragmentation) probably rather small ranges
of blocks to be discarded in response to every fstrim and forward it
through the block subsystem (which I don't think is keeping track
either?) to the drive. Only after all of that overhead, I guess the
drive might respond faster if it had already done most of the work
last time.

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

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcQFxxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9SAg/9H9nFGZ2+3y4caIBouczAoNhWEavYHVeo0tbhOvbIdrbr1qPghbl/fJlV
6DyCbbn39cp9XIEqGCYI0GGS1h+X+RWu8ufCX6TZXUMcMzx+3Ye+WYOoZ3MAUCKv
qUh9hxQkmAe4YD5O9hBWTY/L6Uf+wrIWVp1rmunz1sHTccy1RorAKxHF44Zohuq1
rWBUfAaiROl8CSBzuBC0Qx+VvRfA4YiIS/5+bmY0eZjIDg5SUMVNvj8aXAWBljTB
eXHIZs97BmIeS+VDeKl/8jzDFEF4a4whA9U9n1POfSum1SdiuVgF7McKwz3tDgv+
1qqu8pWsI85vdNPjTWcecjN5ju7jMA4nwYOr30TND7qi0wA3elMEWRQGjxcobAmM
fN8++xA44XD8gpSr4fCUDfIb4E60vcUpTSc6NrQSfTWLK/W+OMow+9rOUyS0oO85
FTeZTcvuF54Wz1d38aGNc2YKmS8r8EVOCytzu5yEFFOFrm4E4lCYUM6A0rBgywaN
yQYI46s4LVX+bcV80p6glQXHUpB40nFJ1xTmk6Y6sWMbdf4DdrIwPRKLkGVSCcwU
6IAvrZnpx5NIH/6nXR9MgY9aSKpgT6ZFZj7BNAMj9V2S/2l+OoJ8JvZsuqNJ/+uf
3UWaA9mlrGoso+as76dK0I+KUqR9/Gm2vyX1IJQCfwRNcOQVltY=
=mp6H
-----END PGP SIGNATURE-----

[Rusty Bird]

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

'Rusty Bird' via qubes-users:

> Marek Marczykowski-Górecki:
> > On Wed, Oct 16, 2024 at 04:28:14PM +0000, Rusty Bird wrote:
> > > Also, on file-reflink
> > > systems, where the dom0 root filesystem is storing (possibly many
> > > terabytes worth of) VM volumes, fstrim can take really long. E.g.
> > > here on my main Btrfs system, which is otherwise quite fast:
> > >
> > > # time fstrim /var/tmp/
> > > real 4m29.240s
> >
> > But that takes long only if there is really a lot of data to discard,
> > no?
>
> # for i in 1 2 3; do time fstrim /var/tmp/; done 2>&1 | grep real
> real 4m24.308s
> real 4m34.060s
> real 4m29.806s
>
> I don't see anything in Btrfs tracking which unused blocks it has
> already issued discards for. Or in ext4, but it doesn't matter with
> the small ext4 dom0 root fs in an LVM Thin installation.

Actually ext4 does keep track:

https://serverfault.com/questions/1113127/fstrim-is-very-slow-on-xfs-and-always-return-same-value-unlike-ext4

> So a large fs
> that's neither almost empty nor almost full has to at least generate a
> gigantic list of (due to fragmentation) probably rather small ranges
> of blocks to be discarded in response to every fstrim and forward it
> through the block subsystem (which I don't think is keeping track
> either?) to the drive. Only after all of that overhead, I guess the
> drive might respond faster if it had already done most of the work
> last time.

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

iQKTBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcQHAJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt//lQ/9GtwhYOxlQCr1FMVt8jf6VSdogeZzWnErQO7ldaujc730hZcHgmbtincl
1Eo81cLy5gQ8fKzBoZ7qNhNd6VjvFJirnhHs6zqQKFCTbOs+FAM2pGViAEGLtT8r
BST11UoTcrN+RBBgnd5o1wP99G/8ZWPOkB/bTAYPb6ZmYlq+oikl7fG/GbeXXFZh
keHdjdiS1uutwA2Ip9pZTkCGuyUd4xy3Y9aHQm2OuuQeYln+ZUUMMeo1LqESWLl1
S1m4CRLLkN8l8StNkz3jf7605+hiyY+NPdbYMXlRl9HhxKugORMAsrzFFVkk+80h
rFrxz49JLp8Cg55X0cShZNYpfaH3eOGw7PS932B+6q0qrHkb7yhCATj2VxBVdCD+
JOzaflxC32XyXDVcJrrhhfwrwoqySBVo/HSZ3O9hhvWEV9CLe+KgivsR72Ryy+eF
n1d0CxjYHEN4qWRN0qTG/YatEJqkZ1bWdtG6rAQrRvkNOomPo3ikGpqw9WKnkhAN
xfCGnoxjNOkCDYyrqIBhRfVKjMldIlkNRnwGGKjLARJJ08Wjmt+fiGeNeOn4qXOK
jwElSeaui2nHOnje1nSxrIsIotwUIK/msFjbJ/lt7xjvna/CgftMPysztHhLrjZU
I6OuIun83nkQnGTy3aAU5ohEWGVhUCB6w3RxqzTv+bWdaucBfmA=
=PCuB
-----END PGP SIGNATURE-----

[Ulrich Windl]

Hi!

Of course if fstrim fails, it has the same amount of block to trim on the next run.

Ulrich

[Rusty Bird]

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

Ulrich Windl:

> Of course if fstrim fails, it has the same amount of block to trim
> on the next run.

But if 'fstrim --verbose' prints a number of trimmed bytes at all and
not an error, then apparently the trimming didn't fail (this time).

To test the different behavior of filesystems like ext4 that keep
track of already discarded blocks, and filesystems like XFS and Btrfs
that don't (or not fully), here's a little script:

https://gist.github.com/rustybird/750a5b28e7b285669fe90851e6f48b32

It creates a filesystem on a 5 GiB loop device, writes three 1 GiB
files inside the mountpoint, deletes two of them; and runs fstrim
three times while looking at the disk usage of the backing file after
each fstrim run. Results:

# ./fstrimtest ext4
3139M img
mnt: 3.8 GiB (4122611712 bytes) trimmed
1091M img
mnt: 0 B (0 bytes) trimmed
1091M img
mnt: 0 B (0 bytes) trimmed
1091M img

# ./fstrimtest xfs
3137M img
mnt: 3.9 GiB (4227661824 bytes) trimmed
1089M img
mnt: 3.9 GiB (4227661824 bytes) trimmed
1089M img
mnt: 3.9 GiB (4227661824 bytes) trimmed
1089M img

# ./fstrimtest btrfs
3084M img
mnt: 3.5 GiB (3766091776 bytes) trimmed
1028M img
mnt: 3 GiB (3255435264 bytes) trimmed
1028M img
mnt: 3 GiB (3255435264 bytes) trimmed
1028M img

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

iQKSBAEBCAB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmcRQLJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8Cxg/4weCl+CT4wjGYyeooSQTAdwmKT3XzsAR+U5Ht6fHqxhCxX/agEoWs42h1
ymQH2iYgxoddf+zQ07A2p20x0ZYmHHt43IXlpohcUkipYwAkxfvSP8LFyj0nLziZ
sdksxKG/sZbN0o/vrlZrul4Ze0SSNqO7itE+YVgim47vsL537k78WAkEtSOqRvQX
8ES1CHmQh2qBysbIla9w7hyQUmDht2fIkmfFvy29OFCzGf4U7R3i4Agokjh797q4
8Azs9RyK7OIH7+U93+7u/BmBRm0IxkeKqeNiZlf2negZ2I9uFfiHIVqhFx0qyEWD
M9PtpvlhcVfljKoNbmwrL5cTFMFBwlrXdRlqAN6808uzGmp/PVn1L2vUmLBfql/o
0czNbqcbTGNSwgoG5RD+iSvnqS2glxbrQugw8nlViPjlnlq5PCZtT51uKpj3hZgE
OBpUL4vFe+nI62pKu7Taulpm9mt+hxXEnMQkzOx+j9dIrpdsx3wNuGN2hjAuWTgv
FOgWaFNd1MJ6+QKyBAcw4lANBgy2NUhw6smAy1qwColQ4P64eP0CJAgPCjwHHHym
jkOl+H+D/lbld0RjpHe6L2RkwvZ8l0Dvxjggtzjrd/O4DIqrplm3Cyo+yJKjZkhO
zL+txZb6HSfVjupwcRJgocarwnanSGqdN+cPcD6cgvyqdkayww==
=vCPI
-----END PGP SIGNATURE-----

[Boryeu Mao]

On Wed, Oct 16, 2024 at 8:03 AM Rusty Bird <rust...@net-c.com> wrote:

I assume you're seeing the same "not supported" message if you run:

    $ sudo fstrim /var/tmp/

Yes

 

The only thing I can think of is that you have custom partitioning,
and the storage layer immediately underneath the filesystem hosting
/var/tmp/ is dm-crypt (unusual for an LVM Thin installation), and
dm-crypt has been mapped with discard disabled.

My Qubes OS was pretty much a vanilla install from the R4.1 iso (then updated in place to 4.2).  During installation, I opted to encrypt the main partition, which I thought was rather standard as well.  In any event, it seems that my situation can't easily be rectified without perhaps a system re-installation from scratch.

Your storage tree (showing discard support) can be printed with:

    $ lsblk --output +DISC-MAX

Yes this is helpful.  Thx.

Finally, you've used qubes-dom0-update, which nowadays calls
qvm-template for template related stuff. For this, qubes-dom0-update
can actually be run as non-root, but you ran it with sudo, so fstrim
was *not* skipped. (Which then failed on on your system.)

So it looks like I'd just stick with running the template install as root, as I won't gain much as non-root.

Thank you again!