J'aimerais bien avoir une petite explication sur ce point
si c'est possible bien sûr. Je ne vois absolument pas comment
c'est possible sur un disque d'avoir une taille de secteur
logique (on dit un "bloc" je crois ?)
strictement plus petite
que la taille d'un secteur physique. Je pensais qu'un « secteur
logique » était un regroupement de secteurs physiques contigus ?
J'aimerais bien avoir une petite explication sur ce point
si c'est possible bien sûr. Je ne vois absolument pas comment
c'est possible sur un disque d'avoir une taille de secteur
logique (on dit un "bloc" je crois ?)
strictement plus petite
que la taille d'un secteur physique. Je pensais qu'un « secteur
logique » était un regroupement de secteurs physiques contigus ?
J'aimerais bien avoir une petite explication sur ce point
si c'est possible bien sûr. Je ne vois absolument pas comment
c'est possible sur un disque d'avoir une taille de secteur
logique (on dit un "bloc" je crois ?)
strictement plus petite
que la taille d'un secteur physique. Je pensais qu'un « secteur
logique » était un regroupement de secteurs physiques contigus ?
Non, cette histoire de « bloc », c'est pour la gestion de l'espace par
certains systèmes de fichiers.
Les secteurs physiques, c'est ce qui est présent réellement à la surface
du disque, avec les informations de synchronisation et de correction.
Les secteurs logiques, c'est ce à quoi donne accès le contrôleur disque
en réponse aux commandes ATA.
Si les secteurs logiques sont plus petits que les secteurs physiques,
une opération de lecture lira les secteurs physiques qui contiennent les
secteurs logiques demandés (donc plus que demandé) et renverra le
contenu voulu.
Plus grave, une opération d'écriture peut modifier des secteurs
physiques partiellement. Le contrôleur devra alors lire les secteurs
physiques modifiés en mémoire tampon, insérer le nouveau contenu et
ensuite écrire sur le disque : beaucoup plus lent.
Non, cette histoire de « bloc », c'est pour la gestion de l'espace par
certains systèmes de fichiers.
Les secteurs physiques, c'est ce qui est présent réellement à la surface
du disque, avec les informations de synchronisation et de correction.
Les secteurs logiques, c'est ce à quoi donne accès le contrôleur disque
en réponse aux commandes ATA.
Si les secteurs logiques sont plus petits que les secteurs physiques,
une opération de lecture lira les secteurs physiques qui contiennent les
secteurs logiques demandés (donc plus que demandé) et renverra le
contenu voulu.
Plus grave, une opération d'écriture peut modifier des secteurs
physiques partiellement. Le contrôleur devra alors lire les secteurs
physiques modifiés en mémoire tampon, insérer le nouveau contenu et
ensuite écrire sur le disque : beaucoup plus lent.
Non, cette histoire de « bloc », c'est pour la gestion de l'espace par
certains systèmes de fichiers.
Les secteurs physiques, c'est ce qui est présent réellement à la surface
du disque, avec les informations de synchronisation et de correction.
Les secteurs logiques, c'est ce à quoi donne accès le contrôleur disque
en réponse aux commandes ATA.
Si les secteurs logiques sont plus petits que les secteurs physiques,
une opération de lecture lira les secteurs physiques qui contiennent les
secteurs logiques demandés (donc plus que demandé) et renverra le
contenu voulu.
Plus grave, une opération d'écriture peut modifier des secteurs
physiques partiellement. Le contrôleur devra alors lire les secteurs
physiques modifiés en mémoire tampon, insérer le nouveau contenu et
ensuite écrire sur le disque : beaucoup plus lent.
Ok donc le secteur logique est une propriété qui concerne le
contrôleur disque qui relie la carte mère au disque lui-même.
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Ok donc le secteur logique est une propriété qui concerne le
contrôleur disque qui relie la carte mère au disque lui-même.
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Ok donc le secteur logique est une propriété qui concerne le
contrôleur disque qui relie la carte mère au disque lui-même.
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Enfin, même si grâce à toi je comprends qu'il est possible
d'avoir un secteur logique < secteur physique, est-ce qu'on
est d'accord pour dire qu'en pratique c'est complètement
déconnant et que c'est à éviter en toutes circonstances ?
Puis-je considérer la commande suivante comme un bon moyen de
connaître la taille d'un secteur physique et logique pour un
disque donnée (c'est la commande fdisk d'un Debian Stretch) ?
~$ sudo fdisk -l /dev/sdc | grep Sector
Sector size (logical/physical): 512 bytes / 512 bytes
Puis-je considérer la commande suivante comme un bon moyen de
connaître la taille d'un secteur physique et logique pour un
disque donnée (c'est la commande fdisk d'un Debian Stretch) ?
~$ sudo fdisk -l /dev/sdc | grep Sector
Sector size (logical/physical): 512 bytes / 512 bytes
Puis-je considérer la commande suivante comme un bon moyen de
connaître la taille d'un secteur physique et logique pour un
disque donnée (c'est la commande fdisk d'un Debian Stretch) ?
~$ sudo fdisk -l /dev/sdc | grep Sector
Sector size (logical/physical): 512 bytes / 512 bytes
Le 10/09/2017 à 16:35, jp willm a écrit :Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Il ne faut pas exagérer le risque avec les partitions logiques. J'ai
noirci le tableau à dessein, mais si on ne modifie pas les partitions
tous les quatre matins il n'y a pas de risque.
mon temps à créer, supprimer ou redimensionner des partitions sur un
disque qui en contient déjà une vingtaine, donc la plus grande
robustesse de GPT et la stabilité de la numérotation des partitions est
appréciable.
Convertir un disque du format DOS/MBR vers GPT en préservant les
partitions existantes n'est pas difficile avec gdisk à condition qu'il y
ait assez d'espace non alloué au début et à la fin du disque (une
trentaine de secteurs) pour loger les deux tables de partition
principale et de secours.
Par contre, il faut généralement réinstaller le chargeur d'amorçage dans
le MBR.
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par la
table de partition principale GPT.
suffisent,
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Le 10/09/2017 à 16:35, jp willm a écrit :
Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Il ne faut pas exagérer le risque avec les partitions logiques. J'ai
noirci le tableau à dessein, mais si on ne modifie pas les partitions
tous les quatre matins il n'y a pas de risque.
mon temps à créer, supprimer ou redimensionner des partitions sur un
disque qui en contient déjà une vingtaine, donc la plus grande
robustesse de GPT et la stabilité de la numérotation des partitions est
appréciable.
Convertir un disque du format DOS/MBR vers GPT en préservant les
partitions existantes n'est pas difficile avec gdisk à condition qu'il y
ait assez d'espace non alloué au début et à la fin du disque (une
trentaine de secteurs) pour loger les deux tables de partition
principale et de secours.
Par contre, il faut généralement réinstaller le chargeur d'amorçage dans
le MBR.
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par la
table de partition principale GPT.
suffisent,
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Le 10/09/2017 à 16:35, jp willm a écrit :Bon, je laisse tomber, ce qui serait prioritaire, c'est d'avoir de mes
tables de partitions en gpt.
Il ne faut pas exagérer le risque avec les partitions logiques. J'ai
noirci le tableau à dessein, mais si on ne modifie pas les partitions
tous les quatre matins il n'y a pas de risque.
mon temps à créer, supprimer ou redimensionner des partitions sur un
disque qui en contient déjà une vingtaine, donc la plus grande
robustesse de GPT et la stabilité de la numérotation des partitions est
appréciable.
Convertir un disque du format DOS/MBR vers GPT en préservant les
partitions existantes n'est pas difficile avec gdisk à condition qu'il y
ait assez d'espace non alloué au début et à la fin du disque (une
trentaine de secteurs) pour loger les deux tables de partition
principale et de secours.
Par contre, il faut généralement réinstaller le chargeur d'amorçage dans
le MBR.
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par la
table de partition principale GPT.
suffisent,
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Non, se méfier du grep... Si t'as une version différente de fdisk[*],
[...]
Disk /dev/sda: 2000 GB, 2000396321280 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
[...]
Non, se méfier du grep... Si t'as une version différente de fdisk[*],
[...]
Disk /dev/sda: 2000 GB, 2000396321280 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
[...]
Non, se méfier du grep... Si t'as une version différente de fdisk[*],
[...]
Disk /dev/sda: 2000 GB, 2000396321280 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
[...]
Le 10/09/2017 à 23:27, Pascal Hambourg a écrit :
Pour GRUB, il est aussi préférable de créer une petite partitionde type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par
la table de partition principale GPT.
J'ai cru comprendre qu'il n'est pas besoin de la formater.
Pas besoin de beaucoup : 60 kosuffisent,
Certains disent 1 Mo mais je serai radin :o)
et la conversion en GPT laisse des "trous" avant la premièrepartition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Reste à voir si cet espace est important, et si on peut le récupérer...
Le 10/09/2017 à 23:27, Pascal Hambourg a écrit :
Pour GRUB, il est aussi préférable de créer une petite partition
de type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par
la table de partition principale GPT.
J'ai cru comprendre qu'il n'est pas besoin de la formater.
Pas besoin de beaucoup : 60 ko
suffisent,
Certains disent 1 Mo mais je serai radin :o)
et la conversion en GPT laisse des "trous" avant la première
partition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Reste à voir si cet espace est important, et si on peut le récupérer...
Le 10/09/2017 à 23:27, Pascal Hambourg a écrit :
Pour GRUB, il est aussi préférable de créer une petite partitionde type "BIOS boot" (drapeau bios_grub dans (G)parted) pour remplacer
l'espace non alloué qu'il y avait après le MBR, maintenant occupé par
la table de partition principale GPT.
J'ai cru comprendre qu'il n'est pas besoin de la formater.
Pas besoin de beaucoup : 60 kosuffisent,
Certains disent 1 Mo mais je serai radin :o)
et la conversion en GPT laisse des "trous" avant la premièrepartition et entre les ex-partitions logiques qui peuvent faire
l'affaire, surtout si le disque a été initialement partitionné en
appliquant l'alignement moderne sur des blocs de 1 Mio.
Reste à voir si cet espace est important, et si on peut le récupérer...
1 Mio est l'alignement par défaut, donc certains partitionneurs
renâclent à créer une partition plus petite qui sera forcément non
alignée. Mais s'il y a bien une partition pour laquelle on se fiche de
l'alignement, c'est la partition BIOS boot. Elle n'est écrite que lors
de l'installation du chargeur d'amorçage qui l'utilise, donc pas souvent
dans le cas de GRUB.
A l'origine, GRUB 2 était conçu pour que sa core image tienne dans
l'espace de 62 secteurs, soit 31 Kio, situé entre le MBR et le début de
la premièr partition du temps de l'alignement sur les cylindres.
Dans certains cas cela peut dépasser, par exemple lorsque /boot/grub est
dans btrfs sur LVM, ce qui nécessite l'inclusion de pilotes volumineux.
Mais on est encore loin des 60 ko.
Reste à voir si cet espace est important, et si on peut le récupérer...
Comme je l'ai écrit, cela dépend le l'alignement des partition appliqué
lors du partitionnement initial. Avec un alignement sur des cylindres,
cela peut être juste. Il suffit de regarder les positions de début et de
fin des partitions avec fdisk.
Mais si tu veux parler de récupérer ces espaces libres pour agrandir les
partitions ou en créer d'autres (que la partition BIOS boot), tu risques
d'être déçu car cela ne représente au mieux que quelques méga-octets.
1 Mio est l'alignement par défaut, donc certains partitionneurs
renâclent à créer une partition plus petite qui sera forcément non
alignée. Mais s'il y a bien une partition pour laquelle on se fiche de
l'alignement, c'est la partition BIOS boot. Elle n'est écrite que lors
de l'installation du chargeur d'amorçage qui l'utilise, donc pas souvent
dans le cas de GRUB.
A l'origine, GRUB 2 était conçu pour que sa core image tienne dans
l'espace de 62 secteurs, soit 31 Kio, situé entre le MBR et le début de
la premièr partition du temps de l'alignement sur les cylindres.
Dans certains cas cela peut dépasser, par exemple lorsque /boot/grub est
dans btrfs sur LVM, ce qui nécessite l'inclusion de pilotes volumineux.
Mais on est encore loin des 60 ko.
Reste à voir si cet espace est important, et si on peut le récupérer...
Comme je l'ai écrit, cela dépend le l'alignement des partition appliqué
lors du partitionnement initial. Avec un alignement sur des cylindres,
cela peut être juste. Il suffit de regarder les positions de début et de
fin des partitions avec fdisk.
Mais si tu veux parler de récupérer ces espaces libres pour agrandir les
partitions ou en créer d'autres (que la partition BIOS boot), tu risques
d'être déçu car cela ne représente au mieux que quelques méga-octets.
1 Mio est l'alignement par défaut, donc certains partitionneurs
renâclent à créer une partition plus petite qui sera forcément non
alignée. Mais s'il y a bien une partition pour laquelle on se fiche de
l'alignement, c'est la partition BIOS boot. Elle n'est écrite que lors
de l'installation du chargeur d'amorçage qui l'utilise, donc pas souvent
dans le cas de GRUB.
A l'origine, GRUB 2 était conçu pour que sa core image tienne dans
l'espace de 62 secteurs, soit 31 Kio, situé entre le MBR et le début de
la premièr partition du temps de l'alignement sur les cylindres.
Dans certains cas cela peut dépasser, par exemple lorsque /boot/grub est
dans btrfs sur LVM, ce qui nécessite l'inclusion de pilotes volumineux.
Mais on est encore loin des 60 ko.
Reste à voir si cet espace est important, et si on peut le récupérer...
Comme je l'ai écrit, cela dépend le l'alignement des partition appliqué
lors du partitionnement initial. Avec un alignement sur des cylindres,
cela peut être juste. Il suffit de regarder les positions de début et de
fin des partitions avec fdisk.
Mais si tu veux parler de récupérer ces espaces libres pour agrandir les
partitions ou en créer d'autres (que la partition BIOS boot), tu risques
d'être déçu car cela ne représente au mieux que quelques méga-octets.
