Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 05/03/2014, à 11:29

obibann

[Résolu] Déplacer des données sur le disque, octets par octets

Bonjour,

Je souhaiterai savoir s'il existe des utilitaire pour déplacer des données sur le système de fichier ext4, octets par octets.
Mon but est de faire en sorte que les n premiers octets de mon FS soient libre, sans pour tant que les données s'y trouvant soient perdues (donc les déplacer).

Merci smile

Dernière modification par obibann (Le 18/03/2014, à 11:54)


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#2 Le 05/03/2014, à 12:33

psyphi

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Oui avec dd smile

Hors ligne

#3 Le 05/03/2014, à 12:52

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Mon but est de faire en sorte que les n premiers octets de mon FS soient libre, sans pour tant que les données s'y trouvant soient perdues (donc les déplacer).

C'est vrai que c'est possible avec dd. En revanche, il ne sera plus possible de monter le système de fichier une fois qu'il ne sera plus à la bonne place dans  la partition. (du moins pas sans un artifice)

C'est quoi le but de la manoeuvre ? Parce que a priori ça n'a aucun sens

edit : Je précise. Il est possible de décaler tout le contenu de la partition. Mais décaler seulement une partie rendra le système de fichier totalement invalide.

Dernière modification par jamesbad000 (Le 05/03/2014, à 12:56)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#4 Le 05/03/2014, à 14:14

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Je comprends que vous puissiez penser que ça n'a pas de sens, je vais vous expliquer.
En fait au taf, nous avons des disques qui ont été mal configurés. Ceux-ci n'ont pas été partitionnés.

En d'autres termes, ils ont installé ext4 directement sur le device (mkfs.ext4 /dev/sdb).

Ce que je souhaite faire, c'est installer une table de partition sur le disque. J'arrive à mes fins si j'installe une table MBR car les 512 premiers octets du disque ne sont pas écris, donc la table de partition peut s'installer sans que les données soient touchées. Avec quelques manip dd, parted, e2fsck, resize2fs j'arrive à revenir dans une situation disque partitionné avec une partition ext4 fonctionnelle sans perdre mes données.

Ça ce complique sur les gros disques : ils font plus de 2.2To et dnc il faut installer une table GPT. Seul problème, elle va occuper plus d'espace et empiéter sur la partie du disque contenant des données. j'arrive donc à installer la table, restaurer mon ext4 sur la partition, mais les données, bien que visible, sont KO (hash md5) car GPT a écrasé les premiers octets contenant des données.

Donc, je cherche un moyen pour déplacer les données en début de disque vers un autre endroit contenant de l'espace libre afin que ma GPT n'écrase pas de données utile..

Merci


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#5 Le 05/03/2014, à 18:49

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Ok je comprend mieux.

J'arrive à mes fins si j'installe une table MBR car les 512 premiers octets du disque ne sont pas écris

Mais je ne vois pas en quoi le problème est fanchement différent entre un partitionnement msdos et GPT : Car mkfs.ext4 /dev/sdb créé un système de fichier qui commence au secteur 0 du disque. Et même si les 2 1ers secteurs du système de fichiers sont vierge, on ne peut amputer le système de fichier de ses 2 secteurs.

