An excerpt from your previous reply:
If you run “df” without “-i”, then it reports based on bytes of usage instead of inode. If there is no difference (or approximately equal size) between the percentages via inode and bytes, then you have a perfectly tuned block size. If the two percentages differ, then the implication is that you have either too large of a block size, or too small of a block size. However, your fdisk (you should use gdisk for GPT, not fdisk) shows your block size is 512 bytes, and this is both the default and the smallest size, so you can only create a larger block size. Looking at what “df -i” reported it seems like there is no issue of running out of inodes, but you probably have a large number of inodes compared to what is required for that number of bytes. I say “probably” because I don’t see the “df” output for mmcblk0p1 without the “-i”. It would be useful to see the result of “df -H -T /” side-by-side compared to “df -H -T -i /” (once with “-i”, and once without “-i”).
Remember that a certain number of inodes will exist regardless of whether or not they are used. More inodes means less actual storage space since these are “overhead”. As an example, if you have some sort of filesystem which uses 1 GB of space for inodes, and if inodes were 25% of capacity when space used is 100%, then it would mean you have four times too many inodes. From a different point of view, you could in the example have changed the inode size from 512 bytes to 2048 bytes to “tune” the filesystem and not waste inodes. Yet another view is to say that the average file size before optimizing is 2048 bytes, but if the average size had been 512 bytes, then there would be no waste. Since part of an inode is metadata, and part is actual storage, having 1/4 of the inodes would reduce the overhead to 1/4 of the amount used for 512 byte block size. I don’t have a side-by-side comparison of “df” with and without “-i” so I don’t know specifics for your case, but tuning by reinstalling the filesystem with a larger block size would save some waste.
Yet another way of saying this is that any time the number of bytes you store in a file does not exactly match the block size (after metadata) you will find that storing that number of bytes consumes more space from the total pool of available storage than the actual file consumes. More files which are not a close match to the block size implies total consumed space will exceed file size totals multiplied by the number of files.
I do not know where your specific space consumption is used at, but those two large files have me curious as to what they are. Also, because these files are so large, it implies you might want to change the block size from 512 bytes to something larger, e.g., 4096 bytes (but to reiterate, you do not have the “-i” and “not -i” version of “df /” side-by-side to compare).
What you are looking at is likely not a bug. Finding large files is about the only way I know of to actually see where space can be recovered (but I’m guessing you don’t want to delete the earlier mentioned files “data_log” and “data_record”, which is where most of this space is…do you really need 3 GB of log?). Changing the block size is destructive, and if you wanted to try other sizes, then basically what you’d need to do (if you don’t want to lose the current filesystem) is to clone, create a copy of this clone in a rootfs file which is formatted to the new block size, and then flash the altered copy.
Keep in mind that if you increase block size, then larger files benefit, but any file significantly less than the new byte size will waste more space. It is a balancing game unless the filesystem is corrupt (if corrupt to that extent you’d need to reinstall).
