root@ubuntu:/home/ubuntu# sg_readcap --16 /dev/sdd
READ CAPACITY (16) not supported
This means when your USB docking translate the capacity from the drive's ATA IDENTIFY DEVICE data (seen in hdparm -I
/ smartctl -i
), it can at most report a size up to 32-bit (i.e. 0xffffffff, 4294967295) in terms of number of logical sectors. This is an inherit limitation of SCSI READ CAPACITY (10):
Logical Sector Size | Maximum capacity supported (TiB / TB)
512 | ~2.0 / ~2.2
4096 | ~16.0 / ~17.6
Since your drive is an AF 512e drive that has totally 5860533168 / 0x15d50a3b0 512-byte logical sectors, which requires 33 bits to represent, only a SATA/USB bridge that supports SCSI READ CAPACITY (16) can handle it properly. When the size is truncated to 32-bit, it turns from:
101011101010100001010001110110000 (5860533168)
to
01011101010100001010001110110000 (1565565872)
The Linux kernel, or probably all OSes, will basically never issue ATA IDENTIFY DEVICE command "directly" (i.e. encapsulated in a SCSI ATA PASS-THROUGH command) to USB drives, but SCSI READ CAPACITY commands (which you issued manually with sg_readcap
), to get the capacity of them.
Only when the drives are actually SATA drive connected with a SATA/USB bridge, the command will be handled by the SCSI-ATA Translation Layer implemented in the bridge, which will then issue ATA IDENTIFY DEVICE command to the SATA drive to get the information it needs to form the response data for the READ CAPACITY command.
But utilities like hdparm
and smartctl
are (almost) exclusively for ATA drives, so they pretty much do everything with ATA PASS-THROUGH. (Also because they are userspace utilities, it is expected you, the user, will only use them on the appropriate type of devices.) That's why you end up getting different capacity in different places.
Reproduction
I just tried the same command as you: du -sh /mnt/c/Program\ Files/
and mine reported properly with what Windows reported.
It's possible it was a bug and has been patched, or that there's something about your file system that I do not have going on with mine. You've already done a dig on linking/shortcuts, but maybe there's still something being overlooked there?
I did double check against Bash on Ubuntu on Windows
"WSL Legacy" and Ubuntu
, both reported the same for me.
Just saw the comments on the question about a reported bug, looks like everything mentioned has been patched up ?
Additional Steps to Try
You probably no longer have this issue occurring, given this was asked over a year ago now. Here's some additional steps I would try, to pinpoint where that large number is coming from.
Install NCDU
I would recommend trying ncdu
. You can install it with the following on Ubuntu/WSL[Ubuntu Flavor]:
sudo apt install ncdu
This will crawl your system and visually show you where space is going. This may help you pinpoint what/where the disk is supposedly being used in that program file mount. I would be really interested to see if this shows the same issue or not. I assume ncdu
uses du
so I would think it would display the same for you unless it uses some flags behind the scene to avoid this.
Display Usages Only for Program Files Directory
Using ncdu
to crawl only a specific directory is pretty straight forward. You can display usage only for the Program Files
directory on windows using the following command:
ncdu /mnt/c/Program\ Files
Resolution
I would recommend that you use Windows to determine disk usage for the Windows Operating System, especially given that the file system is undoubtedly NTFS.
If you want to determine the disk usage just in the WSL instance I would recommend using ncdu
and ignoring the /mnt
directory so you only display usage for the Linux system and not the Windows mount.
Don't get me wrong though, my interests are equally piqued about what's going on with your situation.
Check Linux Disk Space Ignoring Windows Mount
To check the Linux disk usage ignoring the windows mount you can run:
ncdu --exclude /mnt
Why Small Files Take Up More Data
If I recall correctly, even if you only throw a couple of characters into a text file, you're still occupying the sector on the drive. Double checking I was not able to reproduce this on NTFS drive systems, but I was able to do this on FAT32. NTFS is used for Windows so it's possible the reporting through Linux is displaying through Linux's interpretation of the filesystem that it's working with.
It used to be that some apps would make thousands of small files, and it was like death by a million paper cuts. Also transferring thousands of small files would take much longer than a single large contiguous file.
Note that you can see its actual size and the size it occupies on the disk.
I doubt this is the reason you're seeing a large discrepancy in your disk reporting though, but it could be interesting if you had millions of small files. Some caching/storage schemes do tend to branch out into many small files for quick binary search access.
Best Answer
du
includes the size of directories. If you add-type d
to thefind
criteria you may get the result you want (I do on a directory tree containing only standard files):However, there may be other file types that take up space, so try omitting the type check altogether: