When I enabled filevault on Yosemite 10.10.5, it went through the whole process of encrypting, and then it changed to "Optimizing." It progressed to 86% and seems to be stuck there.

enter image description here

For about 24 hours now, it's been saying "X hours remaining." It varies from like 1 hour to 12 hours. About 12 hours into it, I rebooted just to see if that would help, but it didn't. When I run diskutil cs list, it says:

CoreStorage logical volume groups (1 found)
    Name:         Macintosh HD
    Status:       Online
    Size:         999345127424 B (999.3 GB)
    Free Space:   5495873536 B (5.5 GB)
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     999345127424 B (999.3 GB)
        Encryption Status:       Unlocked
        Encryption Type:         AES-XTS
        Conversion Status:       Converting
        Conversion Direction:    forward
        Has Encrypted Extents:   Yes
        Fully Secure:            No
        Passphrase Required:     Yes
            Disk:                  disk2
            Status:                Online
            Size (Total):          993513701376 B (993.5 GB)
            Conversion Progress:   Optimizing 86%
            Revertible:            No
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS

What could the problem be? Is there anything I can do to fix it?

3 Answers 3


Well, how about that.

A few minutes after posting this question, it started making progress again. It zipped straight from 87% to 99% in a few minutes, and now it's done.

Apparently the answer is just "wait more hours."


FileVault is a very tricky thing that depends on a number of variables to execute its operations, such as the overall size of the drive you are encrypting, the type of drive (HDD [and RPM], SSD, etc.), and the amount of actual data (and type of data) stored on the drive.

I ran into a scenario awhile back where I had to disable FileVault in order for certain processes to launch automatically at boot time without me first having to login. I had an encrypted 1TB HDD that was 70% full. It took FileVault nearly 4 DAYS to decrypt this volume. So yeah, FileVault processes can definitely take awhile.

On another note concerning not FileVault itself, but the progress bar in general, when I upgraded from Mavericks to Yosemite, the progress bar stayed at 99% saying "1 minute remaining" for over 2 hours.

I think this is either just buggy handling of certain GUI processes that developers deem not as important as things that actually affect normal system functionality, as it's more of a user experience thing that gets put on the back burner as far as development and improvement goes.

Then again (and I know this is not the same level of code that the OS operates on), but if you ever try implementing a progress bar for operations in bash (which don't already have this functionality built in, such as rsync, wget, etc.), you will discover that it is incredibly difficult to adequately estimate the "estimated time remaining" of certain process operations.

Like I said before, bash is a shell scripting language, and not an actual programming language, so I can't speak for C, C++, etc., but the basic behavior I have seen in bash for progress bars is as follows (if this helps provide any insight):

  • You have 10 processes to execute in a script.
  • The progress bar updates in 10% increments after each process is complete, so that after the last process completes, your progress bar will show 100%.
  • Let's say each process should take 1 minute to complete, so the overall estimated time for the entire operation should be 10 minutes.
  • Now let's say process #9 encounters some unexpected stuff that it has to handle on the backend behind the scenes (which the GUI cannot be configured to update and account for regarding the broad scope of individual system configurations, because that would really slow down development).
  • Instead of taking 1 minute to execute, process #9 ends up taking 10 minutes in order to resolve all of the mess that it had to deal with.
  • Your progress bar will be stuck at 90% saying "1 minute remaining" for 10 minutes.
  • The end result is an operation that says it will take 10 minutes, but in reality, actually takes 20 minutes with a progress bar stuck at 90% for half the time.

The above is just the nature of many progress bar and user-update implementations that I have encountered in the wild, and will hopefully help explain the nature of what you encountered (just on a smaller, much simpler scale).

Microsoft is horrible at this, as any Windows user already knows, and they have obviously taken very little (if any) steps at correcting or improving that behavior. So unfortunately, sometimes the answer is to just walk away or take a nap, and then come back and see if anything has actually happened. It appears that this is one thing that they have in common with Apple (or maybe, like I said before, it is just hard to account for estimated time remaining for specific types of operations).

It is possible in your specific scenario that FileVault thought it was almost finished and then ran into some operations on certain file blocks or something that took a little longer than originally-expected, and the progress bar was just not configured to account for this.


I have a theory:

It seems that the "optimization" process only runs while the computer is in actual use. So, simply leaving the Mac sitting there, even with sleep off, doesn't make it progress the optimization. You actually have to interact with it. As soon as you do, the "remaining" time decrease quickly again.

So I tried this:

To simulate this, open Terminal.app (inside the Applications / Utilities folder) enter enter this command (followed by the Return key):


As long as you leave the Terminal window open with this, macOS thinks you're interacting with it, and the optimization process will continue its work.

Alas, it turns out that is not helping. It seemed so to me at first, but eventually the progress estimation fall back to "more than a day". However, simply interacting with it made it suggest to finish sooner again.

  • I've noticed something very similar - the process seems to speed up when the system being "optimised" is in use. I wonder if the process somehow uses the frequency of keystrokes, etc as input to the RNG (much like ssh/GPG key generation)?
    – mjturner
    Jun 7, 2018 at 7:41

You must log in to answer this question.

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