15

Linux Mint tells me, I only have 622 MB free disk space but there should be some gigabytes left.

Looking at the partitions I am told that there are about ten gigabytes unused. I googled the problem and didn't find a solution but I did find the hint that I should check the disk usage with df -h.

sudo df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p8  189G  178G  622M 100% /home

The output doesn't make any sense to me: The difference between Size and Used is 11GB, but it only shows 622M as Available.

The SSD isn't old, so I wouldn't expect such a discrepancy.

What should I do?

  • 3
    as @Kusalananda commented, you shouldn't just question why you don't get those 10GB (which I hope I addressed correctly in my answer), but also why you're using most of the space in /home. If you know why (eg: store a lot of media files etc.) that's fine, if you don't, you should worry about it, with potential cleaning giving back more than 10GB of space savings. So what would it be? – A.B Jun 29 at 12:24
  • “Looking at the partitions I am told that there are about ten gigabytes unused.” — where were you told this? – ctrl-alt-delor Jun 29 at 15:25
  • 2
    @ctrl-alt-delor from df's output – Size: 189G, Used: 178G – billyjmc Jun 29 at 15:40
  • @ctrl-alt delor, I got the figure 10GB from gparted – and later 11G from df's output, as billyjmc correctly inferred. – tobiornottobi Jun 29 at 17:13
  • 4
    Possible duplicate of ext4: How to account for the filesystem space? – Robert Riedl Jul 1 at 8:39
23

If the filesystem is ext4, there are reserved blocks, mostly to help handling and help avoid fragmentation and available only to the root user. For this setting, it can be changed live using tune2fs (not all settings can be handled like this when the filesystem is mounted):

-m reserved-blocks-percentage

Set the percentage of the filesystem which may only be allocated by privileged processes. Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. Normally, the default percentage of reserved blocks is 5%.

So if you want to lower the reservation to 1% (~ 2GB) thus getting access to ~ 8GB of no more reserved space, you can do this:

sudo tune2fs -m 1 /dev/nvme0n1p8

Note: the -m option actually accepts a decimal number as parameter. You can use -m 0.1 to reserve only about ~200MB (and access most of those previously unavailable 10GB). You can also use the -r option instead to reserve directly by blocks. It's probably not advised to have 0 reserved blocks.

  • 3
    The user is not "getting back" 8 GB. The are getting 8 GB more to spend. It would be better to track down what's using up all the disk space and then possibly do a cleanup of that, if appropriate, or otherwise move it elsewhere, or grow the partition. – Kusalananda Jun 29 at 12:16
  • 1
    @Kusalananda I'll change the vocabulary. As for the usage, I'd need OP's feedback. The question never hinted that there was unknown high usage, only missing 10GB. – A.B Jun 29 at 12:19
  • 1
    A very good and helpful answer, thank you. 5% seems to match the missing 10 gigabytes very clearly. I am not worried about using so much disk space overall, and I can still grow my partition. :) – tobiornottobi Jun 29 at 17:34
  • 4
    Your answer is certainly correct, but it may be worth noting that the value of root-reserved space in this case isn't huge. This is /home, and reserving space for root there isn't as important as it is for other parts of the file system (e.g. to ensure system logs can still be written). Also, as this is an SSD, preventing fragmentation may not have the priority it does on spinning metal disks. – marcelm Jun 29 at 21:46
  • @marcelm That makes sense to me. But is it still useful on a /home partition on an SSD or is it just a waste of space? Would you recommend lowering the root reserved space to 1%? – tobiornottobi Jul 1 at 8:05
8

Deleted files can also contribute to "missing space"

lsof | grep deleted | grep /home

returns this output for me

chrome    11181           criggie   15u      REG              254,0   
4194304  50651663 /home/criggie/.config/google-chrome/BrowserMetrics/BrowserMetrics-5D0236AF-2BAD.pma (deleted)

Which shows that Chrome running as PID 11181 opened that BrowserMetrics file then deleted it, and still has the filehandle open. This means the file is invisible in a directory listing, but is still taking up disk space.

Why do programmes do this? When the running binary terminates, the OS will release the open file handle and the file on disk will be gone, without risk of leaving a stale temp-file around.

What I can't see is how big that file's disk usage is.

  • 2
    Most well-written programs should not do this. It's a bug, and should be reported, it's just that most of these obscure bugs don't really show up until you are in an optimization phase, and if it's a one off it may even not really be detected at all during testing. Note that there may be a specific reason why they are doing this, there may be a rationale I am not aware of here for keeping the handle open this long. – Drunken Code Monkey Jun 30 at 1:19
  • 4
    @DrunkenCodeMonkey Dude - its Chrome... you're totally correct. – Criggie Jun 30 at 3:28
  • 4
    @DrunkenCodeMonkey, a great many well-written programs do this. The open-delete-close pattern for creating temporary files on *nix is nearly universal, because it guarantees the file will be deleted when the program exits, regardless of how it exits: normal termination, crashing, killed by running out of memory, killed by power failure, etc. – Mark Jul 1 at 8:09
  • 3
    @DrunkenCodeMonkey so, what if the program is never done with it? – leftaroundabout Jul 1 at 10:07
  • 3
    @DrunkenCodeMonkey: The pattern is open-delete-work-close. If the program is still doing something with the contents of the temporary file (e.g. using it as an on-disk cache, or logging telemetry data into it), then of course it must keep it open. (Of course, it's also possible that this is indeed a stale unclosed file handle that the program should've closed but didn't. But given that there's only one such file, and that there are no other obvious indications of a resource leak, I would start with the assumption that the file is probably being kept open on purpose.) – Ilmari Karonen Jul 1 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.