1

Can anyone help explain why there is 17 GB worth of free space on my LVG I can't seem to do anything with this space. Is there anyway to fix this? I have already reformatted the disk then cloned the contents back with CCC. I also have FileVault enabled.

Whenever I see this on others setups it is usually a few KB not 17 GB

enter image description here

enter image description here

  • please add the output of diskutil cs list sudo gpt -r show /dev/disk0 and sudo gpt -r show /dev/disk1 and remove the diskutil list pic because it's useless. – klanomath Jul 26 '15 at 20:09
  • I disagree with the recommendation to remove the screenshot, in that it reveals 1.) The logical volume UUID of the 3.1 TB HFS storage rendered inaccessible by its conversion to CS; and 2.) that FileVault has been unlocked, rendering the FS Revertible. – Doc G. Jul 26 '15 at 21:14
  • @DocG. The output of diskutil cs list contains the same information but with precise sizes of the physical volumes – klanomath Jul 26 '15 at 22:10
  • Please see the update screenshot – Arron Jul 28 '15 at 19:14
  • @Arron How much of the space is occupied on your main volume? – klanomath Jul 31 '15 at 12:57
1

I don't know what happened with your drives while installing OS X Yosemite, but I have the same Fusion drive as you but ostensibly without "glitches".

First let's compare your and my Fusion drive, though mine is not filevaulted, but that shouldn't make a big difference.

Your SSD:

Apollo:~ arronvoce$ sudo gpt -r show /dev/diskO
     start          size  index  contents
         0             1         PMBR
         1             1         Pri GPT header
         2            32         Pri GPT table
        34             6
        48        409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
    489648     236306352      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
 236715992        262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
 236978136             7
 236978143            32         Sec GPT table
 236978175             1         Sec GPT header

My SSD:

machine:~ user$ sudo gpt -r show  /dev/disk0
      start         size  index  contents
          0            1         PMBR
          1            1         Pri GPT header
          2           32         Pri GPT table
         34            6         
         40       409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640    236306352      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  236715992       262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  236978136            7         
  236978143           32         Sec GPT table
  236978175            1         Sec GPT header

They have the same size and are formatted the same way.

Your HDD:

Apollo:~ arronvoce$ sudo  gpt -r show /dev/disk1
     start          size  index  contents
         0             1         PMBR
         1             1         Pri GPT header
         2            32         Pri GPT table
        34             6
        48        409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 
    409648    5857846336      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
5858255976       1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
5859525512       1007623
5860533135            32         Sec GPT table
5860533167             1         Sec GPT header

My HDD:

machine:~ user sudo gpt -r show /dev/disk1
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6         
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  5858853952      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  5859263592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  5860533128           7         
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header

They have the same physical size but are formatted slightly different: after your Recovery HD (the third partition) you have some non-formatted blocks with a total size of ~516 MB (1007623 blocks)

Your Physical Volume on the SSD:

    +-< Physical Volume 1212D66A-ADCC-49C2-B2BD-43180F3D1B6F
    |   ----------------------------------------------------
    |   Index:    1
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     120988852224 B (121.0 GB)

My Physical Volume on the SSD:

    +-< Physical Volume 1212D66A-ADCC-49C2-B2BD-43180F3D1B6F
    |   ----------------------------------------------------
    |   Index:    1
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     120988852224 B (121.0 GB)

They have the same size.

Your Physical Volume on the HDD:

    +-< Physical Volume 39D4DCA9-7F2E-40FA-B457-CCDD4370FF2F
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk1s2
    |   Status:   Online
    |   Size:     2999217324032 B (3.0 TB)

My Physical Volume on the HDD:

    +-< Physical Volume 39D4DCA9-7F2E-40FA-B457-CCDD4370FF2F
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk1s2
    |   Status:   Online
    |   Size:     2999733223424 B (3.0 TB)

Your Physical Volume is ~516 MB (515899392 B) smaller than mine which roughly matches with your non-formatted blocks on disk1, which are "missing" now.

Your Logical Volume Group:

+-- Logical Volume Group 91F22B32-DD9C-442B-95F0-ED3DB69AC4FB
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         3120206176256   B (3.1 TB)
    Free Space:   17091772416 B   (17.1 GB)

My Logical Volume Group:

+-- Logical Volume Group 91F22B32-DD9C-442B-95F0-ED3DB69AC4FB
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         3120722075648 B (3.1 TB)
    Free Space:   114688 B (114.7 KB)

Your LVG is ~516 MB (515899392 B) smaller than mine, which matches with the findings above.

