CLEAN MAC DISK FREE
More and more time compacting the stale data before it can free enough space for new data. Eventually the performance of the SSD will fall as the firmware has to spend If the filesystem writing to the SSD tends to favour writing to unused blocks, then creating and removingįiles will cause the SSD to fill up (from the point of view of the firmware) with stale data (from the point Up with almost-empty blocks containing only one sector, will consider moving some existing data into it. To modify a sector, the firmware will allocate a fresh block and, to avoid the device filling Theĭrive firmware runs a garbage collector, keeping track of which blocks are free and where user data “erase block” size is different from the exposed sector size) and the erase operation is quite slow. SSDs are only able to erase data in large blocks (where the SSD drives suffer from the same phenomenon. The file on the host gets larger and larger, even though the filesystem inside the VM (or Docker.qcow2) will constantly accumulate new blocks, many of which contain stale data. Since the block allocator in practice tends to favour unused blocks, the result is that the Docker.raw For example, the algorithm might be designed toįavour allocating blocks contiguously for a file: recently-freed blocks are unlikely to be in the Up to the filesystem’s block allocation algorithm. Making matters worse, the newly-freed blocks might not be re-used straight away – it’s completely Removed, the blocks become “free” from the filesystem’s point of view, but no-one tells the disk device. To be created or extended, the filesystem will find a free block and add it to the file. The explanation for this odd behaviour lies with how filesystems typically manage blocks. (or Docker.qcow2) will increase up to the upper limit (currently set to 64 GiB), even if the filesystem
It’s got even bigger! It seems that if you create and destroy files in a loop, the size of the Docker.raw Next if you re-create the “same” 1GiB file in the container again and then check the size again you will see: $ ls -s Docker.raw The file has not got any smaller! Whatever has happened to the file inside the VM, the host doesn’t seem to Then check the file on the host: $ ls -s Docker.raw If you switch back to the alpine container terminal and delete the file: / # rm -f 1GiB Note the increase in size from 9964528 to 12061704, where the increase of 2097176 512-byte sectors # dd if=/dev/zero of=1GiB bs=1048576 count=1024īack on the host check the file size again: $ ls -s Docker.raw Next start a container in a separate terminal and create a 1GiB file in it: $ docker run -it alpine sh Number of blocks used is not necessarily the same as the file “size”, as the file can be Note the use of -s which displays the number of filesystem blocks actually used by the file. To demonstrate the effect, first check the current size of the file on the host: $ cd ~/Library/Containers//Data/64-linux/ If Docker is used regularly, the size of the Docker.raw (or Docker.qcow2) can keep growing,
So the Docker.raw (or Docker.qcow2) contain image and container data, written by the LinuxĮxt4 and overlay filesystems. Hard-coded sector size of the virtual disk device. The data will be written to byte offset x * 512 in the file Docker.raw where 512 is the Which configures hyperkit to emulate an AHCI disk device such that when the VM writes to sector x on the device, Top of an ext4 filesystem on top of the partition /dev/sda1.
CLEAN MAC DISK FOR MAC
Docker for Mac is a desktop app which allows building, testing and