Filevault Stuck Optimizing

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.

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)
|
+-- Logical Volume Group XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         999345127424 B (999.3 GB)
    Free Space:   5495873536 B (5.5 GB)
    |
    +-< Physical Volume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     999345127424 B (999.3 GB)
    |
    +-> Logical Volume Family XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
        ----------------------------------------------------------
        Encryption Status:       Unlocked
        Encryption Type:         AES-XTS
        Conversion Status:       Converting
        Conversion Direction:    forward
        Has Encrypted Extents:   Yes
        Fully Secure:            No
        Passphrase Required:     Yes
        |
        +-> Logical Volume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
            ---------------------------------------------------
            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?

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.