“gvfs
” is not a real filesystem, it exists only in RAM and should not be umounted, and will not consume actual disk space on eMMC. Just to emphasize, gvfs is working as expected when it denies access. In no way does gvfs consume any disk space even if it has a size (that size is in RAM).
For filelight
to show content which root owns you would need to start it with “sudo filelight
”. Then it should see everything which is a real disk (you could start from where you expect the disk is consumed, e.g., “sudo /home
” or “sudo /
” or “sudo /usr/local
”). In the case of gvfs
this is part of secure interprocess communications and it is intended that very little will be able to access this, not even root under normal circumstances.
If you really want to see what is going on with the eMMC, and not be confused by pseudo files, then you would probably want to clone, and then loopback mount the raw clone on your local PC. You could run “filelight
” against the loopback mounted clone, and you would be guaranteed to see everything which was actually part of the eMMC.
Clone information has changed with time. The newer L4T/JetPack/SDKM instructions differ from R28.2.1. The R28.2.1 URL (including documentation) is here:
https://developer.nvidia.com/embedded/linux-tegra-r2821
(you may need to go there, log in, and then go there again).
A clone will create both a smaller (probably several GB in size if the filesystem is near empty, but approaching 30GB if the filesystem is full) “sparse” clone, plus a larger (the exact size of the entire partition, perhaps about 30GB) “raw” clone. I throw away the sparse clone and only keep the raw clone. If you check the docs for your release for cloning, and want to know how to work with the clone from your PC, then just ask.
Note that the combination of clone, fix, then flash by clone, is a fairly common use of a clone, but it takes a lot of time. One clone would take well over an hour. Copying a 30GB file on a hard drive might take half an hour as well. However, your PC can work with a clone with maxed out content without caring, whereas the Jetson requires temp files to be written for a number off procedures, often including login…and so a full disk can prevent login.
The serial console is very simple, and has very few login requirements, and so you might be able to log in via this even on a system which has disk filled, and delete content. Using serial console could (in less than a minute) get around the whole long and painful process of cloning and examining clones and flashing with a fixed clone.
If I were to suspect a normal install of using up disk space, then here are some key places to check:
-
/var/log
(see “sudo du -h -s /var/log
”)
-
/opt
(see “sudo du -h -s /opt
”)
-
/usr/local
(see “sudo du -h -s /usr/local
”)
-
/home
(see “sudo du -h -s /home
”)
-
/home/...each user...
(see “sudo du -h -s /home/...user name...
”)
The big question: Can you log in via serial console? Assuming you can, are you able to drop into a root shell with “sudo -s
”? If you can, then you don’t need to clone. You can solve the issue from there. If you cannot, then you need to clone and work on the clone instead of the Jetson.