Your Logical Volume:

         +-> Logical Volume 2E2D175C-1397-474D-900F-A9DA7B9D65D6
             ---------------------------------------------------
             Disk:                 disk2
             Status:               Online
             Size (Total):         3097259147264 B (3.1 TB)

My Logical Volume:

        +-> Logical Volume 2E2D175C-1397-474D-900F-A9DA7B9D65D6
            ---------------------------------------------------
            Disk:                  disk2
            Status:                Online
            Size (Total):          3106191572992 B (3.1 TB)

Your LV is ~ 22.9 GB smaller than your LVG (while 17.1 GB are indicated).
My LV is ~ 14.5 GB smaller than my LVG (while only 115 KB are indicated!).

Your LV is ~ 8.9 GB smaller than mine, which matches again, because 22.9 - 14.5 + 0.5 (the unformatted blocks on the HDD) = 8.9 GB

Compare this with a filevaulted OS X Yosemite VM where the LVG (67.86 GB) is 365 MB bigger than the LV (67.49 GB) and the indicated free space is 12.7 MB.

Finally we have to note:

  • the arithmetic of diskutil is in great need of improvement
  • apparently some valuable hard disk space is needed/lost dealing with LVM (CoreStorage). I haven't been able to find any sources explaining this though.
  • You lost only 8.9 GB (which are only 2.9 ‰ of the total disk space) instead of 17.1 GB compared to my Fusion Drive.

After backing up your Mac, booting to Internet Recovery Mode or Recovery Mode and starting Terminal.app you may try to increase (or decrease) your Logical Volume with the following undocumented command after unlocking the volume with diskutil cs unlockVolume LVUUID -stdinpassphrase:

diskutil cs resizeVolume LVUUID size

Example:

diskutil cs resizeVolume 2E2D175C-1397-474D-900F-A9DA7B9D65D6 (3106191572992+x*4096)b

with x = integer and 4096=8x512 (aligned blocks).

Usually you can't expand the CoreStorage Logical Volume beyond LVG_size - ~300 MB (tested with a 64 GiB disk, I don't know how this works for bigger disks). So you may start with 3119900m. If you get a message saying "Error -69720 There is not enough free space in the Core Storage Logical Volume Group for this operation" decrease the size in 100m or 500m steps until it works. If you enter g (=Giga), m (=Mega) or k (=kilo) instead of b (=byte) diskutil will do the math and choose a proper aligned (=multiple of 4096b) value.

I have tested those steps in my aforementioned 10.10.4 VM with FileVault enabled and managed to increase the size of the volume by 6 MB to 67.5 GB. Your mileage may vary.

  • Thank you for this, very interesting! My concern was that this available space that I can't do anything with is unaccessible space on the SSD which would slow down performance of the Fusion Drive, is that possible? – Arron Jul 31 '15 at 18:58
  • @Arron It wouldn't slow down the performance of the Fusion drive at short sight because the algorithm always frees up some GB (3 GB - 6 GB) of the SSD by reallocating files to the HDD part of the Fusion drive. On the long run though 120 GB on the SSD are better than only 97 GB. But as partly described above your SSD shouldn't be affected by the leak. – klanomath Jul 31 '15 at 19:30
-1

This situation has been a common experience for those who first installed Yosemite on a secondary volume to try it out before committing to using it full time. It has also been noted by those who consolidated former Boot Camp volumes (via repartitioning) into free space on the startup volume.

I assure you the solution is simple and non-destructive, with this qualification: If I were you, I wouldn't rely on the second half of that statement even if it came to me printed on Apple letterhead, much less from a stranger's post at a help forum.

I see you made a whole disk backup with CCC, thereby demonstrating probity, perspicacity and economy. Now demonstrate paranoid cowardice and use Disk Utility to run "Verify Disk" on both the backup drive and the main drive before getting into the task at hand.

Quit Disk Utility. Issue the command diskutil cs list from the Terminal. You should see something like this:

sample output of <code>diskutil cs list</code>

You are looking for the two pieces of information highlighted above in red: The UUID of the logical volume to be restored to plain old HFS storage, plus confirmation that FileVault is unlocked. (If it is locked, adding the argument:

-stdinpassphrase

at the tail end of the revert command given below will ask for your FV password and unlock it before proceeding.)

The command to reverts the storage is diskutil corestorage revert *insert_your_UUID_here*

After you quit Terminal to release its 'busy-in use' lock on the volume, launch Disk Utility. It will now be able to function as it should, and you can proceed as you would have before all of this got in your way.

  • Unfortunately I get the error This operation can only be performed if there is exactly one Core Storage physical volume present in the group – Arron Jul 28 '15 at 19:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .