Économiser les écritures sur la mémoire mmc

Le 28/01/2019 à 12:13, Gigiair a écrit :

Ma machine est un Asus E203NAS équipé d'une mémoire emmc de 64Go et
livrée avec W10 qui en prend à peu près la moitié.

J'étais précédemment équipé d'un X205TA de la même marque sur lequel
j'avais viré le système d'origine pour installer Debian buster.
Le problème avec ces mémoires emmc est qu'elles n'ont pas une durée de
vie très longue, et qu'avant de défunter, elles peuvent créer de graves
désordres dans le système de fichiers.
J'avais installé le /home sur une sdcard qui n'a pas tenu très longtemps
≅ 2ans avant les premiers troubles.

Cela me semble être une curieuse démarche que d'acheter une machine dont
on pense d'emblée que les composants ne conviennent pas à l'usage
prévu...

Après, es-tu certain que eMMC = durée de vie faible ? Quand on cherche
les TBW des eMMC ce n'est pas si ridicule que ça (mais ça doit dépendre
aussi de la qualité du contrôleur -gestion de l'usure notamment)

En plus, avec un usage bureautique classique le volume d'écriture moyen
(qui est le facteur d'usure des mémoires flash) n'est quand même pas
très élevé.

Je cherche une configuration de ma nouvelle machine qui me permette
d'économiser les écritures sur les mémoires emmc. J'exclus les clés USB
ou les disques durs externes qui sont très fragiles sur une machine
destinée à être utilisée « à la volée » sans appui fixe, et donc
pouvant
facilement chuter. Les prises pouvant ainsi s'arracher et endommager la
carte mère.
J'ai acheté cette machine à cause de son extrême légèreté et pour
pouvoir l'utiliser sans appui fixe.
J'ai pensé à utiliser google drive ou équivalent, mais je n'ai pas
encore réussi à configurer, je ne sais pas si c'est possible, je
voudrais pouvoir écrire directement sur le gdrive et non pas cloner une
partition de service.

Avec les google drive, dropbox, et Cie, tu peux en général avoir une
synchro "on-demand" (quoique pas avec les formules "gratuites" en
général) : les fichiers ne sont pas téléchargés en local tant qu'on ne
les lit pas. Mais ça ne répond pas vraiment à ta demande, car dès qu'on
veut travailler sur un fichier il est synchronisé en local et les
lectures/écritures se font en local.

Des idées, des conseils, de préférence expérimentés pour économiser
les écritures sur la mmc ?

Sous Linux les trucs habituels pour les SSD : diminuer le paramètre de
swap, et monter en RAM certains dossiers comme /tmp, /var/log, etc... Mais
les montages en RAM diminuent d'autant la RAM disponible, évidemment.

Le 28/01/2019 à 16:44, Gigiair a écrit :

lun. 28 janv. 2019, pehache <pehache.7@gmail.com> disait :

Le 28/01/2019 à 12:13, Gigiair a écrit :

Ma machine est un Asus E203NAS équipé d'une mémoire emmc de 64Go et
livrée avec W10 qui en prend à peu près la moitié.

J'étais précédemment équipé d'un X205TA de la même marque sur
lequel
j'avais viré le système d'origine pour installer Debian buster.
Le problème avec ces mémoires emmc est qu'elles n'ont pas une durée
de
vie très longue, et qu'avant de défunter, elles peuvent créer de
graves
désordres dans le système de fichiers.
J'avais installé le /home sur une sdcard qui n'a pas tenu très
longtemps
≅ 2ans avant les premiers troubles.

Cela me semble être une curieuse démarche que d'acheter une machine dont
on pense d'emblée que les composants ne conviennent pas à l'usage
prévu...

Ce n'est pas le débat. Je trouve que la machine convient parfaitement à
mes besoins. j'essaye de l'exploiter au mieux de ses capacités.

Si dès le départ tu es inquiet pour la durée de vie d'un composant, je
ne trouve pas que la machine "convienne parfaitement", mais bon...

Après, es-tu certain que eMMC = durée de vie faible ? Quand on cherche
les TBW des eMMC ce n'est pas si ridicule que ça (mais ça doit dépendre
aussi de la qualité du contrôleur -gestion de l'usure notamment)

Comme je l'ai dit dans mon message initial, la machine que je suis en
train de configurer succède à une autre qui fonctionnait également sur
une emmc. Les problèmes que j'ai eu, je ne les ai pas inventés et c'est
la raison de ma migration.

Ben en soi ça prouve rien du tout, tu peux juste avoir eu un coup de
malchance avec cette machine. Une panne précoce peut arriver avec
n'importe quelle machine et n'importe quel composant.

En plus, avec un usage bureautique classique le volume d'écriture moyen
(qui est le facteur d'usure des mémoires flash) n'est quand même pas
très élevé.

Qu'est-ce qui te fait dire que j'utilise cette machine pour un usage
bureautique moyen ?

Ce genre de machine on l'achète rarement pour faire du montage intensif de
videos 4K :-)

Je n'utilise que très rarement des logiciels de
bureautique « classiques ». En général c'est pour ouvrir un document
produit par d'autres.

Soit, mais ça ne change rien à mon propos : il est fort possible que ton
usage -que tu ne détailles pas- ne mette aucunement en péril le disque
eMMC sur la durée de vie prévisible de la machine.

Je cherche une configuration de ma nouvelle machine qui me permette
d'économiser les écritures sur les mémoires emmc. J'exclus les clés
USB
ou les disques durs externes qui sont très fragiles sur une machine
destinée à être utilisée « à la volée » sans appui fixe, et donc
pouvant
facilement chuter. Les prises pouvant ainsi s'arracher et endommager la
carte mère.
J'ai acheté cette machine à cause de son extrême légèreté et pour
pouvoir l'utiliser sans appui fixe.
J'ai pensé à utiliser google drive ou équivalent, mais je n'ai pas
encore réussi à configurer, je ne sais pas si c'est possible, je
voudrais pouvoir écrire directement sur le gdrive et non pas cloner une
partition de service.

Avec les google drive, dropbox, et Cie, tu peux en général avoir une
synchro "on-demand" (quoique pas avec les formules "gratuites" en
général) : les fichiers ne sont pas téléchargés en local tant qu'on
ne
les lit pas. Mais ça ne répond pas vraiment à ta demande, car dès
qu'on
veut travailler sur un fichier il est synchronisé en local et les
lectures/écritures se font en local.

Ça n'a aucun intérêt pour mon problème.

Google drive permet un montage

Pas avec les outils officiels de Google. Si tu pensais à autre chose ça
aurait bien de le préciser.

donc j'espère qu'aucune écriture locale
ne se produit.

C'est possible, mais j'en doute. Il faudrait que le protocole de Google
Drive permette un accès au niveau des blocs et pas juste au niveau des
fichiers. Dans tous les cas il faut voir précisément l'outil utilisé
pour le montage.

Des idées, des conseils, de préférence expérimentés pour
économiser
les écritures sur la mmc ?

Sous Linux les trucs habituels pour les SSD : diminuer le paramètre de
swap, et monter en RAM certains dossiers comme /tmp, /var/log, etc... Mais
les montages en RAM diminuent d'autant la RAM disponible, évidemment.

/tmp est par défaut monté sur un ramdisk, mais pas /var/log. Je ne suis
pas sûr que ce soit une très bonne idée de le faire.

L'inconvénient est qu'en cas de crash on n'a pas les logs. On peut
toujours annuler le montage si ponctuellement on sait qu'on va avoir besoin
de consulter les logs après un reboot.

Je vais essayer de
déporter /var/log et la partition de swap sur une sdcard, plus facile à
changer en cas d'usure précoce que la mémoire interne que j'imagine
inamovible.

Pourquoi pas si tu sais que tu n'auras pas besoin d'utiliser le lecteur de
carte sd par ailleurs.

Le 28/01/2019 à 12:13, Gigiair a écrit :

Le problème avec ces mémoires emmc est qu'elles n'ont pas une durée de
vie très longue, et qu'avant de défunter, elles peuvent créer de graves
désordres dans le système de fichiers.
J'avais installé le /home sur une sdcard qui n'a pas tenu très longtemps
≅ 2ans avant les premiers troubles.

Les cartes SD, comme les clés USB, ne sont pas réputées pour leur
endurance en écriture. Elles sont prévues pour du stockage de données
qui changent peu. En outre leur vitesse est assez faible comparées aux
SSD et même aux disques durs.

J'exclus les clés USB qui sont très fragiles
Les prises pouvant ainsi s'arracher et endommager la carte mère.

Il existe des clés USB très compactes dépassant du connecteur USB de
quelques millimètres seulement.

Des idées, des conseils, de préférence expérimentés pour économiser
les écritures sur la mmc ?

Voici quelques idées.

Ne pas utiliser de swap si possible, ou régler une tendance à swapper
basse ("swappiness").

Utiliser tmpfs pour tout ce qui est possible : /tmp bien sûr, /var/log
si pas besoin de garder les logs des démarrages précédents, certaines
parties de /var/cache...

Utiliser le TRIM avec un système de fichiers qui le supporte, soit avec
l'option de montage 'discard', soit périodiquement avec fstrim (semble
la méthode actuellement préférée). Cela ne réduira pas les écritures par
le système hôte, mais réduira l'amplification d'écriture interne lors du
ramasse-miettes ou du nivellement de l'usure en évitant de recopier des
données périmées.

