Comment l'ancien Filevault et le nouveau Lion full disk encryption se comparent-ils du point de vue de la vitesse ?
ATM J'utilise Snow Leppard avec FileVault pour crypter l'ensemble de mon répertoire personnel, ce qui rend l'ouverture d'IPhoto, de Chrome ou d'ITunes excessivement lente.
AnandTech - Retour au Mac : Revue d'OS X 10.7 Lion : Performances de FileVault compare (a) les performances avec et sans FileVault 2 - les deux excluant FileVault 1.
Il peut être utile de trouver une comparaison entre (b) Lion avec et sans FileVault 1 - les deux excluant FileVault 2. Cependant : dans l'effervescence autour de la version 2, il peut être difficile de trouver quelqu'un qui évalue/teste la version 1 sur Lion.
Si les deux points (a) et (b) peuvent être trouvés : lisez-les l'un à côté de l'autre.
Mon intuition est que Les réponses varient en fonction du contenu du répertoire personnel de l'utilisateur. .
Dans mon cas, après avoir abandonné FileVault 1 au profit de FileVault 2 pour un volume de démarrage de 318 Go dans un MacBookPro5,2, la somme des tailles des arbres B des attributs et du catalogue est d'environ 4,9 Go - pour un ordinateur limité à 8 Go de mémoire, une somme considérable :
[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 = 19Présenté par Disk Utility 12 (346) pour mon volume de démarrage :
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,264Présenté par Finder 10.7 pour mon répertoire personnel :
152,306,364,403 bytes (155.61 GB on disk) for 308,668 itemsPrésenté par du pour mon répertoire personnel :
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/gjp22Si la taille par défaut de 8 Mo des bandes dans un .sparsebundle est aussi optimale pour Mac OS X 10.7 (Build 11A511) qu'elle l'était pour les versions précédentes du système - et si (comme je le soupçonne) une proportion significative des fichiers souvent utilisés dans mon répertoire personnel sont beaucoup plus petits - je pourrais trouver que l'abandon de FileVault 2 en faveur de FileVault 1 est plus agréable à vivre. Ce qui suit sentiment pourrait être difficile à quantifier, mais je prévois d'adopter l'approche FileVault 1, avec un peu de chance avant la fin du mois de septembre 2011.
http://identi.ca/conversation/77065575#notice-79879336 renvoie à une vue d'ensemble (travail en cours) qui inclura les performances des deux versions de FileVault ainsi que d'autres considérations. La majeure partie de ce travail est maintenant transférée dans Ask Different sous forme de réponses à la question suivante :
Dans Super User :
Si je trouve quelque chose de plus pertinent par rapport à la question initiale, je le publierai à nouveau ici.
Je n'ai pas été en mesure de trouver des comparaisons directes, mais je suppose que votre question ici est vraiment "les performances de FileVault se sont-elles améliorées dans Lion ? La réponse courte est oui. Jetez un coup d'œil à la page avis de lion de John Siracusa à Ars Technia pour comprendre pourquoi. Il existe des tests de référence réguliers pour les disques durs à l'adresse suivante : http://maxcho.com/2011/07/filevault-2-benchmarks/
Dans la pratique, il est plus rapide lors de l'écriture de modifications sur le disque - le nouveau cryptage des blocs est difficile à mesurer (ce qui signifie qu'il s'agit d'un ralentissement négligeable).
La nouvelle implémentation supprime la quasi-totalité du compactage et du délai de création et de destruction d'un espace crypté. Elle vous permet généralement de continuer à travailler pendant que le broyage des bits s'effectue en arrière-plan.
Le passage d'un disque entier à des blocs cryptés s'effectue en arrière-plan pendant que vous pouvez encore utiliser le Mac, mais ce n'est pas différent d'attendre d'activer ou de désactiver l'ancien cryptage.
Dans la pratique, la nouvelle version est bien plus performante dans tous les domaines et il y a moins de moments où il faut attendre qu'elle effectue une longue opération.
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
