Re: [Linux-31] Copier la table des partitions...

[Pascal Hambourg <pascal AT plouf.fr.eu.org>]

Le 19/07/2018 à 12:44, Jean-Marc Mongrelet (via linux-31 Mailing List) a 
écrit :
> Pas besoin de copier les UUID et labels... ça ne les utilise pas:
> =====================================================================
> $ cat /etc/fstab
> proc            /proc           proc    defaults          0       0
> /dev/mmcblk0p6  /boot           vfat    defaults          0       2
> /dev/mmcblk0p7  /               ext4    defaults,noatime  0       1
> # a swapfile is not a swap partition, no line here
> #   use  dphys-swapfile swap[on|off]  for that
> =====================================================================

D'accord. C'est acceptable si les noms de périphériques des partitions 
sont stables, ce qui est a priori le cas tant qu'il n'y a qu'un lecteur 
de carte SD/MMC.

> > Quelle est ton expérience du vieillissement d'une carte SD utilisée
> > avec un Raspberry Pi ? As-tu essayé F2FS, un système de fichiers conçu
> > pour ce type de stockage et supporté par le noyau de Raspbian ?
>
> En utilisation h24 il parait que cela tien 2 ans... en tous cas, j'en ai 
> déjà une qui a grillé!

En réalité cela doit aussi dépendre de l'usage qu'on en fait, et 
notamment du volume d'écriture.

> Je ne connaissais F2FS... mais maintenant c'est raté, car il faut le 
> configurer à l'installation!

Pas forcément. Puisque tu envisageais de formater la carte SD de 
sauvegarde et d'y copier les fichiers avec cp, tu pourrais aussi bien le 
faire en F2FS. Il devrait ensuite suffire de modifier le type de la 
racine dans /etc/fstab et le paramètre rootfstype= de la ligne de 
commande du noyau dans le fichier de configuration du chargeur 
d'amorçage qui doit se trouver dans la partition /boot.

> Parce qu'il faut éviter trop de cycles d’écritures sur une sd, car cela 
> use la sd...
> En faisant une copie bloc par bloc on copie sur toutes la sd... à 
> contrario par "cp -a" qui copie juste ce qui faut...

L'usure ne se mesure pas forcément au volume total d'écriture, cela 
dépend du fonctionnement de la FTL (flash translation layer) de la carte SD.

Une FTL sophistiquée comme celles des SSD fait du nivellement de l'usure 
en répartissant les écritures dans les blocs physiques, de sorte que 
même si on écrit beaucoup dans certains blocs logiques (par exemple le 
journal d'un système de fichiers journalisé comme ext4, la table 
d'allocation d'un système de fichier FAT, la MFT d'un système de 
fichiers NTFS...), la FTL écrit à chaque fois les nouvelles données dans 
des blocs physiques différents. On peut donc utiliser sans souci 
n'importe quel système de fichiers traditionnel sur un SSD.

La FTL d'une carte SD n'est pas aussi sophistiquée. Si son mécanisme de 
nivellement de l'usure est peu performant voire inexistant, il vaut 
mieux éviter d'écrire de façon répétitive dans les mêmes blocs comme va 
le faire une copie façon cp (écriture dans le journal, mise à jour des 
méta-données) et plutôt copier façon dd qui écrit au plus une fois dans 
chaque bloc.

A noter que F2FS est conçu pour les supports flash "bêtes" sans 
nivellement de l'usure et fonctionne comme la FTL des SSD en 
répartissant les écritures dans de nouveaux blocs.

> Puis si je 
> re-formate et re-copie à nouveau par "cp -a", je refais encore des 
> cycles de copies!

Il existe des alternatives plus performantes que dd pour la copie par 
blocs comme partimage ou partclone (utilisés par clonezilla) qui ne 
copient que les blocs utiles des systèmes de fichiers de types connus.

Mais si tu comptes faire des sauvegardes régulières, il serait peut-être 
plus efficace de faire les suivantes avec un outil comme rsync qui 
n'écrit que les différences, ce qui minimiserait le temps et les écritures.

> > Si le système de fichiers de la dernière partition supporte la
> > réduction, je réduirais légèrement le système de fichier, la partition
> > logique et la partition étendue avec de la marge pour que ça tienne
> > dans le pire cas de carte SD. Ainsi tu n'auras plus ce problème.
>
> Mais, comment peut-on savoir si la dernière partition supporte la 
> réduction ???

C'est ext4, il supporte la réduction "hors ligne", c'est-à-dire démonté, 
avec resize2fs ou gparted qui combine toutes les actions nécessaires.

> Mais là on réduit que la dernière partition... et pas la partition logique!

Pardon ? La dernière, c'est la partition logique (n° 7).

> De plus... c'est une manip sur la carte sd d'origine... ça fait flipper, 
> si tu perds le système de fichier pendant la réduction... ta tout faux, 
> car c'est ton original!

Attention, une réduction peut causer des écritures massives pour 
deplacer toutes les données situées au-delà de la taille désirée.

Tu peux faire une copie de la carte SD sur un disque ou un SSD soit 
comme sauvegarde, soit comme copie de travail pour la réduction.