Utiliser l'option de montage "noatime" ou "nodiratime" au lieu de
l'option par défaut "relatime" à condition qu'aucun programme ne repose
sur la date de dernier accès (exemple connu : mutt).

Utiliser un système de fichiers qui limite et nivelle les écritures
comme f2fs ou nilfs2. Ce n'est pas forcément utile avec un SSD
sophistiqué qui sait déjà faire ça tout seul, plutôt avec une clé USB ou
une carte SD. Attention, ces systèmes de fichiers ont des inconvénients.
- F2fs n'est pas supporté par GRUB, il faut donc mettre /boot sur un
autre système de fichiers.
- Nilfs2 ne supporte pas les attributs POSIX étendus (donc les
"capacités", utilisées par certains exécutables pour éviter l'emploi du
bit SUID).
- Aucun n'est supporté par l'installateur Debian.
- Aucun n'est supporté par défaut par l'initramfs de Debian.

J'ai utilisé un peu tout cela pour installer Debian sur une clé USB,
mais je n'en ai pas un usage fréquent donc j'ai peu de recul sur
l'endurance.

Le 28/01/2019 à 16:44, Gigiair a écrit :

/tmp est par défaut monté sur un ramdisk

Très mauvaise idée, il vaut mieux utiliser un tmpfs, beaucoup plus
efficace et performant.

