Après redémarrage, un de mes disques n'est plus monté automatiquement
(ce qui fait plus ou moins échouer le démarrage en demandant une
intervention manuelle). Le disque ne contient pas le système et je l'ai
supprimé de fstab, le reste fonctionne sans lui.
Après inspection le disque n'apparaît plus sous son uuid
dans /dev/disk/by-uuid/. Il semble qu'il y en ait un autre qui
corresponde mais avec un uuid différent.
J'arrive à monter le disque manuellement avec
mount /dev/sdd1 /mnt/truc -t ext4
Si je ne précise pas le type du système de fichiers j'ai ce message
d'erreur :
mount: /dev/sdd1 : plus de systèmes de fichiers ont été trouvés.
Ce n'est pas censé arriver, utilisez -t <type> pour
indiquer explicitement le type de système de fichiers
ou utilisez wipefs(8) pour nettoyer le périphérique.
J'ai deux disques de données très similaires, pour le premier blkid
donne ça :
/dev/sdc1: UUID="d401716c-deb2-4ba4-9c76-2944d1e78d4b" TYPE="ext4"
PARTUUID="2544c6b2-7dd9-4abc-9960-039fcf6d7252"
Et pour le second, celui qui ne marche pas, blkid n'affiche rien du
tout (retour à l'invite de commande, rien d'affiché ; j'ai bien tapé le
bon chemin).
On dirait que certaines méta-données du disque ont été perdues. fsck ne
pense pas que quelque chose va mal sur ce disque, mais je pense que le
problème se situe avant la lecture du système de fichiers de toutes
façons (?). Peut-être que ça marcherait en modifiant l'uuid du disque
dans fstab et en précisant au passage le système de fichiers, mais ça
m'intrigue : une idée de ce qui a pu se passer ? Est-ce qu'il y a un
moyen de régénérer ces infos ? D'autres remarques/idées ?
Le Thu, 26 Nov 2015 09:01:26 +0100 Pascal Hambourg a écrit :
Yliur a écrit : > Pascal Hambourg a écrit : > >> Si tu as le temps, l'écriture d'un fichier de zéros sur tout >> l'espace libre ne présente pas de risque particulier : >> >> dd bs=4k if=/dev/zero of=/point/de/montage/effacetout > > Sans doute mais il faudrait que je sois sûr de ce qui est libre (en > lisant la table des partitions sans doute).
Qu'est-ce que la table de partition vient faire là-dedans ? Tu veux parler de la table d'allocation des blocs du système de fichiers ? Il s'agit juste de créer un fichier de zéros qui va remplir tout l'espace libre du système de fichiers monté. Le système de fichiers sait très bien lesquels de ses blocs sont libres, sinon on se demande à quoi il sert.
Ok, j'ai pensé que les infos à effacer se trouvaient en dehors. Mais non bien sûr, puisqu'elles sont bien visibles par wipefs sur /dev/sdd1.
> Parce que cette commande telle quelle ne va pas permettre de faire > un effacement ciblé,
Non, elle a pour but d'effacer systématiquement tout bloc non alloué du système de fichiers, en prenant le temps qu'il faut.
Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux l'idée (et ce que tu avais écrit). Par contre je pensais que ces données parasites ne se trouvaient pas dans les données allouables au contenu des fichiers mais dans une zone qui ne pouvait pas être altérée par ce contenu. Tu supposes que ce n'est pas le cas parce qu'il ne s'agit pas de méta-données du système de fichiers ext4 ?
> il faudrait trouver le premier octet concernée et le > lui indiquer.
Idéalement, oui, cela ferait gagner du temps d'écriture. Mais si c'est pour en perdre autant à la lecture et détection, ça ne vaut pas le coup.
Jusqu'à ce que la commande s'arrête et que la partition soit effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché : " # wipefs /dev/sdd1 offset type ---------------------------------------------------------------- 0x7470abb000 zfs_member [raid] LABEL: ddzfs UUID: 15481972323858100681
J'essaierai une solution plus radicale une autre fois sans doute.
Le Thu, 26 Nov 2015 09:01:26 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Yliur a écrit :
> Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
>
>> Si tu as le temps, l'écriture d'un fichier de zéros sur tout
>> l'espace libre ne présente pas de risque particulier :
>>
>> dd bs=4k if=/dev/zero of=/point/de/montage/effacetout
>
> Sans doute mais il faudrait que je sois sûr de ce qui est libre (en
> lisant la table des partitions sans doute).
Qu'est-ce que la table de partition vient faire là-dedans ? Tu veux
parler de la table d'allocation des blocs du système de fichiers ? Il
s'agit juste de créer un fichier de zéros qui va remplir tout l'espace
libre du système de fichiers monté. Le système de fichiers sait très
bien lesquels de ses blocs sont libres, sinon on se demande à quoi il
sert.
Ok, j'ai pensé que les infos à effacer se trouvaient en dehors. Mais
non bien sûr, puisqu'elles sont bien visibles par wipefs sur /dev/sdd1.
> Parce que cette commande telle quelle ne va pas permettre de faire
> un effacement ciblé,
Non, elle a pour but d'effacer systématiquement tout bloc non alloué
du système de fichiers, en prenant le temps qu'il faut.
Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque
pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux
l'idée (et ce que tu avais écrit). Par contre je pensais que ces données
parasites ne se trouvaient pas dans les données allouables au contenu
des fichiers mais dans une zone qui ne pouvait pas être altérée par ce
contenu. Tu supposes que ce n'est pas le cas parce qu'il ne s'agit pas
de méta-données du système de fichiers ext4 ?
> il faudrait trouver le premier octet concernée et le
> lui indiquer.
Idéalement, oui, cela ferait gagner du temps d'écriture. Mais si c'est
pour en perdre autant à la lecture et détection, ça ne vaut pas le
coup.
Jusqu'à ce que la commande s'arrête et que la partition soit
effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché :
"
# wipefs /dev/sdd1
offset type
----------------------------------------------------------------
0x7470abb000 zfs_member [raid]
LABEL: ddzfs
UUID: 15481972323858100681
Le Thu, 26 Nov 2015 09:01:26 +0100 Pascal Hambourg a écrit :
Yliur a écrit : > Pascal Hambourg a écrit : > >> Si tu as le temps, l'écriture d'un fichier de zéros sur tout >> l'espace libre ne présente pas de risque particulier : >> >> dd bs=4k if=/dev/zero of=/point/de/montage/effacetout > > Sans doute mais il faudrait que je sois sûr de ce qui est libre (en > lisant la table des partitions sans doute).
Qu'est-ce que la table de partition vient faire là-dedans ? Tu veux parler de la table d'allocation des blocs du système de fichiers ? Il s'agit juste de créer un fichier de zéros qui va remplir tout l'espace libre du système de fichiers monté. Le système de fichiers sait très bien lesquels de ses blocs sont libres, sinon on se demande à quoi il sert.
Ok, j'ai pensé que les infos à effacer se trouvaient en dehors. Mais non bien sûr, puisqu'elles sont bien visibles par wipefs sur /dev/sdd1.
> Parce que cette commande telle quelle ne va pas permettre de faire > un effacement ciblé,
Non, elle a pour but d'effacer systématiquement tout bloc non alloué du système de fichiers, en prenant le temps qu'il faut.
Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux l'idée (et ce que tu avais écrit). Par contre je pensais que ces données parasites ne se trouvaient pas dans les données allouables au contenu des fichiers mais dans une zone qui ne pouvait pas être altérée par ce contenu. Tu supposes que ce n'est pas le cas parce qu'il ne s'agit pas de méta-données du système de fichiers ext4 ?
> il faudrait trouver le premier octet concernée et le > lui indiquer.
Idéalement, oui, cela ferait gagner du temps d'écriture. Mais si c'est pour en perdre autant à la lecture et détection, ça ne vaut pas le coup.
Jusqu'à ce que la commande s'arrête et que la partition soit effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché : " # wipefs /dev/sdd1 offset type ---------------------------------------------------------------- 0x7470abb000 zfs_member [raid] LABEL: ddzfs UUID: 15481972323858100681
Jusqu'à ce que la commande s'arrête et que la partition soit effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché :
Avec les options par défaut, mke2fs réserve des blocs à root. Tu peux voir si c'est le cas comme ceci : sudo dumpe2fs -h /dev/sdd1 |grep Reserved
Auquel cas, il faudrait lancer cette commande dd en tant que root (si tu n'as pas encore supprimé ficrempl il suffit de créer un ficrempl2) pour effacer aussi ces blocs-là.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Jusqu'à ce que la commande s'arrête et que la partition soit
effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché :
Avec les options par défaut, mke2fs réserve des blocs à root. Tu peux voir
si c'est le cas comme ceci :
sudo dumpe2fs -h /dev/sdd1 |grep Reserved
Auquel cas, il faudrait lancer cette commande dd en tant que root (si tu
n'as pas encore supprimé ficrempl il suffit de créer un ficrempl2) pour
effacer aussi ces blocs-là.
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Jusqu'à ce que la commande s'arrête et que la partition soit effectivement pleine, j'ai vérifié.
Mais ça n'a pas marché :
Avec les options par défaut, mke2fs réserve des blocs à root. Tu peux voir si c'est le cas comme ceci : sudo dumpe2fs -h /dev/sdd1 |grep Reserved
Auquel cas, il faudrait lancer cette commande dd en tant que root (si tu n'as pas encore supprimé ficrempl il suffit de créer un ficrempl2) pour effacer aussi ces blocs-là.
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Yliur
Le Fri, 27 Nov 2015 00:09:27 +0100 Pascal Hambourg a écrit :
Yliur a écrit : > Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque > pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux > l'idée (et ce que tu avais écrit). Par contre je pensais que ces > données parasites ne se trouvaient pas dans les données allouables > au contenu des fichiers mais dans une zone qui ne pouvait pas être > altérée par ce contenu. Tu supposes que ce n'est pas le cas parce > qu'il ne s'agit pas de méta-données du système de fichiers ext4 ?
Je l'espérais en me disant que si un bloc est alloué aux méta-données, il aurait déjà dû être réécrit avec les méta-données en question. A moins que le système de fichiers réserve de l'espace pour les méta-données.
En root, afin de ne pas laisser l'espace réservé ?
Aussi incroyable que ça puisse (me) paraître ça a fonctionné ! :)
wipefs ne parle plus de zfs et après redémarrage l'uuid du disque est réapparu dans /dev/disk/by-uuid/. blkid affiche à nouveau les méta-données de la partition (uuid et type du système de fichiers). J'ai remis mon montage par uuid dans fstab et tout est rentré dans l'ordre.
Merci à vous deux pour avoir trouvé la solution.
Par contre je ne comprends pas comment ça marche : si ces blocs étaient effectivement des blocs considérés comme vides, disponibles pour écrire du contenu de fichiers, pourquoi mount/blkid/wipefs allaient chercher à cet endroit des méta-données ? Je pensais qu'elles étaient dans un endroit particulier ou bien référencées par un genre d'index quelque part, ces commandes ne peuvent pas parcourir tout le disque en les recherchant j'imagine...
Le Fri, 27 Nov 2015 00:09:27 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
Yliur a écrit :
> Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque
> pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux
> l'idée (et ce que tu avais écrit). Par contre je pensais que ces
> données parasites ne se trouvaient pas dans les données allouables
> au contenu des fichiers mais dans une zone qui ne pouvait pas être
> altérée par ce contenu. Tu supposes que ce n'est pas le cas parce
> qu'il ne s'agit pas de méta-données du système de fichiers ext4 ?
Je l'espérais en me disant que si un bloc est alloué aux méta-données,
il aurait déjà dû être réécrit avec les méta-données en question. A
moins que le système de fichiers réserve de l'espace pour les
méta-données.
En root, afin de ne pas laisser l'espace réservé ?
Aussi incroyable que ça puisse (me) paraître ça a fonctionné ! :)
wipefs ne parle plus de zfs et après redémarrage l'uuid du disque est
réapparu dans /dev/disk/by-uuid/. blkid affiche à nouveau les
méta-données de la partition (uuid et type du système de fichiers).
J'ai remis mon montage par uuid dans fstab et tout est rentré dans
l'ordre.
Merci à vous deux pour avoir trouvé la solution.
Par contre je ne comprends pas comment ça marche : si ces blocs étaient
effectivement des blocs considérés comme vides, disponibles pour écrire
du contenu de fichiers, pourquoi mount/blkid/wipefs allaient chercher à
cet endroit des méta-données ? Je pensais qu'elles étaient dans un
endroit particulier ou bien référencées par un genre d'index quelque
part, ces commandes ne peuvent pas parcourir tout le disque en les
recherchant j'imagine...
Le Fri, 27 Nov 2015 00:09:27 +0100 Pascal Hambourg a écrit :
Yliur a écrit : > Ah, pardon. Il s'agit en fait d'écrire dans un fichier sur le disque > pour le remplir, pas dans /dev/sdd1 directement. Je comprends mieux > l'idée (et ce que tu avais écrit). Par contre je pensais que ces > données parasites ne se trouvaient pas dans les données allouables > au contenu des fichiers mais dans une zone qui ne pouvait pas être > altérée par ce contenu. Tu supposes que ce n'est pas le cas parce > qu'il ne s'agit pas de méta-données du système de fichiers ext4 ?
Je l'espérais en me disant que si un bloc est alloué aux méta-données, il aurait déjà dû être réécrit avec les méta-données en question. A moins que le système de fichiers réserve de l'espace pour les méta-données.
En root, afin de ne pas laisser l'espace réservé ?
Aussi incroyable que ça puisse (me) paraître ça a fonctionné ! :)
wipefs ne parle plus de zfs et après redémarrage l'uuid du disque est réapparu dans /dev/disk/by-uuid/. blkid affiche à nouveau les méta-données de la partition (uuid et type du système de fichiers). J'ai remis mon montage par uuid dans fstab et tout est rentré dans l'ordre.
Merci à vous deux pour avoir trouvé la solution.
Par contre je ne comprends pas comment ça marche : si ces blocs étaient effectivement des blocs considérés comme vides, disponibles pour écrire du contenu de fichiers, pourquoi mount/blkid/wipefs allaient chercher à cet endroit des méta-données ? Je pensais qu'elles étaient dans un endroit particulier ou bien référencées par un genre d'index quelque part, ces commandes ne peuvent pas parcourir tout le disque en les recherchant j'imagine...
Nicolas George
Pascal Hambourg , dans le message <n359oa$2faq$, a écrit :
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Pascal Hambourg , dans le message <n359oa$2faq$1@saria.nerim.net>, a
écrit :
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k
c'est trop petit pour avoir les meilleures performances (GNU cat semble
utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il
fait plus fin qu'une taille hardcodée).
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Pascal Hambourg
Nicolas George a écrit :
Pascal Hambourg , dans le message <n359oa$2faq$, a écrit :
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Nicolas George a écrit :
Pascal Hambourg , dans le message <n359oa$2faq$1@saria.nerim.net>, a
écrit :
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k
c'est trop petit pour avoir les meilleures performances (GNU cat semble
utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il
fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très
récents), je n'ai jamais observé de gain de performance significatif
avec des tailles de bloc de plus 4 Kio. Par contre la perte est
flagrante avec des tailles inférieures, surtout 512 octets. Comme
j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Benoit Izac
Bonjour,
Le 27/11/2015 à 20:21, Pascal Hambourg a écrit dans le message <n3aag4$up8$ :
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k
c'est trop petit pour avoir les meilleures performances (GNU cat semble
utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il
fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très
récents), je n'ai jamais observé de gain de performance significatif
avec des tailles de bloc de plus 4 Kio. Par contre la perte est
flagrante avec des tailles inférieures, surtout 512 octets. Comme
j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k
c'est trop petit pour avoir les meilleures performances (GNU cat semble
utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il
fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très
récents), je n'ai jamais observé de gain de performance significatif
avec des tailles de bloc de plus 4 Kio. Par contre la perte est
flagrante avec des tailles inférieures, surtout 512 octets. Comme
j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Il n'y a pas de raison particulière de fixer une taille de bloc ici, et 4k c'est trop petit pour avoir les meilleures performances (GNU cat semble utiliser 128k, j'ai la flemme d'aller voir le code source pour voir s'il fait plus fin qu'une taille hardcodée).
Par expérience (limitée aux disques durs classiques et pas très récents), je n'ai jamais observé de gain de performance significatif avec des tailles de bloc de plus 4 Kio. Par contre la perte est flagrante avec des tailles inférieures, surtout 512 octets. Comme j'ignorais quelle taille de bloc cat utilise, j'ai préféré assurer.
Le Fri, 27 Nov 2015 20:36:13 +0100 Pascal Hambourg a écrit :
> Par contre je ne comprends pas comment ça marche : si ces blocs > étaient effectivement des blocs considérés comme vides, disponibles > pour écrire du contenu de fichiers, pourquoi mount/blkid/wipefs > allaient chercher à cet endroit des méta-données ? Je pensais > qu'elles étaient dans un endroit particulier ou bien référencées > par un genre d'index quelque part, ces commandes ne peuvent pas > parcourir tout le disque en les recherchant j'imagine...
Non, en effet. Ce serait trop long et inutile de surcroît. Je suppose que libblkid recherche des signatures spécifiques aux positions particulières où elles sont susceptibles de se trouver pour identifier le type de méta-données. Or il n'y a pas de raison pour que la position d'une signature ZFS ait une signification particulière dans un système de fichiers ext4. Ces blocs étaient simplement considérés libres par le système de fichiers ext4 et n'avaient jamais été réécrits. Je ne sais pas si je me fais bien comprendre.
Oui, merci.
Par contre, pourquoi la position où la signature était détectée avançait après chaque tentative d'effacement, je voudrais bien le savoir.
Je ne sais pas ce que libblkid considère comme la signature de ZFS, mais ce dernier stocke peut-être à la fin du disque un certain nombre d'informations dans des zones marquées avec un genre d'identifiant (soit pour se différencier d'autres systèmes de fichiers qui écrivent leurs trucs ici aussi, soit parce qu'il s'en sert pour savoir ce qu'il a écrit dans chacune des zones).
Du coup wipefs aurait parcouru une partie du disque depuis la fin en cherchant ces traces et à chaque fois que j'en ai enlevé une il en a trouvé une autre un peu plus loin.
Le Fri, 27 Nov 2015 20:36:13 +0100
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a écrit :
> Par contre je ne comprends pas comment ça marche : si ces blocs
> étaient effectivement des blocs considérés comme vides, disponibles
> pour écrire du contenu de fichiers, pourquoi mount/blkid/wipefs
> allaient chercher à cet endroit des méta-données ? Je pensais
> qu'elles étaient dans un endroit particulier ou bien référencées
> par un genre d'index quelque part, ces commandes ne peuvent pas
> parcourir tout le disque en les recherchant j'imagine...
Non, en effet. Ce serait trop long et inutile de surcroît. Je suppose
que libblkid recherche des signatures spécifiques aux positions
particulières où elles sont susceptibles de se trouver pour identifier
le type de méta-données. Or il n'y a pas de raison pour que la
position d'une signature ZFS ait une signification particulière dans
un système de fichiers ext4. Ces blocs étaient simplement considérés
libres par le système de fichiers ext4 et n'avaient jamais été
réécrits. Je ne sais pas si je me fais bien comprendre.
Oui, merci.
Par contre, pourquoi la position où la signature était détectée
avançait après chaque tentative d'effacement, je voudrais bien le
savoir.
Je ne sais pas ce que libblkid considère comme la signature de ZFS,
mais ce dernier stocke peut-être à la fin du disque un certain nombre
d'informations dans des zones marquées avec un genre d'identifiant
(soit pour se différencier d'autres systèmes de fichiers qui écrivent
leurs trucs ici aussi, soit parce qu'il s'en sert pour savoir ce qu'il
a écrit dans chacune des zones).
Du coup wipefs aurait parcouru une partie du disque depuis la fin en
cherchant ces traces et à chaque fois que j'en ai enlevé une il en a
trouvé une autre un peu plus loin.
Le Fri, 27 Nov 2015 20:36:13 +0100 Pascal Hambourg a écrit :
> Par contre je ne comprends pas comment ça marche : si ces blocs > étaient effectivement des blocs considérés comme vides, disponibles > pour écrire du contenu de fichiers, pourquoi mount/blkid/wipefs > allaient chercher à cet endroit des méta-données ? Je pensais > qu'elles étaient dans un endroit particulier ou bien référencées > par un genre d'index quelque part, ces commandes ne peuvent pas > parcourir tout le disque en les recherchant j'imagine...
Non, en effet. Ce serait trop long et inutile de surcroît. Je suppose que libblkid recherche des signatures spécifiques aux positions particulières où elles sont susceptibles de se trouver pour identifier le type de méta-données. Or il n'y a pas de raison pour que la position d'une signature ZFS ait une signification particulière dans un système de fichiers ext4. Ces blocs étaient simplement considérés libres par le système de fichiers ext4 et n'avaient jamais été réécrits. Je ne sais pas si je me fais bien comprendre.
Oui, merci.
Par contre, pourquoi la position où la signature était détectée avançait après chaque tentative d'effacement, je voudrais bien le savoir.
Je ne sais pas ce que libblkid considère comme la signature de ZFS, mais ce dernier stocke peut-être à la fin du disque un certain nombre d'informations dans des zones marquées avec un genre d'identifiant (soit pour se différencier d'autres systèmes de fichiers qui écrivent leurs trucs ici aussi, soit parce qu'il s'en sert pour savoir ce qu'il a écrit dans chacune des zones).
Du coup wipefs aurait parcouru une partie du disque depuis la fin en cherchant ces traces et à chaque fois que j'en ai enlevé une il en a trouvé une autre un peu plus loin.
