Kysymys:
Vanhan Filevaultin ja uuden Lionin koko levyn salauksen nopeus
Framester
2011-07-27 18:37:48 UTC
view on stackexchange narkive permalink

Kuinka vanha Filevault ja uusi Lionin koko levyn salaus vertailevat nopeutta?

ATM Käytän Snow Leppardia FileVaultin kanssa salaamaan koko kotihakemistoni, mikä tekee IPhoto-, Chrome- tai ITunes-ohjelmien avaamisesta ärsyttävää. hidas.

Linkitetty: [Lyhentääkö FileVaultin käyttö SSD: n käyttöikää?] (Http://superuser.com/q/259768/84988) - Super User
Kolme vastused:
Graham Perrin
2011-07-30 23:45:11 UTC
view on stackexchange narkive permalink

AnandTech - Takaisin Maciin: OS X 10.7 Lion -katsaus: FileVault-suorituskyky vertaa (a) suorituskykyä FileVault 2: n kanssa ja ilman sitä - molemmat lukuun ottamatta FileVault 1: tä.

Se saattaa auttaa löytämään vertailun (b) Lionista FileVault 1: n kanssa ja ilman sitä - molemmat lukuun ottamatta FileVault 2: ta. Versio 2: n jännityksessä voi olla vaikea löytää joku vertaileva / testaava versio 1 Lionista.

Jos molemmat (a) ja (b) löytyvät: lue nämä kaksi rinnakkain.

Haaveeni on, että vastaukset vaihtelevat sen mukaan, mitä käyttäjällä on kotihakemistossa .

Minun tapauksessani, kun olen hylännyt FileVault 1: n FileVault 2: n hyväksi 318 Gt: n käynnistyslevylle MacBookPro5: ssä2, määritteiden ja luettelo B-puiden kokojen summa on noin 4,9 Gt - tietokoneelle, jossa on rajoitettu 8 Gt muistia, huomattava summa:

  [macbookpro08-centrim: ~] gjp22% dateSat 30. heinäkuuta 2011 19:14:26 BST [macbookpro08-centrim: ~] gjp22 % uname -aDarwin macbookpro08-centrim.home 11.0.0 Darwin Kernel Version 11.0.0: la 18. kesäkuuta 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) -attribuutit = 100000000000000000001000000000000000. kHFSVolumeJournaled (levyllä on päiväkirja) journalInfoBlock = 0x948 createDate = su 17. huhtikuuta 00:33:38 2011 modifyDate = la 30. heinäkuuta 19:14:22 2011 backupDate = 0 checkDate = su 17. huhtikuuta 08:33:38 2011 fileCount = 6478678 folderCount = 436279 / * ilman juurikansiota * / blockSize = 4096 totalBlocks = 77592939 freeBlocks = 10772212 nextAllocation = 52271602 rsrcClumpSize = 65536 dataClumpSize = 65536 nextCatalogID = 79803393
writeCount = 349797840 -koodauksetBitmap = 000000000000000000000000000000000000 0000001000000000000000000011011111. MacRoman. MacJapanese. MacChineseTrad. MacKorean. MacArabic. MacGreek. MacCyrillic. MacChineseSimp # Finder Info # Käynnistettävä järjestelmä siunattu kansion tunniste finderInfo [0] = 0x3e4357c (nopea: / System / Library / CoreServices) # Käynnistyssovelluksen vanhemman kansion tunnus finderInfo [1] = 0x3e87cda (nopea: / System / Library / CoreServices / boot. : / System / Library / CoreServices) # VSDB-levytunniste (64-bittinen) finderInfo [6] = 0xbbc2127 finderInfo [7] = 0xac90a940 # File System Boot UUID UUID = 031C0245-ADB2-3BDA-96D0-3C2616ACC11F # Allocation Bitmap CNID 6) looginen koko = 9728000 tavua (9,7 Mt) totalBlocks = 2375 clumpSize = 0 tavua = = startBlock-lohko Luku% tiedostosta 0x1 0x947 100,00% 2375 allokointilohkoa yhdessä määrässä. Keskimäärin 2375,00 allokointilohkoa / laajuus. # Extents Overflow File (CNID 3) looginen koko = 9437184 tavua (9,4 Mt) totalBlocks = 2304 clumpSize = 9437184 tavua extents = startBlock blockCount% tiedostosta 0x2149 0x900 100,00% 2304 allokointilohkoa 1 osassa.
Keskimäärin 2304,00 allokointilohkoa / laajuus. # Luettelotiedosto (CNID 4) looginen koko = 3544186880 tavua (3,5 Gt) totalBlocks = 865280 clumpSize = 177209344 tavun laajuus = startBlock-lohkoMäärä% tiedostosta 0x4b679 0x3c9d0 28,69% 0xfc349 0x287a 1,20% 0x122141 02012 0 0 012 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0122 0 0 0 0122 0 0 0 0122 0 0 0122 0 0 0122 0 0 0122 0 0 0122 0 0 0122 0 0 0 01212 0 0 1 0x310 0,09% 0x10c8ad 0x10760 7,79% 0x2a89 0x3f600 30,00% 0xdce49 0x15200 10,00% 865280 allokointilohkoa yhteensä 9 osuudessa. 96142,22 allokointilohkoa keskimäärin. # Käynnistystiedosto (CNID 7) looginen koko = 0 tavua # Määritetiedosto (CNID 8) looginen koko = 1423966208 tavua (1,4 Gt) totalBlocks = 347648 clumpSize = 203423744 tavua = startBlock blockMäärä% tiedostosta 0x88049 0x54e00 100,00% 347648 jakolohkot 1 kaikki yhteensä. 347648,00 allokointilohkoa keskiarvoa kohden. # Volume Header SHA-1 ef3c7622787bfbd73b65a73a82261aee9197dbe5 # Apujärjestelmän CNID: t HFS + yksityinen metatietokansio = 18 HFS + Hakemiston metatietokansio = 19  

