On Thursday, January 25, 2018 at 3:29:28 PM UTC+1, beso wrote:
> On Thursday, January 25, 2018 at 4:03:16 PM UTC+2, Yuraeitha wrote:
> > On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote:
> > > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote:
> > > > On 01/24/2018 07:11 PM, beso wrote:
> > > > > 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
> > > > 
> > > > Ouch, try better this way:
> > > > 
> > > > 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.
> > > 
> > > 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 :-))
> > 
> > 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.
> 
> 
> 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?

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.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8b76be1d-cc12-4935-8b7e-d1ecdc554d5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to