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.
Bonjour, 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.
J'avais raté ce point : "clé USB" Les clé USB, même les bonnes, sont en général *beaucoup* plus lentes que les HDD. Je suppose que quand tu envisages de créer une volume chiffré de 3To c'est sur un HDD, donc tu ne peux absolument pas extrapoler les temps que tu as mesurés sur une clé.
Je viens de retester avec TrueCrypt (qui est l'ancêtre de VeraCrypt) sur mon iMac 2011, en créant une image chiffrée de 10Go (avec toutes options par défaut) : Sur le HDD interne : TrueCrypt sature le débit du disque à environ 100Mo/s. Temps de création 1mn40s, le process occupe 45% de CPU environ, et une occupation mémoire négligeable (quelques dizaines de Mo). Sur le SSD interne : TrueCrypt sature le débit du disque à environ 220Mo/s. Temps de création 40s environ, le process occupe 80% de CPU environ.
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière version récupérée à l'instant. J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de 100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt). Toujours une occupation mémoire faible... -- "...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 27/09/2020 à 16:05, pehache a écrit :
Le 27/09/2020 à 15:48, pehache a écrit :
Le 27/09/2020 à 06:19, Gerald a écrit :
Bonjour,
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.
J'avais raté ce point : "clé USB"
Les clé USB, même les bonnes, sont en général *beaucoup* plus lentes
que les HDD. Je suppose que quand tu envisages de créer une volume
chiffré de 3To c'est sur un HDD, donc tu ne peux absolument pas
extrapoler les temps que tu as mesurés sur une clé.
Je viens de retester avec TrueCrypt (qui est l'ancêtre de VeraCrypt) sur
mon iMac 2011, en créant une image chiffrée de 10Go (avec toutes options
par défaut) :
Sur le HDD interne : TrueCrypt sature le débit du disque à environ
100Mo/s. Temps de création 1mn40s, le process occupe 45% de CPU environ,
et une occupation mémoire négligeable (quelques dizaines de Mo).
Sur le SSD interne : TrueCrypt sature le débit du disque à environ
220Mo/s. Temps de création 40s environ, le process occupe 80% de CPU
environ.
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière
version récupérée à l'instant.
J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de
100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s
et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt).
Toujours une occupation mémoire faible...
--
"...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)
Bonjour, 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.
J'avais raté ce point : "clé USB" Les clé USB, même les bonnes, sont en général *beaucoup* plus lentes que les HDD. Je suppose que quand tu envisages de créer une volume chiffré de 3To c'est sur un HDD, donc tu ne peux absolument pas extrapoler les temps que tu as mesurés sur une clé.
Je viens de retester avec TrueCrypt (qui est l'ancêtre de VeraCrypt) sur mon iMac 2011, en créant une image chiffrée de 10Go (avec toutes options par défaut) : Sur le HDD interne : TrueCrypt sature le débit du disque à environ 100Mo/s. Temps de création 1mn40s, le process occupe 45% de CPU environ, et une occupation mémoire négligeable (quelques dizaines de Mo). Sur le SSD interne : TrueCrypt sature le débit du disque à environ 220Mo/s. Temps de création 40s environ, le process occupe 80% de CPU environ.
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière version récupérée à l'instant. J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de 100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt). Toujours une occupation mémoire faible... -- "...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)
pehache
Le 27/09/2020 à 15:17, jp willm a écrit :
Bonjour, Le 27/09/2020 à 06:19, Gerald a écrit :
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.
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet : <https://www.youtube.com/watch?v=LrOFSbkfTZw>
20mn de video pour des explications qui tiendraient probablement sur 2 pages lues en 3mn... -- "...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 27/09/2020 à 15:17, jp willm a écrit :
Bonjour,
Le 27/09/2020 à 06:19, Gerald a écrit :
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.
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet :
<https://www.youtube.com/watch?v=LrOFSbkfTZw>
20mn de video pour des explications qui tiendraient probablement sur 2
pages lues en 3mn...
--
"...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)
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.
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet : <https://www.youtube.com/watch?v=LrOFSbkfTZw>
20mn de video pour des explications qui tiendraient probablement sur 2 pages lues en 3mn... -- "...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)
Stéphane CARPENTIER
Le 27-09-2020, Gerald a écrit :
[...] cryptage, [...] chiffrage [...]
Je ne vais pas beaucoup aider sur le sujet parce que je n'y connais rien en Windowserie mais au boulot nos disques Windows sont chiffrés et ça ne rame pas vraiment. Il doit donc exister quelque chose, je ne sais pas quoi, je ne sais pas non plus si c'est compatible Linux/Mac. Par contre, niveau vocabulaire, je souhaite juste apporter une précision parce que je vois que ça revient et que ce n'est donc pas juste une étourderie. En gros, lorsque Alice veut envoyer un message à Bob, elle utilise le chiffrement pour protéger son message. Puis, Bob, va utiliser le déchiffrement pour lire le message. Le but est de se protéger de Charlie, le voleur qui veut essayer de le décrypter. De façon stricte, le cryptage n'a donc aucun sens puisque ça reviendrait à essayer de coder son message sans savoir comment faire. Cependant, comme c'est rentré dans le langage courant, disons que c'est synonyme de chiffrement et ce n'est pas la raison de mon intervention. Le mot qui n'a rien à faire ici, c'est le chiffrage, c'est un terme entièrement valide mais dans un autre contexte qui n'a rien à voir avec ta question. Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me coûter la mise en place de l'action. Que ce soit le coût du disque dur, de la licence et/ou de la main d'œuvre. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
Le 27-09-2020, Gerald <voir_le_reply_to@car_ici.invalid> a écrit :
[...] cryptage, [...] chiffrage [...]
Je ne vais pas beaucoup aider sur le sujet parce que je n'y connais rien
en Windowserie mais au boulot nos disques Windows sont chiffrés et ça ne
rame pas vraiment. Il doit donc exister quelque chose, je ne sais pas
quoi, je ne sais pas non plus si c'est compatible Linux/Mac.
Par contre, niveau vocabulaire, je souhaite juste apporter une
précision parce que je vois que ça revient et que ce n'est donc pas
juste une étourderie.
En gros, lorsque Alice veut envoyer un message à Bob, elle utilise le
chiffrement pour protéger son message. Puis, Bob, va utiliser le
déchiffrement pour lire le message. Le but est de se protéger de
Charlie, le voleur qui veut essayer de le décrypter.
De façon stricte, le cryptage n'a donc aucun sens puisque ça
reviendrait à essayer de coder son message sans savoir comment faire.
Cependant, comme c'est rentré dans le langage courant, disons que c'est
synonyme de chiffrement et ce n'est pas la raison de mon intervention.
Le mot qui n'a rien à faire ici, c'est le chiffrage, c'est un terme
entièrement valide mais dans un autre contexte qui n'a rien à voir avec
ta question.
Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me
coûter la mise en place de l'action. Que ce soit le coût du disque dur,
de la licence et/ou de la main d'œuvre.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io
Je ne vais pas beaucoup aider sur le sujet parce que je n'y connais rien en Windowserie mais au boulot nos disques Windows sont chiffrés et ça ne rame pas vraiment. Il doit donc exister quelque chose, je ne sais pas quoi, je ne sais pas non plus si c'est compatible Linux/Mac. Par contre, niveau vocabulaire, je souhaite juste apporter une précision parce que je vois que ça revient et que ce n'est donc pas juste une étourderie. En gros, lorsque Alice veut envoyer un message à Bob, elle utilise le chiffrement pour protéger son message. Puis, Bob, va utiliser le déchiffrement pour lire le message. Le but est de se protéger de Charlie, le voleur qui veut essayer de le décrypter. De façon stricte, le cryptage n'a donc aucun sens puisque ça reviendrait à essayer de coder son message sans savoir comment faire. Cependant, comme c'est rentré dans le langage courant, disons que c'est synonyme de chiffrement et ce n'est pas la raison de mon intervention. Le mot qui n'a rien à faire ici, c'est le chiffrage, c'est un terme entièrement valide mais dans un autre contexte qui n'a rien à voir avec ta question. Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me coûter la mise en place de l'action. Que ce soit le coût du disque dur, de la licence et/ou de la main d'œuvre. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
Pascal Hambourg
Le 27/09/2020 à 15:05, Gerald a écrit :
Si, et bizarrement : ça occupe bien les six processeurs "en alternance" sans les saturer
Donc pas tous en même temps ?
(comme le ferait un rip vidéo), c'est juste marqué 100%, mais l'ordi devient, progressivement, au fil du cryptage, quasi inutilisable.
Si ça empire progressivement alors que l'occupation CPU reste stable, ce n'est pas un problème de CPU mais probablement d'occupation mémoire : les données écrites dans le volume chiffré peuvent avoir tendance à remplacer les données des fichiers utilisés par les autres processus dans le cache disque en mémoire, voire à faire grossir la mémoire allouée au cache et à forcer le swap des autres processus.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
MAIS, je n'ai pas réessayé dans un contexte différent (vu le temps !) juste confirmé, en test sur une clé avec un volume chiffré de petite taille, la proportionnalité des temps de chiffrage
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ? La création d'un volume chiffré vide ? Ce n'est pas du chiffrement, c'est de l'écriture de données aléatoires pour qu'on ne puisse pas distinguer les zones contenant des données chiffrées et celles ne contenant rien. Les clés USB, c'est généralement mauvais en écriture (et guère meilleur en lecture).
D'une image disque virtuelle créée dans un volume lui-même non chiffré. Image de 2,7 To, donc, max autorisé sur un disque de 3 To. Disque formaté en exFat et image itou (pour l'interopérabilité).
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement (minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par FUSE en espace utilisateur, donc avec des performances médiocres. Si en plus tu empiles deux couches d'exFAT, c'est encore pire.
Le 27/09/2020 à 15:05, Gerald a écrit :
Si, et bizarrement : ça occupe bien les six processeurs "en
alternance" sans les saturer
Donc pas tous en même temps ?
(comme le ferait un rip vidéo), c'est
juste marqué 100%, mais l'ordi devient, progressivement, au fil du
cryptage, quasi inutilisable.
Si ça empire progressivement alors que l'occupation CPU reste stable, ce
n'est pas un problème de CPU mais probablement d'occupation mémoire :
les données écrites dans le volume chiffré peuvent avoir tendance à
remplacer les données des fichiers utilisés par les autres processus
dans le cache disque en mémoire, voire à faire grossir la mémoire
allouée au cache et à forcer le swap des autres processus.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
MAIS, je n'ai pas réessayé dans un contexte différent (vu le temps !)
juste confirmé, en test sur une clé avec un volume chiffré de petite
taille, la proportionnalité des temps de chiffrage
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ?
La création d'un volume chiffré vide ? Ce n'est pas du chiffrement,
c'est de l'écriture de données aléatoires pour qu'on ne puisse pas
distinguer les zones contenant des données chiffrées et celles ne
contenant rien.
Les clés USB, c'est généralement mauvais en écriture (et guère meilleur
en lecture).
D'une image disque virtuelle créée dans un volume lui-même non
chiffré. Image de 2,7 To, donc, max autorisé sur un disque de 3 To.
Disque formaté en exFat et image itou (pour l'interopérabilité).
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement
(minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par
FUSE en espace utilisateur, donc avec des performances médiocres. Si en
plus tu empiles deux couches d'exFAT, c'est encore pire.
Si, et bizarrement : ça occupe bien les six processeurs "en alternance" sans les saturer
Donc pas tous en même temps ?
(comme le ferait un rip vidéo), c'est juste marqué 100%, mais l'ordi devient, progressivement, au fil du cryptage, quasi inutilisable.
Si ça empire progressivement alors que l'occupation CPU reste stable, ce n'est pas un problème de CPU mais probablement d'occupation mémoire : les données écrites dans le volume chiffré peuvent avoir tendance à remplacer les données des fichiers utilisés par les autres processus dans le cache disque en mémoire, voire à faire grossir la mémoire allouée au cache et à forcer le swap des autres processus.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
MAIS, je n'ai pas réessayé dans un contexte différent (vu le temps !) juste confirmé, en test sur une clé avec un volume chiffré de petite taille, la proportionnalité des temps de chiffrage
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ? La création d'un volume chiffré vide ? Ce n'est pas du chiffrement, c'est de l'écriture de données aléatoires pour qu'on ne puisse pas distinguer les zones contenant des données chiffrées et celles ne contenant rien. Les clés USB, c'est généralement mauvais en écriture (et guère meilleur en lecture).
D'une image disque virtuelle créée dans un volume lui-même non chiffré. Image de 2,7 To, donc, max autorisé sur un disque de 3 To. Disque formaté en exFat et image itou (pour l'interopérabilité).
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement (minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par FUSE en espace utilisateur, donc avec des performances médiocres. Si en plus tu empiles deux couches d'exFAT, c'est encore pire.
jp willm
Le 27/09/2020 à 16:30, pehache a écrit :
20mn de video pour des explications qui tiendraient probablement sur 2 pages lues en 3mn...
Peut-être, mais je trouve qu'il explique bien et use de répétitions pour mieux accentuer :) -- jp willm http://willms.yj.fr/willms/index.html
Le 27/09/2020 à 16:30, pehache a écrit :
20mn de video pour des explications qui tiendraient probablement sur 2
pages lues en 3mn...
Peut-être, mais je trouve qu'il explique bien et use de répétitions pour
mieux accentuer :)
20mn de video pour des explications qui tiendraient probablement sur 2 pages lues en 3mn...
Peut-être, mais je trouve qu'il explique bien et use de répétitions pour mieux accentuer :) -- jp willm http://willms.yj.fr/willms/index.html
Gerald
Le 27 septembre 2020 à 16:16, pehache a écrit :
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière version récupérée à l'instant. J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de 100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt). Toujours une occupation mémoire faible...
Merci beaucoup d'avoir pris le temps de ces tests. La cible étant un HDD externe de 3 To, si on part de tes résultats de 100s pour 10Go, ça nous donnerait du 10000s pour 1To, 30000s pour 3To, /3600 = 8h20. Bon. Ça resterait raisonnable (le transfert des données lui-même doit prendre ce temps aussi, c'est le débit USB qui limite). Ça laisse entendre que, par rapport à ta config, j'ai rencontré un problème (peut-être hardware ?) qui m'oriente vers une modification des ma configuration et un nouvel essai. Penses-tu que le formatage en ExFAT puisse être en cause ? Il me semble qu'on n'a guère le choix pour être inter-opérable : sur le mac, en dehors des formats "maison", on n'a le choix qu'entre FAT et ExFat, et il me semble que FAT ne supporte pas les fichiers >4Go... (or j'ai des vidéos dans le tas). Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ? Il me semblait que les cartes du Raspberry Pi étaient formatées ainsi par défaut... mais j'ai peut-être halluciné... Grand merci à nouveau pour ta patience. Note que, mine de rien, des réponses valides à ces question pourraient avoir de l'intérêt, y compris pour les linuxiens de passage ou ici présents, et que pour cette raison on n'est pas hors-charte ! Salutations ! -- Gerald
Le 27 septembre 2020 à 16:16, pehache a écrit :
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière
version récupérée à l'instant.
J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de
100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s
et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt).
Toujours une occupation mémoire faible...
Merci beaucoup d'avoir pris le temps de ces tests. La cible étant un
HDD externe de 3 To, si on part de tes résultats de 100s pour 10Go,
ça nous donnerait du 10000s pour 1To, 30000s pour 3To, /3600 = 8h20.
Bon. Ça resterait raisonnable (le transfert des données lui-même doit
prendre ce temps aussi, c'est le débit USB qui limite).
Ça laisse entendre que, par rapport à ta config, j'ai rencontré un
problème (peut-être hardware ?) qui m'oriente vers une modification
des ma configuration et un nouvel essai. Penses-tu que le formatage
en ExFAT puisse être en cause ? Il me semble qu'on n'a guère le choix
pour être inter-opérable : sur le mac, en dehors des formats
"maison", on n'a le choix qu'entre FAT et ExFat, et il me semble que
FAT ne supporte pas les fichiers >4Go... (or j'ai des vidéos dans le
tas). Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ? Il
me semblait que les cartes du Raspberry Pi étaient formatées ainsi
par défaut... mais j'ai peut-être halluciné...
Grand merci à nouveau pour ta patience. Note que, mine de rien, des
réponses valides à ces question pourraient avoir de l'intérêt, y
compris pour les linuxiens de passage ou ici présents, et que pour
cette raison on n'est pas hors-charte ! Salutations !
Et pour bien faire j'ai refait la manipe avec VeraCrypt, dernière version récupérée à l'instant. J'ai des chiffres très semblables : 1mn40s sur le HDD avec un débit de 100Mo/s et 35% d'occupation COU, 30s sur le SSD avec un débit de 280Mo/s et 75% d'occupation CPU (donc plus rapide que le vieux TrueCrypt). Toujours une occupation mémoire faible...
Merci beaucoup d'avoir pris le temps de ces tests. La cible étant un HDD externe de 3 To, si on part de tes résultats de 100s pour 10Go, ça nous donnerait du 10000s pour 1To, 30000s pour 3To, /3600 = 8h20. Bon. Ça resterait raisonnable (le transfert des données lui-même doit prendre ce temps aussi, c'est le débit USB qui limite). Ça laisse entendre que, par rapport à ta config, j'ai rencontré un problème (peut-être hardware ?) qui m'oriente vers une modification des ma configuration et un nouvel essai. Penses-tu que le formatage en ExFAT puisse être en cause ? Il me semble qu'on n'a guère le choix pour être inter-opérable : sur le mac, en dehors des formats "maison", on n'a le choix qu'entre FAT et ExFat, et il me semble que FAT ne supporte pas les fichiers >4Go... (or j'ai des vidéos dans le tas). Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ? Il me semblait que les cartes du Raspberry Pi étaient formatées ainsi par défaut... mais j'ai peut-être halluciné... Grand merci à nouveau pour ta patience. Note que, mine de rien, des réponses valides à ces question pourraient avoir de l'intérêt, y compris pour les linuxiens de passage ou ici présents, et que pour cette raison on n'est pas hors-charte ! Salutations ! -- Gerald
Gerald
Le 27 septembre 2020 à 15:17, jp willm a écrit :
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet : <https://www.youtube.com/watch?v=LrOFSbkfTZw>
Merci pour ton suivi. Malheureusement cette solution, certainement excellente en mono-environnement, ne semble pas multiplateforme, ce qui constitue la base de ma recherche... Car même si je bascule sous Linux totalement (auquel cas j'examinerai évidememnt l'option qu'il suggère, le problème va persister d'une partie de ma famille restée sous MacOS et l'autre sous Windows... Toute la question restane, dans cette interopérabilité, de disposer de disques d'archives lisibles par tous et interchangeables. -- Gerald
Le 27 septembre 2020 à 15:17, jp willm a écrit :
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet :
<https://www.youtube.com/watch?v=LrOFSbkfTZw>
Merci pour ton suivi. Malheureusement cette solution, certainement
excellente en mono-environnement, ne semble pas multiplateforme, ce
qui constitue la base de ma recherche...
Car même si je bascule sous Linux totalement (auquel cas j'examinerai
évidememnt l'option qu'il suggère, le problème va persister d'une
partie de ma famille restée sous MacOS et l'autre sous Windows...
Toute la question restane, dans cette interopérabilité, de disposer
de disques d'archives lisibles par tous et interchangeables.
Adrien a publié récemment un tuto intéressant et bien fait à ce sujet : <https://www.youtube.com/watch?v=LrOFSbkfTZw>
Merci pour ton suivi. Malheureusement cette solution, certainement excellente en mono-environnement, ne semble pas multiplateforme, ce qui constitue la base de ma recherche... Car même si je bascule sous Linux totalement (auquel cas j'examinerai évidememnt l'option qu'il suggère, le problème va persister d'une partie de ma famille restée sous MacOS et l'autre sous Windows... Toute la question restane, dans cette interopérabilité, de disposer de disques d'archives lisibles par tous et interchangeables. -- Gerald
Gerald
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
Le 27/09/2020 à 15:05, Gerald a écrit :
Si, et bizarrement : ça occupe bien les six processeurs "en alternance" sans les saturer
Donc pas tous en même temps ?
apparemment oui. (mais ma visualisation est médiocre)
Si ça empire progressivement alors que l'occupation CPU reste stable, ce n'est pas un problème de CPU mais probablement d'occupation mémoire :
on est d'accord.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
Oui, c'est le terme utilisé par Apple dans la version française du système... (ou peut-être par l'utilitaire de visualisation que j'utilise (iStatsMenu) j'ai copié *bêtement*.
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Dont acte pour chiffrement. Et par là je n'entends pas grand chose :-) Je *souhaiterais* juste trouver une solution équivalente à Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte" en lecture que si fourniture du mot de passe. Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané. Une fois le volume démonté, si on ne dispose pas du mdp, il ne sert qu'à caler les portes. Je ne prétends rien ni à rien, je suis juste en recherche...
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement (minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par FUSE en espace utilisateur, donc avec des performances médiocres. Si en plus tu empiles deux couches d'exFAT, c'est encore pire.
OK, bien noté. DONC ? Quel format suggères-tu, inter-opérable en lecture/écriture, et qui supporte des tailles de fichiers supérieures à 4 Go ?
D'avance merci. -- Gerald
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
Le 27/09/2020 à 15:05, Gerald a écrit :
>
Si, et bizarrement : ça occupe bien les six processeurs "en
alternance" sans les saturer
Donc pas tous en même temps ?
apparemment oui. (mais ma visualisation est médiocre)
Si ça empire progressivement alors que l'occupation CPU reste stable, ce
n'est pas un problème de CPU mais probablement d'occupation mémoire :
on est d'accord.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
Oui, c'est le terme utilisé par Apple dans la version française du
système... (ou peut-être par l'utilitaire de visualisation que
j'utilise (iStatsMenu) j'ai copié *bêtement*.
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Dont acte pour chiffrement. Et par là je n'entends pas grand chose
:-) Je *souhaiterais* juste trouver une solution équivalente à
Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte"
en lecture que si fourniture du mot de passe. Tout son contenu est
chiffré et déchiffré "à la volée" au fur et à mesure des demandes de
visualisation ou utilisation du User. Les données copiées dans un
sens ou dans l'autre font l'objet d'un codage/décodage instantané.
Une fois le volume démonté, si on ne dispose pas du mdp, il ne sert
qu'à caler les portes. Je ne prétends rien ni à rien, je suis juste
en recherche...
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement
(minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par
FUSE en espace utilisateur, donc avec des performances médiocres. Si en
plus tu empiles deux couches d'exFAT, c'est encore pire.
OK, bien noté. DONC ? Quel format suggères-tu, inter-opérable en
lecture/écriture, et qui supporte des tailles de fichiers supérieures
à 4 Go ?
Le 27 septembre 2020 à 17:29, Pascal Hambourg a écrit :
Le 27/09/2020 à 15:05, Gerald a écrit :
Si, et bizarrement : ça occupe bien les six processeurs "en alternance" sans les saturer
Donc pas tous en même temps ?
apparemment oui. (mais ma visualisation est médiocre)
Si ça empire progressivement alors que l'occupation CPU reste stable, ce n'est pas un problème de CPU mais probablement d'occupation mémoire :
on est d'accord.
La "permutation mémoire" atteint dans les 5 Go
Qu'est-ce que c'est ? Une traduction pourrie pour l'occupation du swap ?
Oui, c'est le terme utilisé par Apple dans la version française du système... (ou peut-être par l'utilitaire de visualisation que j'utilise (iStatsMenu) j'ai copié *bêtement*.
"Chiffrement". D'ailleurs qu'entends-tu exactement par "chiffrement" ?
Dont acte pour chiffrement. Et par là je n'entends pas grand chose :-) Je *souhaiterais* juste trouver une solution équivalente à Filevault2 d'Apple : un volume chiffré (réel ou virtuel), ne "monte" en lecture que si fourniture du mot de passe. Tout son contenu est chiffré et déchiffré "à la volée" au fur et à mesure des demandes de visualisation ou utilisation du User. Les données copiées dans un sens ou dans l'autre font l'objet d'un codage/décodage instantané. Une fois le volume démonté, si on ne dispose pas du mdp, il ne sert qu'à caler les portes. Je ne prétends rien ni à rien, je suis juste en recherche...
A moins d'utiliser un noyau Linux récent qui supporte exFAT nativement (minimum 5.4, mais de préférence au moins 5.7), exFAT doit être géré par FUSE en espace utilisateur, donc avec des performances médiocres. Si en plus tu empiles deux couches d'exFAT, c'est encore pire.
OK, bien noté. DONC ? Quel format suggères-tu, inter-opérable en lecture/écriture, et qui supporte des tailles de fichiers supérieures à 4 Go ?
D'avance merci. -- Gerald
Gerald
Le 27 septembre 2020 à 16:32, Stéphane CARPENTIER a écrit :
Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me coûter la mise en place de l'action. Que ce soit le coût du disque dur, de la licence et/ou de la main d'œuvre.
Effectivement, bien vu. Chiffrement, donc ! Merci. -- Gerald
Le 27 septembre 2020 à 16:32, Stéphane CARPENTIER a écrit :
Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me
coûter la mise en place de l'action. Que ce soit le coût du disque dur,
de la licence et/ou de la main d'œuvre.
Effectivement, bien vu. Chiffrement, donc ! Merci.
Le 27 septembre 2020 à 16:32, Stéphane CARPENTIER a écrit :
Si je demande un chiffrage, je m'attends à ce qu'on me dise ce que va me coûter la mise en place de l'action. Que ce soit le coût du disque dur, de la licence et/ou de la main d'œuvre.
Effectivement, bien vu. Chiffrement, donc ! Merci. -- Gerald
Stéphane CARPENTIER
Le 27-09-2020, Gerald a écrit :
Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ?
C'est toujours pareil, ça dépend de ce que tu veux faire. Si tu veux formater un disque pour utilisation pure Linux, oui, c'est un mauvais chois. Mais si c'est une partition d'échange avec Mac et Windows, si c'est le seul formatage possible (ie: pour Mac et Windows, pour Linux c'est pas le seul), tu n'as pas le choix. Il ne va pas te conseiller un meilleur formatage Linux qui ne peux pas être lu sur tes autres systèmes.
et que pour cette raison on n'est pas hors-charte !
C'est pas forcément le plus en charte, mais vu les messages actuels, ça change de pticlou. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
Le 27-09-2020, Gerald <voir_le_reply_to@car_ici.invalid> a écrit :
Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ?
C'est toujours pareil, ça dépend de ce que tu veux faire. Si tu veux
formater un disque pour utilisation pure Linux, oui, c'est un mauvais
chois. Mais si c'est une partition d'échange avec Mac et Windows, si
c'est le seul formatage possible (ie: pour Mac et Windows, pour Linux
c'est pas le seul), tu n'as pas le choix. Il ne va pas te conseiller un
meilleur formatage Linux qui ne peux pas être lu sur tes autres
systèmes.
et que pour cette raison on n'est pas hors-charte !
C'est pas forcément le plus en charte, mais vu les messages actuels, ça
change de pticlou.
--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io
Confirmes-tu que, sous Linux, ExFAT est un mauvais choix ?
C'est toujours pareil, ça dépend de ce que tu veux faire. Si tu veux formater un disque pour utilisation pure Linux, oui, c'est un mauvais chois. Mais si c'est une partition d'échange avec Mac et Windows, si c'est le seul formatage possible (ie: pour Mac et Windows, pour Linux c'est pas le seul), tu n'as pas le choix. Il ne va pas te conseiller un meilleur formatage Linux qui ne peux pas être lu sur tes autres systèmes.
et que pour cette raison on n'est pas hors-charte !
C'est pas forcément le plus en charte, mais vu les messages actuels, ça change de pticlou. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
