Speed of old Filevault vs. new Lion full disk encryption

How do the old Filevault and the new Lion full disk encryption compare speed wise?

ATM I am using Snow Leppard with FileVault to encrypt my whole home directory, which makes opening IPhoto, Chrome or ITunes annoyingly slow.


Solution 1:

It is faster in practice when writing changes to the disk - the new block encryption is hard to measure (meaning it's a negligible slowdown).

The new implementation removes nearly all of the compacting, and delay in creating and tearing down an encrypted space. It generally allows you to continue working while the bit grinding happens in the background.

The effort to shift a whole drive to encrypted blocks happens in the background while you can still use the mac but it's no different than waiting to turn on or off the old encryption.

In practice the new is far better performing across the board and has less times when you have to wait for it to do some long operation.

Solution 2:

AnandTech — Back to the Mac: OS X 10.7 Lion review: FileVault performance compares (a) performance with and without FileVault 2 — both excluding FileVault 1.

It may help to find a comparison of (b) Lion with and without FileVault 1 — both excluding FileVault 2. However: in the excitement around version 2, it may be difficult to find someone benchmarking/testing version 1 on Lion.

If both (a) and (b) can be found: read the two alongside each other.

My hunch is that answers will vary, depending on what the user has in the home directory.

In my case, after abandoning FileVault 1 in favour of FileVault 2 for a 318 GB startup volume in a MacBookPro5,2, the sum of the sizes of the attributes and catalog B-trees is around 4.9 GB — for a computer limited to 8 GB memory, a considerable sum:

[macbookpro08-centrim:~] gjp22% date
Sat 30 Jul 2011 19:14:26 BST
[macbookpro08-centrim:~] gjp22% uname -a
Darwin macbookpro08-centrim.home 11.0.0 Darwin Kernel Version 11.0.0: Sat Jun 18 12:56:35 PDT 2011; root:xnu-1699.22.73~1/RELEASE_X86_64 x86_64
[macbookpro08-centrim:~] gjp22% sudo fileXray --volume_header /
# HFS+ Volume
  Volume size          = 318 GB (296 GiB)

# Volume Header
  signature            = 0x482b (H+)
  version              = 0x4
  lastMountedVersion   = 0x4846534a (HFSJ)
  attributes           = 10000000000000000010000000000000
                       . kHFSVolumeJournaled (volume has a journal)
  journalInfoBlock     = 0x948
  createDate           = Sun Apr 17 00:33:38 2011
  modifyDate           = Sat Jul 30 19:14:22 2011
  backupDate           = 0
  checkedDate          = Sun Apr 17 08:33:38 2011
  fileCount            = 6478678
  folderCount          = 436279 /* not including the root folder */
  blockSize            = 4096
  totalBlocks          = 77592939
  freeBlocks           = 10772212
  nextAllocation       = 52271602
  rsrcClumpSize        = 65536
  dataClumpSize        = 65536
  nextCatalogID        = 79803393
  writeCount           = 349797840
  encodingsBitmap      = 00000000000000000000000000000000
                         00000010000000000000000011011111
                           . MacRoman
                           . MacJapanese
                           . MacChineseTrad
                           . MacKorean
                           . MacArabic
                           . MacGreek
                           . MacCyrillic
                           . MacChineseSimp

  # Finder Info
       # Bootable system blessed folder ID
         finderInfo[0] = 0x3e4357c (speedy:/System/Library/CoreServices)
       # Parent folder ID of the startup application
         finderInfo[1] = 0x3e87cda (speedy:/System/Library/CoreServices/boot.efi)
       # Open folder ID
         finderInfo[2] = 0
       # Mac OS 9 blessed folder ID
         finderInfo[3] = 0
       # Reserved
         finderInfo[4] = 0
       # Mac OS X blessed folder ID
         finderInfo[5] = 0x3e4357c (speedy:/System/Library/CoreServices)
       # VSDB volume identifier (64-bit)
         finderInfo[6] = 0xbbc2127
         finderInfo[7] = 0xac90a940
       # File System Boot UUID
                  UUID = 031C0245-ADB2-3BDA-96D0-3C2616ACC11F

  # Allocation Bitmap File (CNID 6)
  logicalSize          = 9728000 bytes (9.7 MB)
  totalBlocks          = 2375
  clumpSize            = 0 bytes
  extents              =   startBlock   blockCount      % of file

                                  0x1        0x947       100.00 %

                         2375 allocation blocks in 1 extents total.
                         2375.00 allocation blocks per extent on an average.

  # Extents Overflow File (CNID 3)
  logicalSize          = 9437184 bytes (9.4 MB)
  totalBlocks          = 2304
  clumpSize            = 9437184 bytes
  extents              =   startBlock   blockCount      % of file

                               0x2149        0x900       100.00 %

                         2304 allocation blocks in 1 extents total.
                         2304.00 allocation blocks per extent on an average.

  # Catalog File (CNID 4)
  logicalSize          = 3544186880 bytes (3.5 GB)
  totalBlocks          = 865280
  clumpSize            = 177209344 bytes
  extents              =   startBlock   blockCount      % of file

                              0x4b679      0x3c9d0        28.69 %
                              0xfc349       0x287a         1.20 %
                             0x122346      0x1bbda        13.13 %
                             0x142047      0x12a52         8.83 %
                             0x121a0f        0x91a         0.27 %
                             0x120d38        0x310         0.09 %
                             0x10c8ad      0x10760         7.79 %
                               0x2a89      0x3f600        30.00 %

                              0xdce49      0x15200        10.00 %

                         865280 allocation blocks in 9 extents total.
                         96142.22 allocation blocks per extent on an average.

  # Startup File (CNID 7)
  logicalSize          = 0 bytes

  # Attributes File (CNID 8)
  logicalSize          = 1423966208 bytes (1.4 GB)
  totalBlocks          = 347648
  clumpSize            = 203423744 bytes
  extents              =   startBlock   blockCount      % of file

                              0x88049      0x54e00       100.00 %

                         347648 allocation blocks in 1 extents total.
                         347648.00 allocation blocks per extent on an average.

# Volume Header SHA-1
  ef3c7622787bfbd73b65a73a82261aee9197dbe5

# Auxiliary System CNIDs
  HFS+ Private Metadata Folder   = 18
  HFS+ Directory Metadata Folder = 19

Presented by Disk Utility 12 (346) for my startup volume:

         Capacity : 317.82 GB (317,820,678,144 Bytes)
       Free Space : 43.88 GB (43,882,483,712 Bytes)
             Used : 273.94 GB (273,938,194,432 Bytes)
  Number of Files : 6,476,859
Number of Folders : 436,264

Presented by Finder 10.7 for my home directory:

152,306,364,403 bytes (155.61 GB on disk) for 308,668 items

Presented by du for my home directory:

Sat 30 Jul 2011 18:23:14 BST
[macbookpro08-centrim:~] gjp22% uname -a
Darwin macbookpro08-centrim.home 11.0.0 Darwin Kernel Version 11.0.0: Sat Jun 18 12:56:35 PDT 2011; root:xnu-1699.22.73~1/RELEASE_X86_64 x86_64
[macbookpro08-centrim:~] gjp22% sudo du -sh ~
Password:
145G    /Users/gjp22

If the default 8 MB size of bands in a .sparsebundle is as optimal for Mac OS X 10.7 (Build 11A511) as it was for previous releases of the system — and if (as I suspect) a significant proportion of oft-used files in my home directory are much smaller — I might find that abandoning FileVault 2 in favour of FileVault 1 feels better. That feeling might be difficult to quantify, but I do plan to take the FileVault 1 approach, hopefully before the end of September 2011.

http://identi.ca/conversation/77065575#notice-79879336 links to an overview (work in progress) that will include performances of the two versions of FileVault alongside other considerations. Most of that work is now transferred to Ask Different as answers under the following question:

  • Apart from being able to encypt an entire volume, what are the other differences of FileVault 2 over FileVault?

In Super User:

  • FileVault performance Snow Leopard

If I find anything more of relevance to the opening question, I'll post again here.

Solution 3:

I wasn't able to find some direct comparisons but I guess you question here is really "has FileVault performance improved in Lion?". The short answer is yes. Take a look at the lion review from John Siracusa at Ars Technia to find out why. There are some regular hard drive benchmarks at the following url: http://maxcho.com/2011/07/filevault-2-benchmarks/