Esittäjä Disk Utility ) käynnistystilavuudelleni:

  Kapasiteetti: 317,82 Gt (317820678144 tavua) Vapaa tila: 43,88 Gt (4388248831212 tavua) Käytetty: 273,94 Gt (273938194432 tavua) Tiedostojen määrä: 6477559 Kansioiden määrä: 436264  

Finder 10.7: n esittämä kotihakemistoni:

  152 306 364 403 tavua (155,61 Gt levyllä) 308 668 tuotteelle  

Esittämä du kodilleni hakemisto:

  la 30. heinäkuuta 2011 18:23:14 BST [macbookpro08-centrim: ~] gjp22% uname -aDarwin macbookpro08-centrim.home 11.0.0 Darwin Kernel Version 11.0.0: la 18. kesäkuuta 12:56:35 PDT 2011; root: xnu-1699.22.73 ~ 1 / RELEASE_X86_64 x86_64 [macbookpro08-centrim: ~] gjp22% sudo du -sh ~ Salasana: 145G / Users / gjp22  

Jos oletuskoko 8 Mt .sparsebundlen kaistojen määrä on yhtä optimaalinen Mac OS X 10.7: lle (koontiversio 11A511) kuin järjestelmän aiemmille julkaisuille - ja jos (epäilen) huomattava osa usein käytetyistä tiedostoista kotihakemistossa on paljon pienempi - Saatan huomata, että FileVault 2: n hylkääminen FileVault 1: n hyväksi tuntuu paremmalta. Tätä tunnetta voi olla vaikea mitata, mutta aion käyttää FileVault 1 -lähestymistapaa, toivottavasti ennen syyskuun 2011 loppua.

http: // identi. ca / convers / 77065575 # notice-79879336 linkit yleiskatsaukseen (keskeneräinen), joka sisältää FileVaultin kahden version suorituskyvyn muiden näkökohtien ohella. Suurin osa tästä työstä on nyt siirretty Kysy erilaiseksi vastaukseksi seuraavan kysymyksen alla:

Pääkäyttäjänä:

Jos löydän jotain muuta merkitystä avauskysymykselle, lähetän uudestaan ​​tänne.

JonB
2011-07-27 20:11:06 UTC
view on stackexchange narkive permalink

En löytänyt suoria vertailuja, mutta luulen, että kysymyksesi on todella "Onko FileVaultin suorituskyky parantunut lionissa?" Lyhyt vastaus on kyllä. Katso Ars Technian John Siracusan leijonan arvostelu saadaksesi selville miksi. Seuraavassa URL-osoitteessa on joitain tavallisia kiintolevyn vertailuarvoja: http://maxcho.com/2011/07/filevault-2-benchmarks/

bmike
2011-07-27 21:41:10 UTC
view on stackexchange narkive permalink

Se on käytännössä nopeampi, kun kirjoitat muutoksia levylle - uutta lohkosalausta on vaikea mitata (eli se on vähäinen hidastuminen).

Uusi toteutus poistaa lähes kaiken tiivistämisen ja viiveen luomalla ja repimällä salattua tilaa. Sen avulla voit yleensä jatkaa työskentelyä samalla kun bittihionta tapahtuu taustalla.

Koko aseman siirtäminen salatuiksi lohkoiksi tapahtuu taustalla samalla, kun voit silti käyttää macia, mutta se ei eroa odotuksesta vanhan salauksen kytkemiseksi päälle tai pois päältä.

Käytännössä uusi toimii huomattavasti paremmin kaikilla alueilla, ja sillä on vähemmän aikoja, kun joudut odottamaan sen suorittamista pitkään.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...