déporter /var/log et la partition de swap sur une sdcard, plus facile à
changer en cas d'usure précoce que la mémoire interne que j'imagine
inamovible.

Pas de problème à mettre /var/log sur une carte SD, mais le bénéfice
dépend du volume d'écriture qui n'est pas forcément énorme. En revanche
le swap sur une carte SD risque de faire ramer le système dès qu'il sera
utilisé.

Le 29/01/2019 à 21:53, Gigiair a écrit :

Voici quelques idées.

Ne pas utiliser de swap si possible, ou régler une tendance à swapper
basse ("swappiness").

Utiliser tmpfs pour tout ce qui est possible : /tmp bien sûr, /var/log
si pas besoin de garder les logs des démarrages précédents, certaines
parties de /var/cache...

Utiliser le TRIM avec un système de fichiers qui le supporte, soit
avec l'option de montage 'discard', soit périodiquement avec fstrim
(semble la méthode actuellement préférée). Cela ne réduira pas les
écritures par le système hôte, mais réduira l'amplification d'écriture
interne lors du ramasse-miettes ou du nivellement de l'usure en
évitant de recopier des données périmées.

Utiliser l'option de montage "noatime" ou "nodiratime" au lieu de
l'option par défaut "relatime" à condition qu'aucun programme ne
repose sur la date de dernier accès (exemple connu : mutt).

