You are correct with your assumption that there is a "double-encryption" occurring. This of course has the result of causing a lot of drive thrashing to occur. Having previously had to fix numerous corrupt FileVaults, I would first back up the sparsebundle. Once that is complete, I would then disable Legacy FileVault.
Ultimately, the only real reason to maintain this setup is if there is reason to suspect there are others who possess login credentials (especially admin credentials) and are capable of mischievous behavior. Even under that scenario, my recommendation would be to encrypt the files which need to be kept secret using TrueCrypt and disable Legacy FileVault.
Suggestions
Review System Preferences
Create another user.
Log in as that user.
Use the Security & Privacy pane of System Preferences. In the FileVault tab, click Enable Users… then in the sheet, ensure that all required users are enabled.
Hint
System Preferences may show that FileVault is enabled, with a recovery key, when there is encryption with Core Storage, but neither FileVault 2 nor a recovery key. I reported this bug to Apple a while ago.
Similarly, but not the same bug:
- I assume that System Preferences may show FileVault disabled on a system where most elements of FileVault are enabled.
Thorough application of Disk Utility
Ensure that the utility is applied:
- to the logical volume group, which appears to contain the logical volume.
(Where Core Storage is used, Disk Utility in 10.8 can not show the physical disk.)
If you select the LV alone, then verification will omit the partition map.
Observations
Conversion Status: Failed
If encryption was applied when the volume was created (typically: erasure with Disk Utility) then:
- there was no conversion forward
- conversion backward can not begin.
Conversion Direction: backward
This implies that:
- recently, conversion backward did begin
- previously, the logical volume was the result of conversion forward (not the result of erasure with Disk Utility).
diskutil coreStorage encryptVolume 4FDED44E-EC4B-4B11-9FF5-9C958BD8CEAB
That could apply if logical volume 4FDED44E-EC4B-4B11-9FF5-9C958BD8CEAB was not encrypted.
As the LV is already encrypted, the response from diskutil is correct.
The question in Apple Support Communities
From the opening poster:
Does the resolution there in ASC, the bounty here in Ask Different, mean that Dennis continues to seek a more detailed answer, a better resolution?
Code -69755
-69755 appears in another discussion:
Interpreting the failure
Pessimistically but realistically:
- a failure to convert – with conversion of nothing – may indicate media failure, possibly in or around the area occupied by the extents file.
Best Answer
Don't think it's double-encrypted. I suspect you created a 'Disk Password' when encrypting in Disk Utility and then you added users to unlock the disk when enabling FileVault. Out of curiosity, what do the following show?
Answers from original poster:
diskutil cs listshows:sudo fdesetup list -eshows: