Almost 450 MB consumed on empty external hard drive

Question

I have an old Macbook Pro with 500GB hard disk. The MBP stopped working. I am now using that hard disk as external storage. After erasing the data (using Disk Utility), I see that almost 450MB is used by 57 files and was not expecting any allocation yet.

In Terminal, going to /Volumes/disk name/ and using du -h on each directory gave me a total of 1 MB consumption.

Macintosh HD 1$ ls -la
total 0
drwxrwxr-x  7 esarupa  2110378014   306B Jan 27 10:25 ./
drwxrwxrwt@ 4 root     admin        136B Jan 27 11:39 ../
drwx------  5 esarupa  2110378014   170B Jan 27 10:25 .Spotlight-V100/
d-wx-wx-wt  2 esarupa  2110378014    68B Jan 27 10:25 .Trashes/
drwx------  5 esarupa  2110378014   170B Jan 27 10:34 .fseventsd/

I am currently on 10.9.1, Processor: 2.5 GHz Intel Core i5. What are these files and why are they taking up 450MB? Is it possible that some files did not get erased and are not showing up in Terminal?

Answer 1

My inclination is that your situation is both normal and expected.

I have a 500 GB UDB HDD with almost the same Bytes capacity as yours and the folders you list are generated on all HFS+ filesystems to allow several items to work. Additionally, my SSD that I have connected over USB also was recently wiped and had 71 files, 312.8 MB of space used on a totally unused partition and after erasing it, the files and space used went to 39 and 312.5 MB respectively:

Mac:~ me$ cd /Volumes/SSD 
Mac:SSD me$ sudo du -sm .Spotlight-V100/ .Trashes/ .fseventsd/
1   .Spotlight-V100/
0   .Trashes/
1   .fseventsd/

You should expect your .Trashes folder to be empty and little actual space used for the other two folders. They hold filesystem metadata and databases used for Spotlight as well as Time Machine and other tools that track filesystem events. As you can see, I have 2 MB or so of allocation but 312.4 MB of space is not usable due to block allocation sizes, filesystem reserved space and other overhead.

You can use sudo ls -laR to get a complete listing of all the files on your disk. Also, the OS will recreate these files if you ever delete them, so your choice is to use HFS+ and let these exist / grow as needed or choose a filesystem that doesn't pre-allocate this space on that drive.

Answer 2

There are two issues to consider here:

1. Every disk has to maintain data files that contain information about every file (or potential file) on the disk, where each is physically located on the media, how many data blocks they occupy, permissions attributes, extended attributes, creation dates, modification dates, journaling information, etc. This catalog of information exists even on an empty formatted drive. Although the catalog may be "empty", the catalog data files still exist and take up space.
2. Even the tiniest regular file with a single character in it takes up more than one byte of space. This is because the disk will allocate at least one or more blocks for the file. On the computer I am currently on, a single character file is one byte in size, but occupies 4 kB on disk. I can edit this file and add content. If I stay below 4 kB in size, overall disk usage won't go up. If I exceed 4 kB in size, then additional blocks will have to be allocated and disk usage will grow to at least 8 kB.

The command du is only reporting "user" files inside your directory structure. It is not reporting usage by the disk catalog structures, so the usage does not need to match.

Tools exist that can perform low-level reads of a hard drive and extract information that was previously on the disk. That is a different topic entirely. But if that is your concern, you can perform a low-level erase, which will write random data multiple times to your hard drive to make data recovery difficult.

Answer 3

I am wondering here, also, that we may just be seeing the difference in how the O/S calculates space and the drive manufacturers calculate space.

I remember hearing (a while back) that the drive manufacturers often count space where (for example) 1KB = 1000 bytes and the O/S calculates space where 1KB = 1024 bytes. The latter being more "correct" from the O/S' perspective.

When Hard drives were in the 5 to 500 MB range the differences in calculated size were small enough to blame it on bad blocks, o/s overhead, formatting, etc. But when you are dealing with vastly bigger disk sizes (millions/billions of times in many cases) the small byte difference gets to be very big and you end up with gigs and gigs of seemingly "missing space."

It has been a while since I remember hearing about this and don't know if it is still common practice but I would guess that the overhead from the formatting, boot records and hidden partitions are usually tiny in comparison to disk sizes these days.

Answer 4

You'll also want to use diskutil list to check if there is a hidden Boot Recovery partition.

ex.

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *512.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS 512                     511.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

As above, you can see that on this old Mac Book Pro of mine 650 MB are hidden for recovery tooling.

This is now called "macOS Recovery" and is a "built-in recovery system on your Mac". https://support.apple.com/en-us/ht201314

If you are interested in removing this partition, see Can I remove Recovery HD partition?