Utiliser un système de fichiers qui limite et nivelle les écritures
comme f2fs ou nilfs2. Ce n'est pas forcément utile avec un SSD
sophistiqué qui sait déjà faire ça tout seul, plutôt avec une clé USB
ou une carte SD. Attention, ces systèmes de fichiers ont des
inconvénients. - F2fs n'est pas supporté par GRUB, il faut donc mettre
/boot sur un autre système de fichiers.
- Nilfs2 ne supporte pas les attributs POSIX étendus (donc les
"capacités", utilisées par certains exécutables pour éviter l'emploi
du bit SUID).
- Aucun n'est supporté par l'installateur Debian.
- Aucun n'est supporté par défaut par l'initramfs de Debian.

J'ai utilisé un peu tout cela pour installer Debian sur une clé USB,
mais je n'en ai pas un usage fréquent donc j'ai peu de recul sur
l'endurance.

Merci pour tes informations. Le problème est que la mémoire eMMC n'est
pas amovible et que lorsqu'elle est trop dégradée, la machine est bonne
pour la benne. Sur ma nouvelle machine j'ai partitionné la carte en deux
volumes de 32Go, Je n'en utilise qu'un et je garde l'autre en réserve
lorsque le support sera trop dégradé.

Cela ne sert pas à grand chose, car même si tu n'utilises que les 32
premiers Go de la carte, le wear-leveling du contrôleur va quant à lui
répartir les écritures sur l'ensemble des 64Go physiques, justement pour
éviter d'écrire toujours dans les mêmes cellules physiques. Avec les SSD
l'OS n'a aucun contrôle sur les adresses physiques où sont réellement
écrites les données.

J'ai monté un Google Drive en utilisant google-drive-ocamlfuse que j'ai
trouvé en furetant sur le web mais les écritures et les effacements sont
vraiment très lents.

Et en plus tu n'as même pas la certitude de réduire les écritures. Car à
moins que cela ait changé depuis 2015 le fonctionnement par défaut de ce
genre de montage semble bien consister à télécharger le fichier entier
dans un cache local sur le disque pour le lire ou pour écrire dedans :

https://github.com/astrada/google-drive-ocamlfuse/issues/115
https://github.com/astrada/google-drive-ocamlfuse/issues/286

Ce fonctionnement pourrait même avoir pour résultat d'augmenter les
écritures (si tu lis régulièrement le même fichier, il va être
retéléchargé à chaque fois s'il n'est pas resté en cache).

Apparemment il y a des options pour streamer les "gros fichiers", auquel
cas c'est la RAM qui semble être utilisée comme cache pour ces fichiers.
Mais du coup il faut en avoir assez, et ce qui se passe quand on veut
écrire dans le fichier et pas simplement le lire n'est pas clair du tout...



--
"...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

Le 28/01/2019 à 13:09, pehache a écrit :

Le 28/01/2019 à 12:13, Gigiair a écrit :

Ma machine est un Asus E203NAS équipé d'une mémoire emmc de 64Go et
livrée avec W10 qui en prend à peu près la moitié.

J'étais précédemment équipé d'un X205TA de la même marque sur lequel
j'avais viré le système d'origine pour installer Debian buster.
Le problème avec ces mémoires emmc est qu'elles n'ont pas une durée de
vie très longue,

[...]

Après, es-tu certain que eMMC = durée de vie faible ? Quand on cherche les
TBW des eMMC ce n'est pas si ridicule que ça (mais ça doit dépendre aussi
de la qualité du contrôleur -gestion de l'usure notamment)

Bon, cette histoire m'a titillé et j'ai cherché en pratique quelles
étaient les différences entre les mémoires eMMC et les SSD.


Ce qui différe :

- l'interface : SATA ou PCIE pour les SSD, et interface spécifique pour
les eMMC, héritée des cartes MMC externes (dont dérivent les cartes SD).
Mais l'interface a beaucoup évolué depuis.

