No space left
beso
Steve Coleman
> Something is eating free space in my system. It step by step decreasing. I haven't found any good solution for that.
>
$ sudo du -h / | sort -g | tail -100
Once you know where the space is going, its just a matter of what is
putting it all there.
beso
[xxxxx@dom0 /]$ sudo du -h / | sort -g | tail -100
du: `/proc/17545/task/17545/fd/4' ei saa kasutada: No such file or directory
du: `/proc/17545/task/17545/fdinfo/4' ei saa kasutada: No such file or directory
du: `/proc/17545/fd/3' ei saa kasutada: No such file or directory
du: `/proc/17545/fdinfo/3' ei saa kasutada: No such file or directory
928K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K /usr/share/icons/Adwaita/16x16/status
928K /usr/share/icons/Adwaita/24x24/status
928K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
928K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/intersil
928K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/sound/pci/echoaudio
932K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
932K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
932K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/input/touchscreen
936K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
936K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/crypto
936K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/marvell
940K /usr/lib64/python3.4/email
940K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
940K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/wireless/ath/ath9k
944K /usr/lib/firmware/ath6k
944K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
944K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/include/media
944K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/include/media
944K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/include/media
944K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/scripts/gcc-plugins
944K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/isdn/hisax
948K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/arch/x86/crypto
948K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/arch/x86/crypto
948K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/arch/x86/crypto
948K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/arch/x86/crypto
948K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/arch/x86/crypto
948K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/arch/x86/crypto
952K /usr/share/icons/Adwaita/48x48/status
964K /usr/lib64/gtk-2.0/2.10.0/engines
968K /usr/share/locale/bs/LC_MESSAGES
972K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/crypto
972K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/crypto
972K /usr/share/locale/bs
972K /usr/share/locale/oc/LC_MESSAGES
972K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/crypto
972K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/crypto
976K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/ata
976K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
976K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/ata
976K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
976K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/ata
976K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
976K /usr/share/doc/python-pycurl
976K /usr/share/locale/oc
976K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/scripts/kconfig
976K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/ata
976K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
976K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/scripts/kconfig
976K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/ata
976K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
976K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/scripts/kconfig
976K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/ata
976K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/media/usb/dvb-usb
980K /usr/share/anaconda/ui/spokes
980K /usr/share/fonts/stix
980K /usr/share/icons/Adwaita/scalable/actions
1000K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/include/linux/platform_data
1000K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/include/linux/platform_data
1000K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/include/linux/platform_data
1004K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/build/fs
1004K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/build/fs
1004K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/build/fs
1008K /usr/lib64/python2.7/site-packages/gi
1012K /usr/lib64/python3.4/site-packages/coverage
1012K /usr/lib64/python3.4/site-packages/gi
1012K /usr/lib/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1012K /usr/lib/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1012K /usr/lib/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1012K /usr/share/yelp/mathjax/jax
1012K /var/lib/qubes/vm-kernels/4.9.35-20/modules/4.9.35-20.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1012K /var/lib/qubes/vm-kernels/4.9.45-21/modules/4.9.45-21.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1012K /var/lib/qubes/vm-kernels/4.9.56-21/modules/4.9.56-21.pvops.qubes.x86_64/kernel/drivers/net/ethernet/broadcom/bnx2x
1016K /usr/share/icons/Adwaita/256x256/apps
1016K /usr/share/locale/nn/LC_MESSAGES
1020K /usr/lib64/python2.7/site-packages/Crypto/SelfTest
1020K /usr/share/anaconda/ui
1020K /usr/share/doc/HTML
1020K /usr/share/locale/nn
donoban
> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
>> On 01/23/2018 04:55 AM, beso wrote:
>>> Something is eating free space in my system. It step by step decreasing. I haven't found any good solution for that.
>>>
>>
>> This command should give you a clue as to where the space is going:
>>
>> $ sudo du -h / | sort -g | tail -100
>>
sudo du -h / | sort -g -r | tail -100
beso
du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or directory
du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
0 /proc/109/ns
0 /proc/109/net/stat
0 /proc/109/net/netfilter
0 /proc/109/net/dev_snmp6
0 /proc/109/net
0 /proc/109/map_files
0 /proc/109/fdinfo
0 /proc/109/fd
0 /proc/109/attr
0 /proc/109
0 /proc/108/task/108/ns
0 /proc/108/task/108/net/stat
0 /proc/108/task/108/net/netfilter
0 /proc/108/task/108/net/dev_snmp6
0 /proc/108/task/108/net
0 /proc/108/task/108/fdinfo
0 /proc/108/task/108/fd
0 /proc/108/task/108/attr
0 /proc/108/task/108
0 /proc/108/task
0 /proc/108/ns
0 /proc/108/net/stat
0 /proc/108/net/netfilter
0 /proc/108/net/dev_snmp6
0 /proc/108/net
0 /proc/108/map_files
0 /proc/108/fdinfo
0 /proc/108/fd
0 /proc/108/attr
0 /proc/108
0 /proc/106/task/106/ns
0 /proc/106/task/106/net/stat
0 /proc/106/task/106/net/netfilter
0 /proc/106/task/106/net/dev_snmp6
0 /proc/106/task/106/net
0 /proc/106/task/106/fdinfo
0 /proc/106/task/106/fd
0 /proc/106/task/106/attr
0 /proc/106/task/106
0 /proc/106/task
0 /proc/106/ns
0 /proc/106/net/stat
0 /proc/106/net/netfilter
0 /proc/106/net/dev_snmp6
0 /proc/106/net
0 /proc/106/map_files
0 /proc/106/fdinfo
0 /proc/106/fd
0 /proc/106/attr
0 /proc/106
0 /proc/105/task/105/ns
0 /proc/105/task/105/net/stat
0 /proc/105/task/105/net/netfilter
0 /proc/105/task/105/net/dev_snmp6
0 /proc/105/task/105/net
0 /proc/105/task/105/fdinfo
0 /proc/105/task/105/fd
0 /proc/105/task/105/attr
0 /proc/105/task/105
0 /proc/105/task
0 /proc/105/ns
0 /proc/105/net/stat
0 /proc/105/net/netfilter
0 /proc/105/net/dev_snmp6
0 /proc/105/net
0 /proc/105/map_files
0 /proc/105/fdinfo
0 /proc/105/fd
0 /proc/105/attr
0 /proc/105
0 /proc/10
0 /proc/1
0 /proc
0 /dev/xen
0 /dev/vfio
0 /dev/snd/by-path
0 /dev/snd
0 /dev/raw
0 /dev/qubes_dom0
0 /dev/pts
0 /dev/net
0 /dev/mqueue
0 /dev/mapper
0 /dev/lightnvm
0 /dev/input/by-path
0 /dev/input
0 /dev/dri
0 /dev/disk/by-uuid
0 /dev/disk/by-partuuid
0 /dev/disk/by-partlabel
0 /dev/disk/by-id
0 /dev/disk
0 /dev/cpu/3
0 /dev/cpu/2
0 /dev/cpu/1
0 /dev/cpu/0
0 /dev/cpu
0 /dev/char
0 /dev/bsg
0 /dev/block
Yuraeitha
> Something is eating free space in my system. It step by step decreasing. I haven't found any good solution for that.
Are you on Qubes 4 or Qubes 3.2.?
Perhaps discard or trimming is not working? I.e. every time have more space was required, and following delete "of any files" (doesnt matter which), then the virtual volume won't shrink again. I've recently had this issue too, assuming it's the same issue you have.
Also you can verify if the above is the case or not, by checking your VM size outside the VM, and then confirm the actual space used for your files inside the VM, and see if they somewhat match. For example, run in dom0 terminal "qvm-ls --format disk" and look at the PRIV-CURR column. The numbers are shown in megabytes, i.e. 1000MB is the same as 1GB.
Then open up your VM, find the /rw folder, and right click on it to get the size of the folder.
You're not looking for exact matching values here, but if the values are vastly apart, then the above issue is probably what you're having. I never investigated the exat cause of this issue, but I suspect it was discard not working properly in the VM's, albeit discard in dom0 started working properly after I enabled it.
Among the VM's that did not work, and took alot of disk space, I had to dispose of. I just simply transferred all my files to a new AppVM and deleted the old one after verifying if everything was working. I regained some 30GB alone on my 128GB disk, just by doing this. Perhaps you're having a similar issue.
Sometimes restating all of Qubes may help too, it may sometimes be a quick temporary fix. Neither is replacing VM's with new ones. The real fix to this issue is to get discard to work properly, not only in dom0, but also inside each VM template.
Yuraeitha
I forgot to add, before you right click on the /rw folder of any VM you might suspect to have space issues, make sure first that invisible folders and files are shown, otherwise they won't be counted in the size calculation. In fedora templates, the normal files window manager, simply just hold Ctrl, and then type "H" once. Then all hidden files should be shown in that folder, and all sub-folders, and a more accurate measure of the actual used size will show.
For example Firefox's hidden folder in /home is usually use several 100MB's, and it can make a difference in your size comparison. Thunderbird can also be quite big, i.e. my Thunderbird hidden folder in /home is several GB's in size.
Keep in mind that /rw (read / write) folder, is where your /home folder is, among other folders, which an AppVM needs to have write access to.
beso
Thank for the answer. Actually I didn't understand "qvm-ls --format disk" command. So I couldn't compare them. I trimmed again all my appvm-s, I got back about 5G.
One strange thing for me - in case I start some appvm, free space is increasing about 500MB. It is different every time.
So its increasing and then starts decreasing. Sometimes this decreasing stops but sometime it goes to 0.
donoban
> On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
>> On 01/24/2018 09:34 AM, beso wrote:
>>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
>>>> On 01/23/2018 04:55 AM, beso wrote:
>>>>> Something is eating free space in my system. It step by step decreasing. I haven't found any good solution for that.
>>>>>
>>>>
>>>> This command should give you a clue as to where the space is going:
>>>>
>>>> $ sudo du -h / | sort -g | tail -100
>>>>
>>
>> Try reversing the sort output:
>>
>> sudo du -h / | sort -g -r | tail -100
>
> sudo du -h / | sort -g -r | tail -100
> du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
> du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or directory
> du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> 0 /proc/109/ns
> 0 /proc/109/net/stat
cd /
sudo du -sh *
You should see each dir on / and its disk usage
then cd what you think it's using more than expected and du -sh * again.
beso
Thank you for the answer. Actually I know generally that some of my appvm-s are quite big and there is quite few room(about 6G). Thing I don't understand and would like to know is that this free room is disappearing sometimes(not always) "in my eyes"(free space checker shows me in real time :-))
donoban
> Thank you for the answer. Actually I know generally that some of my appvm-s are quite big and there is quite few room(about 6G). Thing I don't understand and would like to know is that this free room is disappearing sometimes(not always) "in my eyes"(free space checker shows me in real time :-))
>
SSD disk and ~50% for a conventional (unless it's used only for long
term storage).
If you can't remove anything consider to buy another hard disk.
Yuraeitha
It may be, "possible" that discard / fstrim only partially works? For example if it works in dom0, but not in some, or all your VM's, then numbers may change, but they won't be exact. This too means some VM's can grow larger than the actual files they hold, i.e. if you once had more files in, but no longer have that much now. If it can't shrink back down, then it'll stay large. Does your VM's shrink back down too?
I modified donoban's command slightly, it's a good command and it's a good advice he gives. The only reason I modified it to AppVM folder, is because it's a likely source for your disk changes, so it's a good place to start looking too in addition to overall root at "/".
Try:
in dom0: cd /var/lib/qubes/appvms
in dom0: sudo du -sh *
It'll show all your AppVM's and their total disk usage, it's way simpler than the "qvm-ls --format disk" dommand I gave you earlier.
It's recommendable that you save these logs over some days, i.e. sudo nano and copy-paste into it, and save with ctrl+x and follow the guideline to save.
By keeping these logs, you can easily narrow down where it changes in an uncontrollable manner when compared. You can even post them here if you prefer, or cross out the VM names with numbers instead if you prefer privacy (just be sure they match numbers between logs).
As donoban also said, if you do this properly, you'll be able to narrow down the possible culprit. Run the commands once a day over a few days, on both "/" and "/var/lib/qubes/appvms", and keep one log for each path, for some days.
This way, you'll quickly narrow it down with minimal effort once a day, only requiring a bit of patience and a few quick commands daily, max 3-4 minutes.
beso
Actually I haven't trimmed dom0 itself only templates/appvms/standalones. Is this link https://www.qubes-os.org/doc/disk-trim/ correctway to do that?
Yuraeitha
It depends, are you using UEFI/EFI to install Qubes? or LegacyBIOS/Grup? You found the right guide, but this guide is only for LegacyBIOS/Grup, and I'm not entirely happy with some of the commands in it, it seems a bit dangerous, but then again, I'm no expert. I'm also not sure if it works for Qubes 4, or only Qubes 3.2. Some guides still have to be updated for Qubes 4. I just find it odd that the "dracut -H -f" command is used, which as far as I know is related to the kernel installations. It seems possible to be related to fstab etc., but it also seems a bit overkill/dangerous without further insight into why it's used. Perhaps someone more knowledgeable can confirm that this works and doesn't break a system? I might be too careful, it's an official Qubes guide after all. But just to be sure and safe.
If you're on UEFI/EFI, then it's quite a lot easier. I actually used the guide you found there to blindly guess what to do with UEFI/EFI, since I did not find a Qubes guide for it. At least it works for my system, again, you might want to have someone more knowledgeable to confirm this before trying it on your own system. At the very least, make full backups first, i.e. let it run while you sleep.
For UEFI/EFI installation:
0: Check step 7: before starting, to verify if it works before trying to enable it.
1: Backup everything for safety to an external drive.
2: Follow step 1 and step 2 here in the guide you found. Make sure allow-discards is shown after the UUID numbers in step 2, and also that step 2 UUID's match the numbers found in step 1, although they likely match, so you probably only need to add "allow-discards" at the end. Close and save file, be careful not to edit anything else than the intended.
As for step 3,4 and 5: Instead of Grub, for UEFI/EFI you go here "sudo nano /boot/efi/EFI/qubes/xen.cfg", the path might be slightly different on some installations, but it should be somewhat like this. But in all liklihood the path is identical to the above path.
Now make sure rd.luks.allow-discards=1 is added to the kernel=vmlinuz line, just add it at the end of the long line. Also, you only need to do it on the default kernel, look at the very first line at the top to identify which one below is being primary booted from. Close and save file, be careful not to edit anything else than the intended.
As for step 6, it's pretty much the same again as the guide says. Go "sudo nano /etc/fstab" and add discard in the options for the root path "/". If you need help identifying just ask. "/" is the mount point for the partition for the commandline you need. The mountpoints are usually the first after a space separation, after the longer UUID or drive path address you see. Root might also be the first line, see if you can identity the "/" after the first space separation after the UUID/address. You can put in discard after the options, or inbetween the other options, like "defaults,discard,x.system..... "
Step 7: Although may want to run this first before doing the above steps, just to see if it works or not, before trying to enable it. Run "sudo dmsetup table"
Step X1: Have someone more knowledgeable than me verify this, I'm not entirely sure if its correct. But it seems like it worked on my system.
Step X2: Be mindful that updates may from time to time reset the discard settings from i.e. fstab or xen.cfg. If this happens, it's trivial to just add it back, but it can be a bit annoying. I believe debian systems do wann you if they make changes to fstb during an update, at which point it might be a good idea to either compare first, as it offers you to do, or simply just install the new fresh one (which the update also offers you to do), and then add discards again afterwards manaully once its done updating. Just to be safe you don't cause your system to be unbootable.