Optimización atascada de Filevault

3

Cuando habilité Filevault en Yosemite 10.10.5, pasó por todo el proceso de cifrado y luego cambió a "Optimización". Progresó a 86% y parece estar atrapado allí.

Desdehaceaproximadamente24horas,sedice"X horas restantes". Varía desde 1 hora hasta 12 horas. Aproximadamente a las 12 horas, reinicié para ver si eso ayudaba, pero no fue así. Cuando ejecuto diskutil cs list , dice:

CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    =========================================================
    Name:         Macintosh HD
    Status:       Online
    Size:         999345127424 B (999.3 GB)
    Free Space:   5495873536 B (5.5 GB)
    |
    +-< Physical Volume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk0s2
    |   Status:   Online
    |   Size:     999345127424 B (999.3 GB)
    |
    +-> Logical Volume Family XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
        ----------------------------------------------------------
        Encryption Status:       Unlocked
        Encryption Type:         AES-XTS
        Conversion Status:       Converting
        Conversion Direction:    forward
        Has Encrypted Extents:   Yes
        Fully Secure:            No
        Passphrase Required:     Yes
        |
        +-> Logical Volume XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
            ---------------------------------------------------
            Disk:                  disk2
            Status:                Online
            Size (Total):          993513701376 B (993.5 GB)
            Conversion Progress:   Optimizing 86%
            Revertible:            No
            LV Name:               Macintosh HD
            Volume Name:           Macintosh HD
            Content Hint:          Apple_HFS

¿Cuál podría ser el problema? ¿Hay algo que pueda hacer para solucionarlo?

    
pregunta Edward Ned Harvey 23.11.2015 - 02:15

3 respuestas

3

Bueno, ¿qué te parece?

Unos minutos después de publicar esta pregunta, comenzó a avanzar nuevamente. Se comprimió directamente del 87% al 99% en unos pocos minutos, y ahora está listo.

Al parecer, la respuesta es simplemente "esperar más horas".

    
respondido por el Edward Ned Harvey 23.11.2015 - 03:41
1

FileVault es una cosa muy difícil que depende de una serie de variables para ejecutar sus operaciones, como el tamaño general de la unidad que está cifrando, el tipo de unidad (HDD [y RPM], SSD, etc.), y la cantidad de datos reales (y el tipo de datos) almacenados en la unidad.

Hace tiempo me encontré con un escenario en el que tuve que deshabilitar FileVault para que ciertos procesos se ejecutaran automáticamente en el momento del arranque sin que yo primero tuviera que iniciar sesión. Tenía un disco duro cifrado de 1 TB que estaba lleno al 70%. A FileVault le tomó casi 4 DÍAS para descifrar este volumen. Así que sí, los procesos de FileVault definitivamente pueden tomar un tiempo.

En otra nota relacionada con no con FileVault, sino con la barra de progreso en general, cuando actualicé Mavericks a Yosemite, la barra de progreso se mantuvo en 99% diciendo "1 minuto restante" durante más de 2 horas.

Creo que esto es simplemente un manejo defectuoso de ciertos procesos GUI que los desarrolladores consideran no tan importantes como cosas que realmente afectan la funcionalidad normal del sistema, ya que es más una experiencia de usuario que se pone en el Quemador en retroceso en lo que respecta al desarrollo y la mejora.

Otra vez (y sé que este no es el mismo nivel de código en el que opera el sistema operativo), pero si alguna vez intentas implementar una barra de progreso para las operaciones en bash (que aún no tiene esta funcionalidad incorporada) , como rsync , wget , etc.), descubrirá que es increíblemente difícil estimar adecuadamente el "tiempo estimado restante" de ciertas operaciones de proceso.

Como dije antes, bash es un lenguaje de shell scripting, y no un lenguaje de programación real, por lo que no puedo hablar de C , C++ , etc., pero el comportamiento básico que he visto en bash para barras de progreso es el siguiente (si esto ayuda a proporcionar alguna información):

  • Tienes 10 procesos para ejecutar en un script.
  • La barra de progreso se actualiza en incrementos del 10% después de completar cada proceso, de modo que después de que se complete el último proceso, su barra de progreso mostrará el 100%.
  • Digamos que cada proceso debe tardar 1 minuto en completarse, por lo que el tiempo total estimado para toda la operación debe ser de 10 minutos.
  • Ahora digamos que el proceso # 9 encuentra algunas cosas inesperadas que tiene que manejar en el backend detrás de la escena (que la GUI no puede configurarse para actualizarse y tener en cuenta el amplio alcance de las configuraciones individuales del sistema, porque eso realmente ralentizaría desarrollo hacia abajo).
  • En lugar de tomar 1 minuto para ejecutarse, el proceso # 9 termina tomando 10 minutos para resolver todo el lío con el que tuvo que lidiar.
  • Su barra de progreso se quedará bloqueada al 90% diciendo "1 minuto restante" durante 10 minutos.
  • El resultado final es una operación que dice que tomará 10 minutos, pero en realidad, toma 20 minutos con una barra de progreso bloqueada al 90% durante la mitad del tiempo.

Lo anterior es solo la naturaleza de muchas implementaciones de barra de progreso y actualización de usuario que he encontrado en la naturaleza, y espero que ayude a explicar la naturaleza de lo que encontraste (solo en una escala más pequeña y mucho más simple). p>

Microsoft es horrible con esto, ya que cualquier usuario de Windows ya lo sabe, y obviamente han tomado muy pocos pasos (o ninguno) para corregir o mejorar ese comportamiento. Desafortunadamente, a veces la respuesta es simplemente alejarse o tomar una siesta, y luego regresar y ver si algo realmente ha sucedido. Parece que esto es algo que tienen en común con Apple (o quizás, como dije antes, es difícil tener en cuenta el tiempo restante restante para tipos específicos de operaciones).

Es posible en su escenario específico que FileVault pensó que estaba casi terminado y luego se ejecutó en algunas operaciones en ciertos bloques de archivos o algo que tomó un poco más de lo esperado originalmente, y la barra de progreso simplemente no estaba configurada para dar cuenta de esto.

    
respondido por el rubynorails 23.11.2015 - 04:03
1

Tengo una teoría:

Parece que el proceso de "optimización" solo se ejecuta mientras la computadora está en uso real. Por lo tanto, simplemente dejar el Mac ahí sentado, incluso sin dormir, no hace que la optimización avance. En realidad tienes que interactuar con él. Tan pronto como lo hagas, el tiempo "restante" volverá a disminuir rápidamente.

Así que intenté esto:

Para simular esto, abra Terminal.app (dentro de la carpeta Aplicaciones / Utilidades) ingrese ingrese este comando (seguido de la tecla Retorno):

caffeinate

Mientras deje abierta la ventana de la Terminal con esto, macOS cree que está interactuando con ella, y el proceso de optimización continuará su trabajo.

Lamentablemente, resulta que no está ayudando. Al principio me pareció que sí, pero finalmente la estimación del progreso vuelve a "más de un día". Sin embargo, el simple hecho de interactuar con él hizo que sugiriera que terminara antes otra vez.

    
respondido por el Thomas Tempelmann 01.11.2017 - 13:35

Lea otras preguntas en las etiquetas