- un module eMMC est constitué d'une puce unique qui intégre un module
unique de mémoire flash et le contrôleur. Un SSD est généralement
constitué de plusieurs puces de mémoire flash, et d'un contrôleur
séparé. Cela explique les performances supérieures des SSD, car le
contrôleur gère les différentes puces flash en parallèle, à la
manière d'un RAID 0.

Ce qui est commun :

- Dans les deux cas c'est de la mémoire flash, caractérisée par un
nombre limitée d'écritures dans chaque cellule. Comme dans les SSD on
trouve dans les eMMC des cellules TLC (la mémoire flash la moins chère et
la moins endurante) en entrée de gamme, mais aussi des cellules MLC ou SLC
en montant en gamme.

- Dans les deux cas les contrôleurs gèrent le wear-leveling, ont un
mécanisme de garbage collector, et supportent le TRIM (en tous cas dans
les normes eMMC récentes).


En pratique il n'y a donc aucune raison que la durée de vie d'un stockage
eMMC soit inférieure à celle d'un SSD. En entrée de gamme avec des
cellules TLC, la règle du pouce est de considérer qu'un stockage de nGo
peut supporter un volume d'écriture total de l'ordre de 0.5*nTo. Donc une
eMMC de 64Go en TLC peut supporter 32To d'écritures... Sur 10 ans, cela
représente 9Go écrits par jour : il y a quand même de quoi voir venir.

(xpost et fu2 fr.comp.stockage)

Le 28/01/2019 à 13:09, pehache a écrit :

Le 28/01/2019 à 12:13, Gigiair a écrit :

Ma machine est un Asus E203NAS équipé d'une mémoire emmc de 64Go et
livrée avec W10 qui en prend à peu près la moitié.

J'étais précédemment équipé d'un X205TA de la même marque sur lequel
j'avais viré le système d'origine pour installer Debian buster.
Le problème avec ces mémoires emmc est qu'elles n'ont pas une durée de
vie très longue,

[...]

...es-tu certain que eMMC = durée de vie faible ? Quand on cherche les TBW
des eMMC ce n'est pas si ridicule que ça (mais ça doit dépendre aussi de la
qualité du contrôleur -gestion de l'usure notamment)

Bon, cette histoire m'a titillé et j'ai cherché en pratique quelles
étaient les différences entre les mémoires eMMC et les SSD.

Ce qui différe :

- l'interface : SATA ou PCIE pour les SSD, et interface spécifique pour
les eMMC, héritée des cartes MMC externes (dont dérivent les cartes SD).
Mais l'interface a beaucoup évolué depuis.

- un module eMMC est constitué d'une puce unique qui intégre un module
unique de mémoire flash et le contrôleur. Un SSD est généralement
constitué de plusieurs puces de mémoire flash, et d'un contrôleur
séparé. Cela explique les performances supérieures des SSD, car le
contrôleur gère les différentes puces flash en parallèle, à la
manière d'un RAID 0.

Ce qui est commun :

- Dans les deux cas c'est de la mémoire flash, caractérisée par un
nombre limitée d'écritures dans chaque cellule. Comme dans les SSD on
trouve dans les eMMC des cellules TLC (la mémoire flash la moins chère et
la moins endurante) en entrée de gamme, mais aussi des cellules MLC ou SLC
en montant en gamme.

- Dans les deux cas les contrôleurs gèrent le wear-leveling, ont un
mécanisme de garbage collector, et supportent le TRIM (en tous cas dans
les normes eMMC récentes).


En pratique il n'y a donc aucune raison que la durée de vie d'un stockage
eMMC soit inférieure à celle d'un SSD. En entrée de gamme avec des
cellules TLC, la règle du pouce est de considérer qu'un stockage de nGo
peut supporter un volume d'écriture total de l'ordre de 0.5*nTo. Donc une
eMMC de 64Go en TLC peut supporter 32To d'écritures... Sur 10 ans, cela
représente 9Go écrits par jour en moyenne : il y a quand même de quoi
voir venir.