As a failsafe, I booted into single user mode ( see my advice for special key commands on bootup! :] ), and I ran 'fsck -fy', and it passed there as well. (b) The drive passes verification in First Aid. Here are responses to everything you mentioned: Note: I made sure to clear all cache locations that I know of, as well as /tmp. So, I really do think that there is a file(s) somewhere outside the reach of normal user mode taking up the space. Is it a monolithic VMDK rather than being split into multiple files?ĭempson, thank you for all of the thoughts - before I respond to them, I want to point out that OmniDiskSweeper is the only source that is notreporting the same size. the file system wasn't defragmented), so the file system still has used space around the 80 GB mark and cannot be shrunk smaller than that, despite having a lot of free space before that point. (c) Something to do with the shrink mechanism not working as planned (e.g. Special keys at startup are difficult to time right with a VM (unless there is some trick I haven't learned). OS X Recovery) or start up in single user mode (Command-S at startup) and use 'fsck -fy'. You can run Disk Utility's "First Aid" in the guest to check for this, but if it finds any problems then fixing them might be tricky because you need to either boot from a different volume (e.g. (b) Corrupted file system, such that the actual used space and reported used space don't match. (a) Does the VM have a partitioned drive and one of the other partitions is using a lot of space? You can easily check this in Disk Utility. Some remaining possible explanations which occur to me: If there were any such files, their size would count toward the used space on the volume as shown by Disk Utility and df (and Finder, apart from it pretending local snapshots are free space). If Finder, Disk Utility and df -h are all showing the same "used" figure and that is close to the total reported by OmniDiskSweeper, then the problem is not hidden/protected files. If df also shows about 11 GB used then the explanation is probably something to do with the structure of the VMDK and VMware's ability to shrink it. df will show the actual used/free space, so Local Snapshots count toward its used space. They are supposed to be deleted automatically by the system as free space gets low. KiB/MiB/GiB rather than number of blocks, but note that it uses base-2 units, whereas Finder uses base-10, thus df should show numbers that are about 2% higher than Finder for KB, 4% higher for MB, 7% higher for GB.įinder deliberately hides some things from its reported used space, in particular Time Machine's Local Snapshots (which should only exist if Time Machine is enabled in the VM). The -h option displays the results in human-readable form, e.g. The df command shows disk free and used space. (b) If the guest Finder's Get Info shows about 11 GB used space, then double check using the following command in Terminal: You'll need another method to search with admin privileges (which I can detail once I know this is the case). (a) If the guest Finder's Get Info shows about 80 GB of used space, then the problem is likely to be files in a location that your user account doesn't have permission to access, so OmniDiskSweeper isn't counting them. In particular, what do you see in the guest Finder's Get Info for its hard drive? Is that figure also about 80 GB, or is it showing a more reasonable number around 11 GB?ĭepending on the answer to that question, there are two possible routes to tracking down the problem. When you say " Currently claims to be using approx 80gb", where are you seeing that figure?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |