I have connected and mounted in Linux a 32GB micro-sd card that was installed on an old "android 6" tablet of mine
du and baobab show only ~17GB allocated:
$ du -sm /media/emmegi/6605-1EF6/ 16250 /media/emmegi/6605-1EF6/ $ the total number of folders and files in it are reported here:
$ find . -type d | wc -l 121 $ find . -type f | wc -l 417 $ while df is reporting these info:
$ df -hT /dev/sda1 Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 vfat 30G 29G 898M 98% /media/emmegi/6605-1EF6 the device seems fine from lsblk:
$ sudo lsblk 2>&1 | grep sda sda 8:0 1 29,3G 0 disk └─sda1 8:1 1 29,3G 0 part /media/emmegi/6605-1EF6 but, as it was reported by several android apps, also on linux with df I can see that the sd is 99% used:
$ sudo fdisk -l /dev/sda Disk /dev/sda: 29,28 GiB, 31440502784 bytes, 61407232 sectors Disk model: Storage Device Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 61407231 61405184 29,3G 7 HPFS/NTFS/exFAT So it seems there is some ~13 GB difference that I cannot explain (how they are hidden?) I need to find (and possibly clean) them but without formatting the sd card
(adding new info to the original post)
I was forgetting to check the filesystem (I preferred in read-only mode for the time being) - and some interesting clue is being reported:
$ sudo fsck -nv /dev/sda1 fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) fsck.ext2: No such file or directory while trying to open /dev/sda1 Possibly non-existent device? $ sudo fsck -nv /dev/sda1 fsck from util-linux 2.39.3 fsck.fat 4.2 (2021-01-31) Checking we can access the last sector of the filesystem There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 65:01/00 Not automatically fixing this. Boot sector contents: System ID "android " Media byte 0xf0 (5.25" or 3.5" HD floppy) 512 bytes per logical sector 32768 bytes per cluster 52 reserved sectors First FAT starts at byte 26624 (sector 52) 2 FATs, 32 bit entries 3836928 bytes per FAT (= 7494 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 7700480 (sector 15040) 959221 data clusters (31431753728 bytes) 16 sectors/track, 4 heads 0 hidden sectors 61405184 sectors total Checking for unused clusters. Reclaimed 433812 unused clusters (14215151616 bytes). Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Checking free cluster summary. Free cluster summary wrong (5410 vs. really 439222) Auto-correcting. Leaving filesystem unchanged. /dev/sda1: 537 files, 519999/959221 clusters $ the interesting entry is:
Reclaimed 433812 unused clusters (14215151616 bytes).
Now I am going to save a backup of all its content, and then my next test is to plug this microSD in a more-recent android device. If nothing changes, I will run fsck in real mode and see if, after relocating the SD in the original tablet, the lost space is actually recovered
du -s. Android uses a lot of hidden directories. The usual method to find lost space is to du -s successive levels down the directory tree, looking for the largest branch. Or for that few files, du -a to a file and search it in an editor. Or use find /toplevel - type -f -size +4M -ls Plenty of tools exist.du -md1, with-d1showing the usage by individual subdirectories. You take the one that takes up the most and look inside it, possibly runningdu -md1on the subdir, and so on. Also, you can check withdu --apparent-sizethe sum of the actual file sizes. By default,dushows the allocated size, that is, the size that a file takes up on disk, rather than the size of the file's contents.