type ‘df -h’: 
use disk usage analyzer of ubuntu:The file only used 16.5G
The disk only has 1.2G remaining, but the file only uses 16.5G, and the’lsof’ command has also been used without any effect. I don’t know where the 10G space is.
In the df -h output I see the rootfs is size 28GB, and 27GB is used, leaving 1.2GB. I have no idea which file it is which uses “16.5G”. Are you speaking of the host side “Linux_for_Tegra/bootloader/system.img”? If so, this is in compressed format, and upon installation it expands.
There is a tool in ubuntu called ‘disk usage analyzer’, which can count the size of all files in the system. 16.5G is the total size of all files in the system.
It is normal after using SDK manager to flash the system. This situation only appeared after I used it for a period of time.
Any time you run software which might save to a file the disk space can seemingly “disappear”. You’d need to find the specific file or files which are either “large” or “recently appended” to know what they are from.
There is a rather interesting tool for situations like this, but the tool itself is somewhat large. If you install this prior to disk usage becoming too much for the tool, then it is very very nice at finding large files: “sudo apt-get install filelight”.
filelight will provide a pie chart of all disk usage. Then you can click on the largest slice, and drill down, and find the pie chart of usage for that subdirectory. If you are able to use this, then I recommend installing it…at least until you find out what is going on.
If you want to find the usage on command line of a particular subdirectory, then you can simply cd to that location, and run the command “sudo du -h -s .” (which takes a bit of time). Unlike filelight the command won’t offer any breakdown of which subdirectory to that directory to look at next.
I used this tool, and in the first interface, it shows that 26.1G has been used. After clicking in, it shows that all files total only 16.5G.
Basically, as you drill down by clicking on subdirectories, it will show only the content used in that new subdirectory or its child subdirectories. You’re going through a forest, and searching for smaller and smaller patches until you see something out of place.
In the first filelight image I see “/usr” contains the bulk of used space, although “/home” is significant. Probably, if you drill down on “/usr”, then you can go to its largest subdirectory, and see what is there. If you get to a subdirectory which is large, but has only a few files, then you might have found the offending file…if not a single file, then there may be a lot of smaller files taking up your storage. Basically you need to drill down on the largest “slice of the pie” until you find something “optional” (something not part of the actual operating system) which might be unneeded.
Each subdirectory of a directory is a collection of files or other subdirectories. Just keep drilling down until you find something which shouldn’t be there, or something which could be removed (just make sure you remove it via the package tool if it is part of a package…most /home directory content is not a package, most /usr content is a package).
I don’t know if you understand what I mean, even if you delete all the system files, there is still 10G of space disappeared.
Ahh, I think I see what you are saying…the second filelight image with 27.4 GiB used, followed by clicking in the center to show “/”, then shows the 15.6 GiB image.
When you first start filelight it will show content of the disk as a whole…not of partitions. The 27.4 GiB is the size of the entire eMMC, not the partition content. When you are using filelight on a system with more than one hard drive you will see a similar icon for each drive. Then when you click on a drive it will refine the graphic image based on the filesystem content of one partition, not the entire disk. All of the Xaviers will have about 95% used of the eMMC as a whole because there are many partitions used for boot.
Then, when you drill down to the rootfs partition (“/”), you are seeing the content of that partition and not the disk as a whole. If you were to run this command, then you’d see an approximate agreement with the “15.6 GiB”:
df -h /
(note that a “GiB” is based on multiples of 1024, whereas a “GB” is multiples of 1000…df -h shows GiB, but rounds off a decimal lower precision)
So there is no missing space…it is just that there is a lot of space occupied by content used for boot, but not available to the rootfs.
If you want to see how many partitions there are:
sudo gdisk -l /dev/mmcblk0
(label “APP” is the rootfs)