Utilisateur mac historique, je suis en recherche de solutions de
migration, point par point, pour les aspects et fonctions qui me sont
importants et je bloque sur le chiffrage à la volée de gros volumes
que permet, sous MacOS, FileVault 2.
L'essai que je viens de faire de Veracrypt ne soutient absolument pas
la comparaison, en particulier pour la mise en œuvre. Du moins
jusqu'à plus ample informé, raison de ce post.
S'agissant du chiffrage d'un volume de 3 To, ai-je raison de
constater que cela prend une trentaine d'heures ? Et pas en
arrière-plan ni avec possibilité d'interruption puis de reprise en
cours que permet Filevault ?
Je ne cherche pas à valoriser quoi que ce soit par rapport à quoi que
ce soit. Juste à trouver des solutions viables et inter-plateformes,
de préférence en open-source (sans obligation).
Peut-être suis-je parti sur une mauvaise piste ? Y a-t-il d'autres
solutions concurrentes ? On est d'accord que pour des dossiers
chiffrés de volume plus faible, VC fonctionne bien (même si on n'a
pas la fluidité d'une solution intégrée au système). J'ai ainsi créé
un dossier de 10 Go sur une clé USB en 6 minutes. Mais évidemment la
règle de trois est ensuite implacable... pour 100 Go -> 60 minutes etc.
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
Ça dépend des priorités.
Mais encore ?
Le 28/09/2020 à 21:55, Pascal Hambourg a écrit :
Le 28/09/2020 à 20:15, pehache a écrit :
Le 28/09/2020 à 18:55, Pascal Hambourg a écrit :
Pas forcément. Ça peut être la gestion de la mémoire et du cache
disque du système lui-même qui réagit de façon non optimale à
l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des
situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier
l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe
comment". Si l'OS met en cache d'écriture un volume de données qui le
conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
Pas forcément. Ça peut être la gestion de la mémoire et du cache disque du système lui-même qui réagit de façon non optimale à l'écriture continue d'un énorme fichier. J'ai déjà vu ça dans des situations n'ayant rien à voir avec Veracrypt. Il faudrait vérifier l'occupation mémoire de Veracrypt.
Oui oui, là ce n'est pas "de façon non optimale", c'est "n'importe comment". Si l'OS met en cache d'écriture un volume de données qui le conduit à swapper, c'est de l'ordre du défaut de conception ou du bug.
Ça dépend des priorités.
Mais encore ?
pehache
Le 28/09/2020 à 21:49, Gerald a écrit :
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs. On pourrait tenir pour possible que ce soit la version mac de Veracrypt qui est en cause : en dehors de problèmes de portabilité inter-plateforme comme celle qui me soucie, il n'y a en effet *aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser Veracrypt alors que Filevault est intégré au système. Veracrypt doit être peu utilisé, peu surveillé dans cet environnement, et peut-être encore moins sur de gros volumes.
Tu pourrais dire la même chose pour n'importe quel OS sur lequel VeraCrypt tourne Par ailleurs il y a quand même des raisons objectives : - le code est libre et auditable, contrairement aux solutions proprios qui ne reposent que sur la confiance que l'on place en Apple, MS, etc... - VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent, comme les volumes cachés. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Le 28/09/2020 à 21:49, Gerald a écrit :
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs.
On pourrait tenir pour possible que ce soit la version mac de
Veracrypt qui est en cause : en dehors de problèmes de portabilité
inter-plateforme comme celle qui me soucie, il n'y a en effet
*aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser
Veracrypt alors que Filevault est intégré au système. Veracrypt doit
être peu utilisé, peu surveillé dans cet environnement, et peut-être
encore moins sur de gros volumes.
Tu pourrais dire la même chose pour n'importe quel OS sur lequel
VeraCrypt tourne
Par ailleurs il y a quand même des raisons objectives :
- le code est libre et auditable, contrairement aux solutions proprios
qui ne reposent que sur la confiance que l'on place en Apple, MS, etc...
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou
autres proposent, comme les volumes cachés.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes." (ST sur fr.bio.medecine)
"Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici."
(FLC sur fr.comp.sys.atari)
MacOS Catalina 10.15.7 sur un Mac mini 2018, intel Core i5 à 6 coeurs. On pourrait tenir pour possible que ce soit la version mac de Veracrypt qui est en cause : en dehors de problèmes de portabilité inter-plateforme comme celle qui me soucie, il n'y a en effet *aucune* raison objective, pour quelqu'un sous MacOS, d'utiliser Veracrypt alors que Filevault est intégré au système. Veracrypt doit être peu utilisé, peu surveillé dans cet environnement, et peut-être encore moins sur de gros volumes.
Tu pourrais dire la même chose pour n'importe quel OS sur lequel VeraCrypt tourne Par ailleurs il y a quand même des raisons objectives : - le code est libre et auditable, contrairement aux solutions proprios qui ne reposent que sur la confiance que l'on place en Apple, MS, etc... - VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent, comme les volumes cachés. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
denis.paris
Le 28/09/2020 à 19:00, Pascal Hambourg a écrit :
Le 28/09/2020 à 16:29, denis.paris a écrit :
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...] Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le pilote natif du noyau et gère complètement l'écriture.
Merci de l'info, comme ça fonctionnait parfaitement je ne m'étais pas penché sur la question, mais c'est bon à savoir. Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à la base extFAT a été développé pour les clés USB et les cartes SD alors que NTFS est en production depuis très longtemps sur les disques traditionnels...
Le 28/09/2020 à 19:00, Pascal Hambourg a écrit :
Le 28/09/2020 à 16:29, denis.paris a écrit :
Le 28/09/2020 à 11:38, Pascal Hambourg a écrit :
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi
que l'écriture de façon très limitée (modification du contenu d'un
fichier existant sans changer sa taille) depuis longtemps. Mais
Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et
désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...] Et je n'ai
strictement rien rajouté comme package pour accéder à la partition
NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le
pilote natif du noyau et gère complètement l'écriture.
Merci de l'info, comme ça fonctionnait parfaitement je ne m'étais pas
penché sur la question, mais c'est bon à savoir.
Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à
la base extFAT a été développé pour les clés USB et les cartes SD alors
que NTFS est en production depuis très longtemps sur les disques
traditionnels...
Le pilote NTFS natif du noyau Linux prend en charge la lecture, ainsi que l'écriture de façon très limitée (modification du contenu d'un fichier existant sans changer sa taille) depuis longtemps. Mais Debian a désactivé l'écriture dans le noyau 4.9 de Stretch/9 et désactivé complètement le pilote dans le noyau 4.19 de Buster/10.
OK, mais pourtant j'ai un noyau 4.15 (xubuntu 18.04) [...] Et je n'ai strictement rien rajouté comme package pour accéder à la partition NTFS, qui est accessible parfaitement en écriture.
Parce que ta distribution a installé ntfs-3g qui prend le pas sur le pilote natif du noyau et gère complètement l'écriture.
Merci de l'info, comme ça fonctionnait parfaitement je ne m'étais pas penché sur la question, mais c'est bon à savoir. Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à la base extFAT a été développé pour les clés USB et les cartes SD alors que NTFS est en production depuis très longtemps sur les disques traditionnels...
denis.paris
Le 28/09/2020 à 21:49, Gerald a écrit :
De toute manière, je ne suis pas sûr que ta suggestion pourrait être fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un système MacOS actif pour qu'ils soient lisibles (c'est même le principe !). AFAIK, évidememnt..
Je pense que si, puisqu'il s'agit de copie secteur par secteur, avec un dispositif autonome, le système de fichiers est donc sans importance.
Le 28/09/2020 à 21:49, Gerald a écrit :
De toute manière, je ne suis pas sûr que ta suggestion pourrait être
fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un
système MacOS actif pour qu'ils soient lisibles (c'est même le
principe !). AFAIK, évidememnt..
Je pense que si, puisqu'il s'agit de copie secteur par secteur, avec un
dispositif autonome, le système de fichiers est donc sans importance.
De toute manière, je ne suis pas sûr que ta suggestion pourrait être fonctionnelle sur des volumes cryptés mac et formatés mac. Il faut un système MacOS actif pour qu'ils soient lisibles (c'est même le principe !). AFAIK, évidememnt..
Je pense que si, puisqu'il s'agit de copie secteur par secteur, avec un dispositif autonome, le système de fichiers est donc sans importance.
pehache
Le 29/09/2020 à 08:50, "denis.paris" a écrit :
Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à la base extFAT a été développé pour les clés USB et les cartes SD alors que NTFS est en production depuis très longtemps sur les disques traditionnels...
Sauf que l'implémentation native de NTFS est limitée à Windows. Par ailleurs même si le besoin initial du développement de exFAT c'était pour les cartes (et pas du tout les clés USB), ça reste un fs généraliste tout à fait adapté ici. Il faut le voir comme un remplacement de FAT32 dès lors qu'on a besoin de gérer des très gros volumes et/ou des fichiers de plus de 4Go.
Le 29/09/2020 à 08:50, "denis.paris" a écrit :
Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à
la base extFAT a été développé pour les clés USB et les cartes SD alors
que NTFS est en production depuis très longtemps sur les disques
traditionnels...
Sauf que l'implémentation native de NTFS est limitée à Windows.
Par ailleurs même si le besoin initial du développement de exFAT
c'était pour les cartes (et pas du tout les clés USB), ça reste un fs
généraliste tout à fait adapté ici. Il faut le voir comme un
remplacement de FAT32 dès lors qu'on a besoin de gérer des très gros
volumes et/ou des fichiers de plus de 4Go.
Finalement, NTFS n'est peut-être pas un si mauvais choix que ça, car à la base extFAT a été développé pour les clés USB et les cartes SD alors que NTFS est en production depuis très longtemps sur les disques traditionnels...
Sauf que l'implémentation native de NTFS est limitée à Windows. Par ailleurs même si le besoin initial du développement de exFAT c'était pour les cartes (et pas du tout les clés USB), ça reste un fs généraliste tout à fait adapté ici. Il faut le voir comme un remplacement de FAT32 dès lors qu'on a besoin de gérer des très gros volumes et/ou des fichiers de plus de 4Go.
Gerald
Le 28 septembre 2020 à 22:22, pehache a écrit :
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu au rebranchement du disque...
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé cette histoire de déni plausible : Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte Veracrypt ? Il est évidemment possible aussi de rendre ce fichier invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose ? -- Gerald
Le 28 septembre 2020 à 22:22, pehache a écrit :
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou
autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système
avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu
au rebranchement du disque...
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment
creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé
cette histoire de déni plausible : Filevault permet *aussi* de créer
un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît
alors que comme un simple fichier. Qu'est-ce qui permettrait de
supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte
Veracrypt ? Il est évidemment possible aussi de rendre ce fichier
invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via
le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose
?
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu au rebranchement du disque...
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé cette histoire de déni plausible : Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte Veracrypt ? Il est évidemment possible aussi de rendre ce fichier invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose ? -- Gerald
pehache
Le 29/09/2020 à 10:07, Gerald a écrit :
Le 28 septembre 2020 à 22:22, pehache a écrit :
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu au rebranchement du disque...
On s'en fout, ce n'est pas un concours de bite pour savoir celui qui a le plus de fonctionnalités. C'était une réponse à la question "Quel est l'intérêt objectif d'utiliser autre chose que FV en dehors d'un besoin d'interopérabilité ?" : si on besoin d'une fonctionnalité présente dans VC et qui ne l'est pas dans FV, ça peut justifer l'utilisation de VC même si FV a 36000 autre fonctionnalités géniales.
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé cette histoire de déni plausible : Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte Veracrypt ? Il est évidemment possible aussi de rendre ce fichier invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose ?
Ca n'a rien à voir. C'est un volume2 inclus dans le volume1, qui doit être créé en même temps que le volume1, mais qui n'apparait strictement nulle part si on ne fait que monter le volume1, car il est indiscernable de l'espace libre. Pour le faire apparaitre il faut cocher l'option adhoc au moment de monter le volume1, en entrant un second mot de passe spécifique au volume2.
Le 29/09/2020 à 10:07, Gerald a écrit :
Le 28 septembre 2020 à 22:22, pehache a écrit :
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou
autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système
avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu
au rebranchement du disque...
On s'en fout, ce n'est pas un concours de bite pour savoir celui qui a le
plus de fonctionnalités. C'était une réponse à la question "Quel est
l'intérêt objectif d'utiliser autre chose que FV en dehors d'un besoin
d'interopérabilité ?" : si on besoin d'une fonctionnalité présente
dans VC et qui ne l'est pas dans FV, ça peut justifer l'utilisation de VC
même si FV a 36000 autre fonctionnalités géniales.
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment
creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé
cette histoire de déni plausible : Filevault permet *aussi* de créer
un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît
alors que comme un simple fichier. Qu'est-ce qui permettrait de
supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte
Veracrypt ? Il est évidemment possible aussi de rendre ce fichier
invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via
le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose
?
Ca n'a rien à voir. C'est un volume2 inclus dans le volume1, qui doit
être créé en même temps que le volume1, mais qui n'apparait
strictement nulle part si on ne fait que monter le volume1, car il est
indiscernable de l'espace libre. Pour le faire apparaitre il faut cocher
l'option adhoc au moment de monter le volume1, en entrant un second mot de
passe spécifique au volume2.
- VeraCrypt a des fonctionnalités qui dépassent ce que FileVault ou autres proposent,
..et inversement ! :-) ne serait-ce que l'intégration au système avec chiffrement en arrière-plan, reprise d'un chiffrement interrompu au rebranchement du disque...
On s'en fout, ce n'est pas un concours de bite pour savoir celui qui a le plus de fonctionnalités. C'était une réponse à la question "Quel est l'intérêt objectif d'utiliser autre chose que FV en dehors d'un besoin d'interopérabilité ?" : si on besoin d'une fonctionnalité présente dans VC et qui ne l'est pas dans FV, ça peut justifer l'utilisation de VC même si FV a 36000 autre fonctionnalités géniales.
comme les volumes cachés.
Oui, c'est une fonctionnalité annoncée et que je n'ai pas vraiment creusée faute de besoin immédiat. Je n'ai d'ailleurs pas bien pigé cette histoire de déni plausible : Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ? Quelle mesure supplémentaire apporte Veracrypt ? Il est évidemment possible aussi de rendre ce fichier invisible avec l'outil de manipulation ad hoc (Onyx par ex.) ou via le Terminal. C'est ça qui est automatisé par Veracrypt ou autre chose ?
Ca n'a rien à voir. C'est un volume2 inclus dans le volume1, qui doit être créé en même temps que le volume1, mais qui n'apparait strictement nulle part si on ne fait que monter le volume1, car il est indiscernable de l'espace libre. Pour le faire apparaitre il faut cocher l'option adhoc au moment de monter le volume1, en entrant un second mot de passe spécifique au volume2.
Nicolas George
Gerald , dans le message <rkuq08$rrt$, a écrit :
Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ?
Tu as un fichier bizarre sur ton disque dur : tu es suspect.
Il est évidemment possible aussi de rendre ce fichier invisible
Non, seulement caché, et trouvable par n'importe qui.
Gerald , dans le message <rkuq08$rrt$1@news.gegeweb.eu>, a écrit :
Filevault permet *aussi* de créer
un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît
alors que comme un simple fichier. Qu'est-ce qui permettrait de
supposer qu'il soit crypté ?
Tu as un fichier bizarre sur ton disque dur : tu es suspect.
Il est évidemment possible aussi de rendre ce fichier
invisible
Non, seulement caché, et trouvable par n'importe qui.
Filevault permet *aussi* de créer un volume chiffré à l'intérieur d'un volume chiffré. Il n'apparaît alors que comme un simple fichier. Qu'est-ce qui permettrait de supposer qu'il soit crypté ?
Tu as un fichier bizarre sur ton disque dur : tu es suspect.
Il est évidemment possible aussi de rendre ce fichier invisible
Non, seulement caché, et trouvable par n'importe qui.
pehache
Le 28/09/2020 à 18:21, pehache a écrit :
Le 28/09/2020 à 16:01, Gerald a écrit :
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
J'ai essayé de créé un volume chiffré sur un HHD externe de 2To, depuis mon iMac 2011 (12 Go de RAM) sous 10.12. Il en est à 40% en 2h30, avec un débit autour de 120Mo/s. Pour l'instant aucun problème de réactivité sur le Mac, je l'utilise normalement sans être gêné. - Quand j'ai lancé Veracrypt j'avais déjà un fichier de swap de 3Go environ. - Je n'ai pas fait gaffe au départ mais peu après le début de la création du volume j'ai constaté un volume de 5Go de "fichiers mis en cache" - Quand je fais un "sudo purge", ce volume tombe à moins de 1Go, puis remonte assez vite vers 5Go. Pendant l'exécution de "purge" l'avancement de la création du volume est à l'arrêt. J'en déduis qu'une grosse partie des 5Go en cache viennent de l'activité Veracrypt - quand je ferme quelques applis, le swap retombe à 1,5Go environ et les "fichiers mis en cache" grimpent à 6Go. L'OS donc la RAM libérée pour augmenter le cache - Si je rouvre les applis le swap bouge peu, mais les "fichiers mis en cache" tombent à moins de 5Go Tout parait donc normal, Veracrypt n'occupe lui même que 40Mo de RAM, et l'OS utilise la RAM dispo pour faire le cache d'écriture, sans solliciter anormalement le swap. (plus tard) Ca en est à 50%, mais l'avancement est devenu erratique... Ca avance pendant 20 secondes, ça bloque pendant 10 secondes, ça reprend pendant 20 secondes, etc... Mais l'ordi reste normalement réactif. (bien plus tard mais en ayant mis l'ordi en veille entre temps) Ca en est à 80%, mais l'avancement est de plus en plus lent. Maintenant c'est plutôt 10 secondes d'écriture, et 20 secondes de blocage. Du coup ça n'en finit plus. Je ne fais pas grand chose avec l'ordi et du volume des "fichiers mis en cache" est monté à 8Go et le swap à 3Go. Pour autant l'ordi est toujours normalement réactif, je peux travailler avec. Le process Veracrypt lui-même reste stable à 40Mo d'occupation. Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça marchait bien, mais après clairement Veracrypt a commencé à "brouter". -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
Le 28/09/2020 à 18:21, pehache a écrit :
Le 28/09/2020 à 16:01, Gerald a écrit :
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une
trentaine d'heures" dans ton message initial, de quelle opération
parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ?
Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à
écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les
calculs liés à la protection de la clé maîtresse et c'est indépendant
de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est
pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata
temporis (apparemment).
Info additionnelle : après reformatage du disque (toujours en ExFAT,
vérification par les outils systèmes, reprise du chiffrement à partir
d'un autre ordi, et alors que le premier quart semblait s'être
déroulé convenablement en 1h30, désormais (30% du processus) c'est
revenu au même délire : lenteur incroyable de l'ordi, roue de la mort
multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
J'ai essayé de créé un volume chiffré sur un HHD externe de 2To, depuis
mon iMac 2011 (12 Go de RAM) sous 10.12. Il en est à 40% en 2h30, avec
un débit autour de 120Mo/s. Pour l'instant aucun problème de réactivité
sur le Mac, je l'utilise normalement sans être gêné.
- Quand j'ai lancé Veracrypt j'avais déjà un fichier de swap de 3Go
environ.
- Je n'ai pas fait gaffe au départ mais peu après le début de la
création du volume j'ai constaté un volume de 5Go de "fichiers mis en cache"
- Quand je fais un "sudo purge", ce volume tombe à moins de 1Go, puis
remonte assez vite vers 5Go. Pendant l'exécution de "purge" l'avancement
de la création du volume est à l'arrêt. J'en déduis qu'une grosse partie
des 5Go en cache viennent de l'activité Veracrypt
- quand je ferme quelques applis, le swap retombe à 1,5Go environ et les
"fichiers mis en cache" grimpent à 6Go. L'OS donc la RAM libérée pour
augmenter le cache
- Si je rouvre les applis le swap bouge peu, mais les "fichiers mis en
cache" tombent à moins de 5Go
Tout parait donc normal, Veracrypt n'occupe lui même que 40Mo de RAM, et
l'OS utilise la RAM dispo pour faire le cache d'écriture, sans
solliciter anormalement le swap.
(plus tard)
Ca en est à 50%, mais l'avancement est devenu erratique... Ca avance
pendant 20 secondes, ça bloque pendant 10 secondes, ça reprend pendant
20 secondes, etc... Mais l'ordi reste normalement réactif.
(bien plus tard mais en ayant mis l'ordi en veille entre temps)
Ca en est à 80%, mais l'avancement est de plus en plus lent. Maintenant
c'est plutôt 10 secondes d'écriture, et 20 secondes de blocage. Du coup
ça n'en finit plus. Je ne fais pas grand chose avec l'ordi et du volume
des "fichiers mis en cache" est monté à 8Go et le swap à 3Go. Pour
autant l'ordi est toujours normalement réactif, je peux travailler avec.
Le process Veracrypt lui-même reste stable à 40Mo d'occupation.
Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça
marchait bien, mais après clairement Veracrypt a commencé à "brouter".
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes." (ST sur fr.bio.medecine)
"Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici."
(FLC sur fr.comp.sys.atari)
Le 28 septembre 2020 à 13:54, Pascal Hambourg a écrit :
Le 28/09/2020 à 13:41, pehache a écrit :
Le 28/09/2020 à 11:24, Pascal Hambourg a écrit :
Précisément. Donc quand tu as écris "le chiffrement prend une trentaine d'heures" dans ton message initial, de quelle opération parlais-tu exactement ?
Il parle de la création du volume VeraCrypt
Je confirme
En quoi cela consiste-t-il pour prendre autant de temps ? Avec cryptsetup, l'initialisation d'un conteneur chiffré se résume à écrire le superbloc LUKS. Ce qui prend le plus de temps, ce sont les calculs liés à la protection de la clé maîtresse et c'est indépendant de la taille du volume.
Ce que tu dis est plein de bon sens, mais dans le monde réel ce n'est pas le cas, ni pour moi ni pour pehache d'ailleurs, au prorata temporis (apparemment). Info additionnelle : après reformatage du disque (toujours en ExFAT, vérification par les outils systèmes, reprise du chiffrement à partir d'un autre ordi, et alors que le premier quart semblait s'être déroulé convenablement en 1h30, désormais (30% du processus) c'est revenu au même délire : lenteur incroyable de l'ordi, roue de la mort multicolore à chaque action (appel de menu ou autre), swap de 2 Go...
Ca ressemble bien à un bug de "fuite mémoire" dans VeraCrypt...
J'ai essayé de créé un volume chiffré sur un HHD externe de 2To, depuis mon iMac 2011 (12 Go de RAM) sous 10.12. Il en est à 40% en 2h30, avec un débit autour de 120Mo/s. Pour l'instant aucun problème de réactivité sur le Mac, je l'utilise normalement sans être gêné. - Quand j'ai lancé Veracrypt j'avais déjà un fichier de swap de 3Go environ. - Je n'ai pas fait gaffe au départ mais peu après le début de la création du volume j'ai constaté un volume de 5Go de "fichiers mis en cache" - Quand je fais un "sudo purge", ce volume tombe à moins de 1Go, puis remonte assez vite vers 5Go. Pendant l'exécution de "purge" l'avancement de la création du volume est à l'arrêt. J'en déduis qu'une grosse partie des 5Go en cache viennent de l'activité Veracrypt - quand je ferme quelques applis, le swap retombe à 1,5Go environ et les "fichiers mis en cache" grimpent à 6Go. L'OS donc la RAM libérée pour augmenter le cache - Si je rouvre les applis le swap bouge peu, mais les "fichiers mis en cache" tombent à moins de 5Go Tout parait donc normal, Veracrypt n'occupe lui même que 40Mo de RAM, et l'OS utilise la RAM dispo pour faire le cache d'écriture, sans solliciter anormalement le swap. (plus tard) Ca en est à 50%, mais l'avancement est devenu erratique... Ca avance pendant 20 secondes, ça bloque pendant 10 secondes, ça reprend pendant 20 secondes, etc... Mais l'ordi reste normalement réactif. (bien plus tard mais en ayant mis l'ordi en veille entre temps) Ca en est à 80%, mais l'avancement est de plus en plus lent. Maintenant c'est plutôt 10 secondes d'écriture, et 20 secondes de blocage. Du coup ça n'en finit plus. Je ne fais pas grand chose avec l'ordi et du volume des "fichiers mis en cache" est monté à 8Go et le swap à 3Go. Pour autant l'ordi est toujours normalement réactif, je peux travailler avec. Le process Veracrypt lui-même reste stable à 40Mo d'occupation. Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça marchait bien, mais après clairement Veracrypt a commencé à "brouter". -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes." (ST sur fr.bio.medecine) "Je suis ATARIste, et j'ai bien l'intention que l'on me respecte ici." (FLC sur fr.comp.sys.atari)
DV
pehache a écrit ceci :
Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça marchait bien, mais après clairement Veracrypt a commencé à "brouter".
Je n'osais trop rien dire à propos de VeraCrypt, parce que mon unique (et désastreux) essai de cette application sur Mac remonte à cinq ou six ans, mais d'après ce que tu écris, j'ai l'impression que ça ne s'est pas beaucoup amélioré. Je parle bien de la version pour Mac, parce que sur Windows, ça fonctionnait bien à l'époque (je n'ai jamais testé VeraCrypt sur Linux). -- Denis
pehache a écrit ceci :
Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça
marchait bien, mais après clairement Veracrypt a commencé à "brouter".
Je n'osais trop rien dire à propos de VeraCrypt, parce que mon unique
(et désastreux) essai de cette application sur Mac remonte à cinq ou
six ans, mais d'après ce que tu écris, j'ai l'impression que ça ne
s'est pas beaucoup amélioré.
Je parle bien de la version pour Mac, parce que sur Windows, ça
fonctionnait bien à l'époque (je n'ai jamais testé VeraCrypt sur
Linux).
Mais vu la lenteur désormais j'arrête là. Jusqu'à 40% (800Mo écrits) ça marchait bien, mais après clairement Veracrypt a commencé à "brouter".
Je n'osais trop rien dire à propos de VeraCrypt, parce que mon unique (et désastreux) essai de cette application sur Mac remonte à cinq ou six ans, mais d'après ce que tu écris, j'ai l'impression que ça ne s'est pas beaucoup amélioré. Je parle bien de la version pour Mac, parce que sur Windows, ça fonctionnait bien à l'époque (je n'ai jamais testé VeraCrypt sur Linux). -- Denis
