Missing hard disk free space

[donoban]

Hi,

I am pretty confused with thin lvm pools and free disk space.

I attached part of lvs output. Is root qubes_dom0-root? 36.96% of data
means near 77gb? df on dom0 only shows near 6GB...

Is the meta value fine?

I should have near 100gb of free space and I am nearly full :/

Regards.

[donoban]

This was my problem
https://github.com/QubesOS/qubes-issues/issues/3226

All fine after fstrim /

[Chris Laprise]

You may want to add 'discard' option to /etc/fstab so the trim happens
automatically.

There was a recent fix that switched all the domUs to use discard for /,
but dom0 was skipped.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[donoban]

On 03/15/18 21:31, Chris Laprise wrote:
>
> You may want to add 'discard' option to /etc/fstab so the trim happens
> automatically.
>
> There was a recent fix that switched all the domUs to use discard for /,
> but dom0 was skipped.
>

I am considering it, there is some controversy with regular fstrim vs
discard option e.g.

http://blog.toracat.org/2014/07/discard-that-discard-run-fstrim-on-rhel-and-rebuilds/

[Chris Laprise]

Keep in mind that most of your VMs (all the domUs) will use discard / in
realtime, along with /rw and home. But I don't think it matters much for
performance on /, as its not meant to be a write-intensive volume (at
least not for domUs).

If I was really concerned about discard performance, I'd focus on
private volumes (rw and volatile) first.

Another wrinkle to this is that Qubes disables actual trim to the SSD by
default. So performance issues introduced by SSD hardware are not even
an issue until/unless you enable trim. See issue
https://github.com/QubesOS/qubes-issues/issues/3686

FWIW I think trim performance is only a problem for older SSD drives
that don't handle their trim cache and block ranges properly.

[donoban]

Thanks for the info.

This also seems confusing
https://www.qubes-os.org/doc/disk-trim/#luks

I did not anything of this but second part of step 5 seems working so
should I believe that TRIM is working ok?

[awokd]

It looks like R4.0 final requires at least the /etc/crypttab discard
option be added, because when I tried to run fstrim -av without it, it
kept telling me 0 bytes trimmed. rd.luks.option does not seem to be needed
any more under R4.0.

[cooloutac]

oh shit we have to do this manually ourselves? lol I forgot what it was like to use linux.

[cooloutac]

Doesn't using trim on encrypted drive lessen security though?

I'm still new to the whole ssd thing as well and more and more I dislike them lol. Had a couple data losses with the one i use and sleep mode using qubes. Its nice they don't break if something crashes but they sure lose data easy.

Got a machine linux and windows don't sleep right always ones with an ssd lol.

[awokd]

On Sun, April 1, 2018 6:15 pm, cooloutac wrote:
> Doesn't using trim on encrypted drive lessen security though?

In my opinion, it's so marginal a security decrease it hardly bears
mention. :) There's a link in the trim doc for further reading.

[Chris Laprise]

I'd like to remind people: Discard and TRIM are not exactly the same thing.

Commands like 'fstrim' only generate discards, and in a Qubes LVM setup
those discards will logically deallocate blocks in the pool, thus
freeing up space for filesystems.

If you enable 'discard' or 'disktrim' or whatever they call it these
days in crypttab, that will result in discards being converted into
hardware TRIM commands. That is because the crypto layer is the one
closest to the hardware in our configuration.

Does TRIM free up space? No. It helps the SSD maintain top write speeds
and perform more efficient wear-leveling. On some drives, it will also
cause the unallocated data to be wiped-out (according to vendor claims).

Does fstrim free up space? Yes! Because it actually generates discards
and the name is misleading.

IMO, the best thing to do is edit your dom0 /etc/fstab and add 'discard'
to the options for root fs '/'. That will free up space in a usable way
and you won't need to run fstrim.

[cooloutac]

according to these qubes doc it says it can hurt performance though if added to fstab? It says to use a systemd or cron job instead. Also says templates and vms already have trim enabled automatically. it also says if we are using luks to add it to crypttab or it won't work?

But is this really nescessary to do in dom0? Will it make any difference if all the templates and vms already have discard by default? And so does that mean we make the cron job for dom0 we also have to add discard to crypttab?

https://www.qubes-os.org/doc/disk-trim/

I apologize if I misunderstand this stuff is confusing.

[Chris Laprise]

That doc may need some clarifying. TRIM might hurt performance on older
SSDs as they wipe data blocks without caching the commands... but
without TRIM the discards are just changing block allocation tables.
Also, we're talking about dom0 where few filesystem operations are
performed; the domUs already all have discard enabled in fstab.

>
> But is this really nescessary to do in dom0? Will it make any difference if all the templates and vms already have discard by default? And so does that mean we make the cron job for dom0 we also have to add discard to crypttab?

The default rc5 dom0 config ran fstrim automatically once per week. IMO,
that's plenty of time for a user to do something which will lead to an
(unnecessary) out of space condition or at least be misinformed about
free space much of the time.

The Qubes code has since been changed to add discard to dom0 fstab
during install, but I don't know if that made it to the 4.0 release iso.
I don't believe the crypttab setting has changed.

TL;dr using discard is necessary when using thin pools (like its
necessary when using sparse disk image files) and relying on fstrim for
that means it should be run frequently.

To me, the most interesting question all this raises is how close in
speed/performance are virtual disk operations on Thin LVM vs Btrfs since
they offer similar features and both incur block allocation processing
on two separate layers.

[cooloutac]

I dunno man I keep hearing about how newer ssd's are supposed to be better. but I got a windows system with an m.2 and its horrible. can't use sleep when using on board audio card. still disabled indexing, superfetch, search and anything else that causes hdd space cause it would cause instability and corruption.

Seems like right now every pc that has an old or new ssd using sleep mode, has instability after resume, no matter what os they are using.

My Qubes dom0 got corrupted once, cause I was using an ssd when resuming from sleep, its even worse in 4.0. and that kind of sucks cause without magic packet waking it up i considered sleep a security feature. but I guess with ssd you can just shut it off and on even better and same thing basically.

But are you saying in RC5 and on trim is enabled by default in dom0?

[Chris Laprise]

Hardware TRIM is disabled by default (the crypttab setting), but dom0
runs 'fstrim' once per week which frees up any extra space dom0 is
occupying in the pool. In this config, both 'discard' option in fstab
and 'fstrim' command only generates discards and shouldn't noticeably
affect performance.