FileVault 2, external disk encryption, drobos, and thin provisioning

[jmmo20]

I use a Drobo unit that has this thin provisioning feature that allows for the storage volume to grow as you add newer hard drives to it.

Basically the OS sees a 16TB volume, but in fact you only have a few tbs (I currently have 2 tb available). As you add new hard drives, or replace old ones, the volume available grows.

My question is.. would think work with apple's new filevault 2 external drive encryption feature? My guess is that it won't since FV2 apparently handles drive's partitions differently.

Any input would be much appreciated! thanks!

 

[CyBeRino]

I use a Drobo unit that has this thin provisioning feature that allows for the storage volume to grow as you add newer hard drives to it.

Basically the OS sees a 16TB volume, but in fact you only have a few tbs (I currently have 2 tb available). As you add new hard drives, or replace old ones, the volume available grows.

My question is.. would think work with apple's new filevault 2 external drive encryption feature? My guess is that it won't since FV2 apparently handles drive's partitions differently.

Any input would be much appreciated! thanks!

I would NOT use filevault on a drobo. Or anything else, really.

 

[8CoreWhore]

I would NOT use filevault on a drobo. Or anything else, really.

Could you elaborate as to why never use File Vault?

 

[CyBeRino]

Could you elaborate as to why never use File Vault?

Drobo is an evil little device that pulls all sorts of dirty tricks, none of which it needs to, under water. Like above: it will tell your computer it has a 16TB HFS+ volume, when really all it has is a single 500GB disk. It relies on knowledge of how the file system works to pull these tricks. FileVault messes with everything it knows about HFS.

 

[MrDudeGuy]

I have a potential fix for anyone out there who did enable FileVault 2 (or encrypted Time Machine backups) on a thin-provisioned Drobo.

Note: When I started using Time Machine with Lion, I was asked whether to encrypt the backups. I enabled this not realizing that this would encrypt the entire disk on which the backups were being placed. I never would have clicked the option if that had been made clear.

Since I had a few TBs on my Drobo, and had it partitioned as a 17 TB volume, the encryption was taking a while (maybe 1-2% per day on my 2010 Core i7 MacBook Pro). Eventually, my Drobo slowed down and couldn't even get through an eject without timing out. The Drobo began alternating between thinking it was entirely full and thinking it was as full as it actually was. Copying all my old data off of the Drobo would take years at best in that state.

It should be noted that before attempting this fix, I pointed my Time Machine backups to a different disk.

Potential Fix
(I've begun this process and will post results here as it continues over the coming weeks)

In a Terminal window:
1 - Type: diskutil list
Output should look like this...

$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            499.4 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *17.6 TB    disk1
   1:                        EFI                         209.7 MB   disk1s1
   2:          Apple_CoreStorage                         17.6 TB    disk1s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk1s3
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Drobo                  *17.6 TB    disk3

You may see two disks which appear to be the Drobo. You'll want to take note of the later one, which doesn't show a GUID_partition_scheme, but is listed as "Apple_HFS Drobo" - This is the "Logical Volume". In my case that's disk3.

2 - Type: diskutil coreStorage info disk3
(If you don't see a "Conversion Status" listed, you have the wrong disk, try another.)

3 - If your conversion status is Converting, check the progress.
Type: diskutil coreStorage list
Look for the Logical Volume Family which has your Logical Volume in it. It should have info looking something like this:

        Sequence:               48
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      Converting
        Has Encrypted Extents:  Yes
        Conversion Direction:   forward

Note that the Conversion Direction is forward.

4 - Now it's time to fix the situation by unencrypting the drive.
Type: diskutil coreStorage revert disk3 -stdinpassphrase
The terminal will ask for the passphrase that was used to encrypt the drive and then go about starting to decrypt it. It will show a "working" progress bar for a while and then tell you "Decryption in progress; use `diskutil coreStorage list` for status".

As I said, this is a work in progress for me, and I'll post results here. I intend to let this run for a while, checking progress along the way. I will have to unmount the disk when I leave for work tomorrow, so I'm hopeful that that will not be any more disruptive to the decrypting operation than it was to the encrypting operation.

I hope this may be helpful to someone out there.

 

[MrDudeGuy]

Progress:
Just 1 day and 1% of the way through unencrypting, my Drobo has returned to nearly normal speeds. I was able to successfully eject (after 3 tries), and re-mount the Drobo with no ill effects. Looks like things are going to be OK.

 

[Mr. Retrofire]

Drobo is an evil little device that pulls all sorts of dirty tricks, none of which it needs to, under water. Like above: it will tell your computer it has a 16TB HFS+ volume, when really all it has is a single 500GB disk. It relies on knowledge of how the file system works to pull these tricks. FileVault messes with everything it knows about HFS.

Really? I thought FV2 is at least one level above the HFS, within the CoreStorage layer.

 

[MrDudeGuy]

Update:
I'm now a little over 60% decrypted and I've learned one important thing since my previous posts. If you're running VMware Fusion, shut it off while you're connected to the Drobo and decrypting. If you don't, things will eventually grind to a halt to the point where the encryption status reports as "Failed" and indicated that reversion is not possible.

This happened to me running Windows 7 on VMware Fusion 4.1.1, but I believe the effect is likely more far reaching than just those versions.

If this happened to you, fear-not. I was able to force restart, and leaving Fusion off, begin the decryption process again.

 

[MrDudeGuy]

Update:

I'm done! It worked!

 

[Crunch]

Thank you!!!

I have to say this, MrDudeGuy, whoever you are, I THANK YOU very much for your posts! The exact same thing happened to me last night with the Time Machine encryption box being checked and even though initially, it gave me some error message, the next day, when I turned my machine back on, the entire Drobo was "encrypting...".

Simply waiting for the completion of the encryption process would have taken a WEEK at least with all the stuff I have on mine, but thanks to you, I caught the whole thing at 2% into this mess and was able to turn "forward" into "backward" or whatever it said.

It's interesting to note that this happened on a brand new 27" "Haswell" iMac with a quad-core i5-4670 (3.4/3.8GHz), OS X Mavericks, and the Drobo 5D. This means that this "bug" of sorts still exists.

You never got any recognition or thanks for this most excellent set of posts that are as relevant and "life-saving" on today's hardware and today's Drobos.

 

[MrDudeGuy]

Thanks

Glad to hear this was of use