Dans les 2 cas, il faut donc décaler le système de fichier (certes plus avec gpt, mais décaler d'un ou de x secteurs reviens au même)

Par ailleurs, je reviens sur ce que j'ai dis. Décaler directement le système de fichier avec dd me semble difficile sans passer par une recopie sur un autre support. Vu qu'on cherche a déplacer vers la fin du disque, il faudrait copier à rebour depuis la fin du système de fichier, et dd ne semble pas prévu pour ça. (Sans parler que faire ce genre de manip sans sauvegarde est hautement risqué)

La procédure la plus simple et sur serait :
- redimentionner le système de fichier si nécessaire pour qu'il ne dépasse pas de la future partition
-  copier ailleurs (image disque tronqué à la nouvelle taile du système de fichier, éventuellement compressée, avec

dd if=/dev/sdb bs="la taille de bloc du FS" count="Le nombre de bloc du FS" | gzip > sdb.img) 

- créer la partition (sdb1)
- réintégrer l'image dans la partition 

gunzip sdb.img | dd of=/dev/sdb1

j'arrive donc à installer la table, restaurer mon ext4 sur la partition, mais les données, bien que visible, sont KO (hash md5) car GPT a écrasé les premiers octets contenant des données.

Ca je ne comprend pas. Comment GPT peut écraser les données avant qu'on les restaure ??

Edit : En fin de compte la procédure que j'ai donnée ci-dessus n'a aucun avantage par rapport à une copie des fichiers avec cp -a puis réintégration des fichiers après avoir fait un partitionnement correcte.

Dernière modification par jamesbad000 (Le 06/03/2014, à 13:11)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#6 Le 06/03/2014, à 14:55

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Après une journée de recherche, j'ai trouvé le mode opératoire à suivre pour convertir mon disque directement formaté en disque avec partition GPT, sans perte de données et sans passer par une sauvegarde complète.

Voici une copie du mode opératoire que j'ai rédigé :

-----

1.    RAPPEL DU PROBLEME POSE
Les serveurs contiennent des disques sans table de partitions.
Les disques sont directement formatés en ext4  sans passer par la création d’une ou plusieurs partitions.

Ce document décrit le mode opératoire permettant de passer d’un disque formaté à un disque partitionné sans perte de données.

La table des partitions utilisée sera GPT.

Important :
Les manipulations indiquées ci-dessous sont très critiques. Le risque de perte de données est donc important. Merci d’être très rigoureux dans l’exécution du mode opératoire. Dans l’idéal, il est fortement conseillé de sauvegarder les données avant de réaliser la migration.

2.    MODE OPERATOIRE
2.1.    NOMENCLATURE
Dans le mode opératoire ci-dessous, nous admettrons que le disque cible correspond à « /dev/sdb » et la partition cible à « /dev/sdb1 ».

Bien évidemment, il faudra remplacer ces valeurs par celles correspondant à votre cas.

2.2.    HASH DES FICHIERS CLES
Sur le disque à migrer, localiser plusieurs fichiers clés, de préférence les gros et les plus importants.
Sur chaque fichier, réaliser un hash md5 et sauvegarder la valeur.

md5sum /path/to/file
8f714607b09b3bb0a324dda590f3f2b2 /path/to/file

2.3.    VERIFICATION ET DEMONTAGE DU DISQUE CIBLE
Assurez-vous qu’aucune ressource n’utilise le disque à migrer et démonter-le

umount /path/to/mountpoint

Le système de fichier doit être propre avant de débuter la migration.
Lancer la commande suivante afin de vérifier le système de fichier.

fsck.ext4 -fv /dev/sdb

2.4.    LIBERATION DES DERNIERS BLOCS

L’opération de migration nécessite de décaler les données du disque. Les derniers blocs du disque seront donc perdus. Afin qu’aucune donnée utile ne se trouve dans ces derniers blocs, nous allons forcer ext4 à ne plus les utiliser et copier les données ailleurs.

Pour cela commençons par extraire le nombre de blocs contenus sur le système de fichier du disque cible :

dumpe2fs /dev/sdb | grep "Block count"

Sauvegarder précieusement la valeur retournée.
Les blocs à condamner seront compris entre v-101 et v-1, où v est la valeur retournée par la commande précédentes (nous condamnons 100 blocs).

Par exemple, si la commande retourne 262144, les blocs à condamner seront les blocs compris entre 262043 et 262143.

Une fois les bornes déterminées, nous allons créer un fichier contenant la liste des blocs à condamner.
L’exemple ci-dessous vous présente les commandes à exécuter avec les valeurs d’exemple utilisées à l’instant.

cat /dev/null > /tmp/bad
for i in `seq 262043 262143` ; do echo $i >> /tmp/bad ; done 

Il ne reste plus qu’à informer ext4 des blocs à condamner.
La commande suivante permet de réaliser ceci. Il faut répondre « y » à toutes les questions.

e2fsck -L /tmp/bad /dev/sdb

La commande suivante permet de vérifier que nos blocs condamnés sont bien pris en compte :

dumpe2fs -b /dev/sdb

Puis ont vérifie l’intégrité du système de fichier :

e2fsck -f /dev/sdb

2.5.    DUMP DES PREMIERS SECTEURS

Lorsque nous allons installer notre table des partitions, celle-ci va écraser les premiers secteurs du disque. Il faut donc les sauvegarder. Nous allons sauvegarder les 100 premiers KB du disque dans le fichier /home/backup.bin

dd if=/dev/sdb of=/home/backup.bin bs=1024 count=100

2.6.    CREATION DE LA TABLE GTP ET DE LA PARTITION

Lancer « parted » sur le disque cible.
parted /dev/sdb

Afficher la taille du système de fichier actuel à l’aide de la commande « p ». Sauvegarder précieusement cette valeur que nous appellerons PTAILLE.

Maintenant, créons notre table GPT. Après l’exécution de la commande suivante, plus de retour en arrière possible.

mklabel gpt

Réponde Yes.

La création de la partition se fait ensuite via la commande « mkpart »

Partition name?  []?
File system type?  [ext2]? ext4
Start? 0
End? PTAILLE
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? Ignore

Remplacer PTAILLE par la valeur que vous avez sauvegardé avec l’unité (exemple : 1250MB)

Quitter « parted » via « quit »

2.7.    DECALAGE DES DONNEES

L’étape suivante consiste à décaler les données contenues sur le disque vers la partition.
Ceci est possible via la commande suivante :

dd if=/dev/sdb of=/dev/sdb1 bs=4096

Attention, cette commande peut mettre beaucoup de temps à s’exécuter selon la taille du disque cible.
En fin de traitement, vous obtiendrez une erreur de type « No space left on device ». C’est normal, l’opération a décalé les données sur le disque et les derniers blocs n’ont pu être recopiés et sont perdus. Heureusement, ils ne contiennent aucune donnée utile.

2.8.    RESTAURATION DE LA SAUVEGARDE
Nous allons désormais restaurer les 100 premiers KB du système de fichier que nous avons sauvegardé tout à l’heure.

dd if=/home/backup.bin of=/dev/sdb1 bs=1 conv=notrunc

Désormais, les données contenus dans le système de fichiers ont retrouvé leur intégrité.

2.9.    CORRECTION DU SYSTEME DE FICHIER

Le système de fichier a été décalé. Il faut donc corriger les incohérences générées par notre migration.
La première étape consiste à laisser ext4 se corriger de lui-même :

e2fsck -f /dev/sdb1
Abort<y>? no
Fix<y>? yes
Fix<y>? yes
[...]

Répondre « no » pour « Abort », mais « yes » aux autres questions posées.

La seconde étape consiste à effectuer une vérification des blocs défectueux et ainsi remettre d’équerre la liste que nous avons altérée :

e2fsck -c /dev/sdb1
Abort<y>? no

Répondre « no » pour « Abort », mais « yes » aux autres questions posées.


Enfin, nous allons corriger la taille de la partition :

resize2fs /dev/sdb1

C’est fini !

2.10.    VALIDATION
Afin de valider que tout s’est bien passé, monter la toute nouvelle partition /dev/sdb1 et réaliser un hash md5 de vos fichiers clés. Les hashs doivent correspondre avec les valeurs obtenues en début d’opération.

Il est également préconisé de faire une vérification du système de fichier :

fsck.ext4 -fv /dev/sdb1


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#7 Le 13/03/2014, à 23:48

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Cette procédure est incorrecte. Même si elle peut fonctionner dans certaines situation, c'est une loterie !

obibann a écrit :

Ce document décrit le mode opératoire permettant de passer d’un disque formaté à un disque partitionné sans perte de données.

Sans perte de données ? C'est présomptueux dans la mesure la verification prévue dans cette procédure ne porte que sur un échantillon :

Si on prend pour exemple une partition créee au secteur 34 (premier secteur dispo après la table de partition GPT sur un disque avec des secteurs logique de 512 Octets ) :

Il est clair que dans le principe, dd va commencer par lire le secteur 0 puis le réécrire au secteur 34. Si bien qu'une fois arrivé au secteur 34 les données qui s'y trouvaient ont été écrasées avant d'avoir été lu.

Manque de pot, rien d'aussi grossier n'arrive. Car linux, en fonction des ressources disponibles, va précharger une partie des données dans des buffers. Et le résultat peut être correcte ou avec très peu d'erreurs, s'il y a beaucoup de ressources disponibles et notamment de la mémoire.

En fait, un problème peut survenir lorsque tout le contenu du buffer en cours a été consommé,
Là, deux cas de figure peuvent se présenter:
1 - Linux n'a pas eu le temps et/ou pas la place mémoire suffisante pour anticiper le chargement d'un autre buffer, et les données suivantes qui vont être lues auront été écrasées avant.
2 - Un nouveau buffer a été chargé suffisamment tôt, tout se passe bien


On peut vérifier la réalité du problème avec le script ci dessous qui décale une partition de 3Go avec des résultats variables :

sudo -s
dev=disk/by-id/ata-IBM-DTLA-307015_YF0YFT0K153
sudo parted /dev/$dev print
sudo umount /mnt
losetup -d /dev/loop0
umount /tmp/tmpfs
rm -r /tmp/tmpfs

# création fs de 3 go
mke2fs -F -t ext4 -m 0 /dev/$dev $((3*1024*1024))

# remplissage fs
mount -L ubuntu904 /mnt2
mount /dev/$dev /mnt
cp -r /mnt2/* /mnt
df -H /mnt

# collecte hash md5 de tous les fichiers de la partition dans part1.md5
rm part1.md5
find /mnt -type f -exec md5sum "{}" >> part1.md5 \;
umount /mnt

# creation periphérique derrière la future table de partition
losetup /dev/loop0 -o 17K --sizelimit 3G /dev/$dev

# remplie la mémoire
# mkdir /tmp/tmpfs
# mount -t tmpfs -o size=1537M tmpfs /tmp/tmpfs
# dd if=/dev/zero of=/tmp/tmpfs/zero bs=4k

# déplacement du système de fichier
dd if=/dev/$dev of=/dev/loop0 bs=4K

umount /tmp/tmpfs
rm -r /tmp/tmpfs

# création table gpt et partition à l'emplacement du système de fichier
parted -s /dev/$dev mklabel gpt
parted -s  /dev/$dev  mkpart ext4 $((17*1024))b $(((3*1024*1024+17)*1024))b

# contrôle fs 
e2fsck -fy /dev/${dev}-part1>part1.fsck
tail part1.fsck

# contrôle fichier versus hash md5 
mount /dev/${dev}-part1 /mnt 
md5sum -c  --quiet part1.md5 &>part1.md5log
tail part1.md5log

1er run juste après démarrage du pc 0 erreurs

2ème run en faisant en parallèle (dans une autre session) de la commande dd
un fs en mémoire (voir section en commentaire dans le script) et en le lisant
pour éviter qu'il soit totalement éjecté dans le swap, avec :

dd of=/dev/null if=/tmp/tmpfs/zero bs=4k

(il y a 2 Go de mémoire sur le pc utilisé, et j'ai donc en théorie laissé 512 Mo libre, mais en pratique une partie c'est tout de même retrouvé dans le swap qui est passé de 0 à pratiquement 2 go)

résultat :

root@Miragek1204:~# md5sum -c  --quiet part1.md5>part1.md5log
md5sum: AVERTISSEMENT : les sommes de contrôle 26 ne concordent pas
root@Miragek1204:~# head part1.md5log
/mnt/usr/share/fonts/truetype/thai/TlwgTypo-Bold.ttf: ÉCHEC
/mnt/usr/share/fonts/truetype/thai/Kinnari-BoldItalic.ttf: ÉCHEC
/mnt/usr/share/fonts/truetype/thai/TlwgMono.ttf: ÉCHEC
/mnt/usr/share/fonts/truetype/thai/TlwgTypewriter-Oblique.ttf: ÉCHEC
/mnt/etc/acpi/events/asus-eee-volume-down: ÉCHEC
/mnt/etc/acpi/events/asus-media-next: ÉCHEC
/mnt/etc/acpi/events/asus-volume-down: ÉCHEC
/mnt/etc/acpi/events/asus-video: ÉCHEC
/mnt/etc/acpi/events/tosh-mail: ÉCHEC
/mnt/etc/cups/printers.conf: ÉCHEC
root@Miragek1204:~# 

3 ème run, idem, mais en activant les 3 lignes commentées dans le script, pour que le fichier mémoire soit créé avant le début de la copie.
et en faisant tourner 2 fois la lecture du tmpfs dans une autre session en parallèle.

Résultat 12000 ligne de log d'erreur dans le contrôle du fs résultant; et plus de 6000 fichier perdus...

md5sum: AVERTISSEMENT : les fichiers listés 6137 n'ont pas pu être lus
root@Miragek1204:~# 

4ème 5ème run exécuté à nouveau, mais sans tmpfs comme dans le 1er run :
à chaque fois une vingtaine de fichiers présentent une erreur de checksum

au reste, la méthode utilisée pour réduire la partition avec les badbloc + troncage de la partition lors de la copie + fsck après troncage, au lieu d'utiliser resize2fs avant le déplacement est amusante, mais aucunement justifiée...

Dernière modification par jamesbad000 (Le 16/03/2014, à 21:42)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#8 Le 14/03/2014, à 15:16

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

au reste, la méthode utilisée pour réduire la partition avec les badbloc + troncage de la partition lors de la copie + fsck après troncage, au lieu d'utiliser resize2fs avant le déplacement est amusante, mais aucunement justifiée...

J'avais essayé de redimensionner le système de fichier, mais ça n’avait pas fonctionné. j'en avais déduis que c'était parce que je n'utilisais pas encore de partition, d'où "l'astuce" des badblocks.

Sinon en toute logique, les conversions seront effectuées sur des serveurs disposant d'au moins 32Go de RAM. Les différents run que j'ai effectués ont toujours été OK. J'ai effectué un test sur un disque de 4To avec succès.

Je comprends bien le problème de lecture que tu détailles, j'ai moi-même était agréablement surpris que le décalage des données ait fonctionné. J'en ai conclu que dd était capable de "gérer ce genre de traitements". Ceci s'explique donc par les buffers que maintiens l'OS. Afin de multiplier les chances de succès, je peux ajouter un contrôle sur la mémoire libre.

De toute façon, même si on ne peut pas tout sauvegarder, les données les plus importantes le seront.

Sans perte de données ? C'est présomptueux dans la mesure la vérification prévue dans cette procédure ne porte que sur un échantillon :

Je n'ai pas copié toute la procédure. La première page contient un warning de 10 lignes, en gras rouge, signalant le risque TRES élevée de perdre ses données, qu'il faut tout sauvegarder avant, etc ...


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#9 Le 16/03/2014, à 21:32

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

J'avais essayé de redimensionner le système de fichier, mais ça n’avait pas fonctionné. j'en avais déduis que c'était parce que je n'utilisais pas encore de partition

resize2fs ne distingue pas une partition d'un disque. SI dessous j'enlève 1 Mo à mon fs de 3 Go qui est sur sdb

root@Miragek1204:~# resize2fs  /dev/sdb $((3*1024-1))M
resize2fs 1.42 (29-Nov-2011)
En train de redimensionner le système de fichiers sur /dev/sdb à 786176 (4k) blocs.
Le système de fichiers /dev/sdb a maintenant une taille de 786176 blocs.

Afin de multiplier les chances de succès, je peux ajouter un contrôle sur la mémoire libre.

Tu ferais mieux d'effectuer un contrôle sur la totalité de tes fichiers en appliquant la même méthode qui dans le script que j'ai donné dans mon post précédent.
De toute façon pour décaler de 34k, en principe il suffirait d'avoir 34k toujours chargés d'avance. Donc avec 2Go et rien d'autre qui tourne, je ne devrais avoir aucun problème. Et pourtant...


2.9.    CORRECTION DU SYSTEME DE FICHIER

Le système de fichier a été décalé. Il faut donc corriger les incohérences générées par notre migration.
La première étape consiste à laisser ext4 se corriger de lui-même :

En fait le fs n'est absolument pas décalé, parce que une fois dans la partition, il se trouve positionné au secteur 0 du périphérique de bloc correspondant à la partition (sbd1). Comme il était au secteur 0 du périphérique de bloc correspondant au disque (sdb).

La seule réparation qui devrait intervenir a pour cause la troncature du système de fichier en lien avec la méthode des badbloc, et se manifeste par un message très simple.

Ci-dessous je construis un périphérique de bloc sur l'emplacement du système de fichier utilisé précédemment, avec encore un mégaoctet de moins.

root@Miragek1204:~# losetup /dev/loop0  --sizelimit $((3*1024-2))M /dev/sdb
root@Miragek1204:~# sudo e2fsck /dev/loop0
e2fsck 1.42 (29-Nov-2011)
La taille du système de fichiers (selon le superbloc) est de 786176 blocs
La taille physique du périphérique est de 785920 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
Arrêter<o>? non

/dev/loop0 contient un système de fichiers comportant des erreurs, vérification forcée.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/loop0 : 11/196608 fichiers (0.0% non contigüs), 29884/786176 blocs

Tout autre réparation, alors que le fs était intègre avant la copie, est le symptôme que des données ont été écrasées dans les blocs de contrôle du système de fichiers, parce qu'elles n'ont pas été chargées suffisamment tôt dans des buffers.
(et donc il y a suspicion de perte de fichier, et également que les blocs de contrôle ne soient pas les seules parties endommagées, mais aussi les données)

Enfin, si au loto 100% des gagnants ont tentés leurs chance. Il ne faut pas perdre de vu que 100% des perdants aussi...

Dernière modification par jamesbad000 (Le 16/03/2014, à 21:38)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#10 Le 17/03/2014, à 09:59

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Merci pour ton aide et tes conseils.

Afin de fiabiliser le déplacement du filesystem, que penses-tu de l'idée suivante :

1) Lecture de 1MB de /deb/sdb vers un fichier dans un emplacement de sauvegarde (/home/toto/onemeg.bin par exemple)
2) Lecture du 1MB suivant sur /deb/sdb vers home/toto/secondmeg.bin
3) Écriture de /home/toto/onemeg.bin sur /dev/sdb1 à partir de l'octet 0 de /dev/sdb1
4) Lecture du 3ème 1MB de /deb/sdb vers /home/toto/onemeg.bin
5) Écriture de /home/toto/secondmeg.bin sur /dev/sdb1 à partir de 1MB+1o de /dev/sdb1
6) Lecture du 4ème 1MB de /deb/sdb vers /home/toto/secondmeg.bin

Et ainsi de suite ... L'idée étant d'avoir toujours des données lues d'avance sur les données écrites.

Bon j'utilise arbitrairement des morceaux de 1MB, il y a peut-être plus optimum.

Sinon, en ce qui concerne resize2fs, peux-tu me confirmer que les données du FS contenues à la fin seront bien physiquement déplacées en cas de redimensionnement, et que ce n'est pas uniquement l'information sur la taille du FS qui est altérée ?

Merci

Dernière modification par obibann (Le 17/03/2014, à 10:00)


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#11 Le 17/03/2014, à 10:28

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Voici la fonction à laquelle je pense (à optimiser sans doute) :

BITSTREAM=4096
NBBLOCS=5000
BUFFER_PATH=/tmp/tmpfs
BUFFER_SIZE=$(( $NBBLOCS * $BITSTREAM * 3 ))

# Move Data procedure
# $1: source
# $2: target
move_data()
{
  read=0
  offset_source=0
  offset_target=0
  data1=$BUFFER_PATH/data1.bin
  data2=$BUFFER_PATH/data2.bin
  data=$data1
  type_write=0
  tstart=`date +%s`
  
  # Mounting buffer
  mkdir -p $BUFFER_PATH >> $LOG 2>&1
  mount -t tmpfs -o size=$BUFFER_SIZE tmpfs $BUFFER_PATH >> $LOG 2>&1
  
  # Moving data
  while [ $read -eq 0 ]
  do
    # Source to file 1
    if [ $type_write -eq 1 ] || [ $offset_source -eq 0 ] ; then
      echo "Copying $1 to $data1 : bs=${BITSTREAM} skip=${offset_source} count=${NBBLOCS}" >> $LOG
      dd if=${1} of=${data1} bs=${BITSTREAM} skip=${offset_source} count=${NBBLOCS} 1>/dev/null 2>>$LOG
      read=$?
      offset_source=$(( $offset_source + $NBBLOCS ))
    fi
    
    # Source to file 2
    if [ $type_write -eq 0 ] ; then
      echo "Copying $1 to $data2 : bs=${BITSTREAM} skip=${offset_source} count=${NBBLOCS}" >> $LOG
      dd if=${1} of=${data2} bs=${BITSTREAM} skip=${offset_source} count=${NBBLOCS} 1>/dev/null 2>>$LOG
      read=$?
      offset_source=$(( $offset_source + $NBBLOCS ))
    fi
    
    # file to target
    data=$data1
    [ $type_write -eq 1 ] && data=$data2
    if [ -s $data ] ; then
      echo "Copying $data to $2 : bs=${BITSTREAM} seek=${offset_target}" >> $LOG
      dd if=${data} of=${2} bs=${BITSTREAM} seek=${offset_target} conv=notrunc 1>/dev/null 2>>$LOG
      # Preparing next write
      offset_target=$(( $offset_target + $NBBLOCS ))
    fi
    
    # Next write
    if [ $type_write -eq 0 ] ; then type_write=1
    else type_write=0 ; fi
  done
  tend=`date +%s`
  duration=$(($tend-$tstart))
  echo "Data moving done in $duration seconds" >> $LOG
  
  # Cleaning buffer
  umount $BUFFER_PATH >> $LOG 2>&1
  rm -rf $BUFFER_PATH >> $LOG 2>&1
}

Dernière modification par obibann (Le 17/03/2014, à 16:32)


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#12 Le 17/03/2014, à 14:46

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Sinon, en ce qui concerne resize2fs, peux-tu me confirmer que les données du FS contenues à la fin seront bien physiquement déplacées en cas de redimensionnement, et que ce n'est pas uniquement l'information sur la taille du FS qui est altérée ?

Oui je confirme.

Sinon, la procédure de copie me semble correcte dans le principe (alterner 2 buffers rechargés aussitôt qu'ils sont vide, et d'une dimension au moins égale à la longueur du déplacement)

Mais par bloc de 1Mo ça risque d'être horriblement long. Je conseillerais plutôt de faire par bloc d'au moins 100 Mo (en jouant sur le count, pas sur le bs), voir même  1 Go si tu as un espace de travail suffisant sur le disque intermédiaire.

Possible aussi de copier tes tampons dans un tmpfs qui sera en mémoire et donc plus rapide  (voir exemple dans mon script plus haut), mais en cas de plantage du pc ou coupure de courant il n'y aura pas de reprise possible.
(Ceci dit, même si les tampons sont sur disque, pour qu'il y ait reprise possible, il faudrait penser à sauvegarder le dernier n° de bloc copié, ce qui ne couterait pas bien cher en perf si les blocs sont très gros)

Dernier truc, tant qu'à faire, tu devrais aligner ta partition sur le 1er Mo (voir man parted pour l'option d'alignement). Pour éviter un risque de dégradation des performances. Evidemment penser à réduire la taille du fs en conséquence  (2 Mo pour faire simple et tenir compte du backup de la table de partition GPT à la fin du disque)

Dernière modification par jamesbad000 (Le 17/03/2014, à 14:47)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#13 Le 17/03/2014, à 16:07

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Merci pour ta réponse.

J'ai mis à jour mon code à jour afin de prendre en compte tes remarques (post #11).

Edit : J'avais renseigné un problème que je rencontrais, mais en fait je me prenais la tête pour rien.
Je passe maintenant sur le décalage à 1MB et le resize2fs à la place des badblocks.

Dernière modification par obibann (Le 17/03/2014, à 16:33)


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#14 Le 17/03/2014, à 17:46

obibann

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Et bien c'est un succès !

L'utilisation de resize2fs fonctionne comme tu me l'as confirmé. Le déplacement via le double buffer est rapide et mes fichiers sont OK.

En ce qui concerne parted, il suffit de créer la partition en lui donnant des bornes en pourcentage pour qu'il s'ajuste automatiquement smile

parted mkpart "toto" ext4 0% 100%

Merci beaucoup pour ton aide !

Dernière modification par obibann (Le 17/03/2014, à 17:47)


Ubuntu 16.04
Avec Windows, on fait ce qu'on peut... Avec Linux, on fait ce qu'on veut !! :p

Hors ligne

#15 Le 17/03/2014, à 19:11

jamesbad000

Re : [Résolu] Déplacer des données sur le disque, octets par octets

Bien joué !


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne