Après avoir légèrement modifié le partitionnement de mon disque
(regroupement de 3 partitions en 1 mais ne concernant ni "/" ni "/home"),
je me retrouve avec quelque chose de bizarre :
# fdisk /dev/hda
Périphérique Boot Start End Blocks Id System
/dev/hda1 * 1 1024 8225248+ 7 HPFS/NTFS
/dev/hda2 1025 3648 21077280 f W95 Ext'd (LBA)
/dev/hda5 1025 1788 6136798+ 83 Linux
/dev/hda6 2010 3593 12723448+ 83 Linux
/dev/hda7 1789 2009 1775151 83 Linux
/dev/hda8 3594 3648 441756 83 Linux
# mount
/dev/hda5 on / type ext3 (rw,acl)
/dev/hda6 on /autre type ext3 (rw,acl)
/dev/hda7 on /home type ext3 (rw,acl)
/dev/hda1 on /mnt/win_c type ntfs (ro,umask=0,nls=iso8859-15)
Pourquoi n'ai-je que 5.8G sur la partition /dev/hda6 alors qu'elle fait
13Go ?
# cfdisk /dev/hda
Nom Fanions Part Type Type SF [Étiq.] Size (MB)
------------------------------------------------------------------------------
hda1 Amorce Primaire NTFS 8422.69
hda5 Logique Linux ext3 6284.12
hda7 Logique Linux ext3 1817.79
hda6 Logique Linux ext3 13028.85
hda8 Logique Linux 452.40
Comment faire pour rétablir ce sac de noeuds sans perdre mon "/" ni mon
"/home". Je peux toutefois sacrifier sans pb le contenu de /dev/hda6
Dans le message <news:, *Qing Liu* tapota sur f.c.o.l.configuration :
Pour l'histoire du reboot après repartitionnement, c'est presque une FAQ. Le noyau n'intègre pas la nouvelle table de partitions (tu peux vérifier avec cat /proc/partitions), et mke2fs se fie au noyau. En fait, le truc c'est que ça dépend des noyaux. Certaines séries (certaines 2.2.x) prennent en compte la nouvelle table de partition sans rebooter et d'autres (<2.1.x, 2.4.x) non.
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
-- TiChou
Dans le message <news:87zn1tb76t.fsf@emi.gnus.roulaize>,
*Qing Liu* tapota sur f.c.o.l.configuration :
Pour l'histoire du reboot
après repartitionnement, c'est presque une FAQ. Le noyau
n'intègre pas la nouvelle table de partitions (tu peux
vérifier avec cat /proc/partitions), et mke2fs se fie au
noyau. En fait, le truc c'est que ça dépend des noyaux.
Certaines séries (certaines 2.2.x) prennent en compte la
nouvelle table de partition sans rebooter et d'autres
(<2.1.x, 2.4.x) non.
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer
le système à recharger la table des partitions.
Dans le message <news:, *Qing Liu* tapota sur f.c.o.l.configuration :
Pour l'histoire du reboot après repartitionnement, c'est presque une FAQ. Le noyau n'intègre pas la nouvelle table de partitions (tu peux vérifier avec cat /proc/partitions), et mke2fs se fie au noyau. En fait, le truc c'est que ça dépend des noyaux. Certaines séries (certaines 2.2.x) prennent en compte la nouvelle table de partition sans rebooter et d'autres (<2.1.x, 2.4.x) non.
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
-- TiChou
Qing Liu
"TiChou" writes:
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Ah merci, je ne connaissais pas. A tester un jour :)
-- Liu
"TiChou" <gro.uohcit@uohcit> writes:
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée
forcer le système à recharger la table des partitions.
Ah merci, je ne connaissais pas. A tester un jour :)
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Ah merci, je ne connaissais pas. A tester un jour :)
-- Liu
Christophe PEREZ
Le Mon, 08 Nov 2004 00:08:53 +0100, TiChou a écrit:
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Bon à savoir. Mais à condition que ça ne soit pas le disquette système sur lequel on a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 08 Nov 2004 00:08:53 +0100, TiChou a écrit:
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer
le système à recharger la table des partitions.
Bon à savoir.
Mais à condition que ça ne soit pas le disquette système sur lequel on
a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
Le Mon, 08 Nov 2004 00:08:53 +0100, TiChou a écrit:
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Bon à savoir. Mais à condition que ça ne soit pas le disquette système sur lequel on a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Bon à savoir. Mais à condition que ça ne soit pas le disquette système sur lequel on a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour ça que dans la plupart des cas on est obligé de rebooter. :)
-- TiChou
Dans le message <news:pan.2004.11.07.23.23.48.850402@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée
forcer le système à recharger la table des partitions.
Bon à savoir.
Mais à condition que ça ne soit pas le disquette système sur lequel on
a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour
ça que dans la plupart des cas on est obligé de rebooter. :)
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Et sinon il y a l'option '-z' de la commande 'hdparm' qui est sensée forcer le système à recharger la table des partitions.
Bon à savoir. Mais à condition que ça ne soit pas le disquette système sur lequel on a booté (ou plus clair, de pouvoir le démonter entièrement), non ?
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour ça que dans la plupart des cas on est obligé de rebooter. :)
-- TiChou
Christophe PEREZ
Le Mon, 08 Nov 2004 00:42:23 +0100, TiChou a écrit:
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour ça que dans la plupart des cas on est obligé de rebooter. :)
J'me disais bien... ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 08 Nov 2004 00:42:23 +0100, TiChou a écrit:
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour
ça que dans la plupart des cas on est obligé de rebooter. :)
Le Mon, 08 Nov 2004 00:42:23 +0100, TiChou a écrit:
Oui, il faut bien évidement qu'aucune partition soit montée. C'est bien pour ça que dans la plupart des cas on est obligé de rebooter. :)
J'me disais bien... ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
no_spam
On Sun, 07 Nov 2004 22:23:08 +0100, TiChou wrote:
Dans le message <news:, *dominique becaert* tapota sur f.c.o.l.configuration :
/dev/hda5 1025 1788 6136798+ 83 Linux /dev/hda6 2010 3593 12723448+ 83 Linux /dev/hda7 1789 2009 1775151 83 Linux /dev/hda8 3594 3648 441756 83 Linux
Tes partitions ne sont pas dans l'ordre !
Oui mais ça n'est pas un problème que l'ordre des partitions ne correspondent pas à leur numérotation. Sauf peut-être à la commande 'df'...
Je ne crois pas. Ca n'a aucune espèce d'importance sous Linux. Par contre, il me semble me rapeler que Windows n'aime pas trop ! Mais ça fait tellement longtemps ;-)
On Sun, 07 Nov 2004 22:23:08 +0100, TiChou wrote:
Dans le message <news:418E8FB6.47B3E017@Spam.wanadoo.fr>,
*dominique becaert* tapota sur f.c.o.l.configuration :
/dev/hda5 1025 1788 6136798+ 83 Linux
/dev/hda6 2010 3593 12723448+ 83 Linux
/dev/hda7 1789 2009 1775151 83 Linux
/dev/hda8 3594 3648 441756 83 Linux
Tes partitions ne sont pas dans l'ordre !
Oui mais ça n'est pas un problème que l'ordre des partitions ne
correspondent pas à leur numérotation. Sauf peut-être à la commande 'df'...
Je ne crois pas. Ca n'a aucune espèce d'importance sous Linux.
Par contre, il me semble me rapeler que Windows n'aime pas trop !
Mais ça fait tellement longtemps ;-)
Dans le message <news:, *dominique becaert* tapota sur f.c.o.l.configuration :
/dev/hda5 1025 1788 6136798+ 83 Linux /dev/hda6 2010 3593 12723448+ 83 Linux /dev/hda7 1789 2009 1775151 83 Linux /dev/hda8 3594 3648 441756 83 Linux
Tes partitions ne sont pas dans l'ordre !
Oui mais ça n'est pas un problème que l'ordre des partitions ne correspondent pas à leur numérotation. Sauf peut-être à la commande 'df'...
Je ne crois pas. Ca n'a aucune espèce d'importance sous Linux. Par contre, il me semble me rapeler que Windows n'aime pas trop ! Mais ça fait tellement longtemps ;-)
no_spam
On Sun, 07 Nov 2004 18:13:58 -0400, Christophe PEREZ wrote:
Le Sun, 07 Nov 2004 18:03:37 -0400, Christophe PEREZ a écrit:
Concrètement, je fais quoi pour retrouver quelque chose de plus normal ?
Ben voilà, rien en fait ! :-) Enfin, si, juste un reformatage de la partition. [...]
En conclusion, après avoir touché à un partitionnement, rebooter AVANT de formater les partitions en question.
En fait, l'explication est que le kernel ne tient pas compte des modifications de table de partition si au moins une partition du disque en question est montée (ou utilisée comme swap). Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...) Dans le doute, il vaut mieux tout le temps rebooter, si possible.
On Sun, 07 Nov 2004 18:13:58 -0400, Christophe PEREZ wrote:
Le Sun, 07 Nov 2004 18:03:37 -0400, Christophe PEREZ a écrit:
Concrètement, je fais quoi pour retrouver quelque chose de plus normal ?
Ben voilà, rien en fait ! :-)
Enfin, si, juste un reformatage de la partition.
[...]
En conclusion, après avoir touché à un partitionnement, rebooter AVANT
de formater les partitions en question.
En fait, l'explication est que le kernel ne tient pas compte des
modifications de table de partition si au moins une partition du disque en
question est montée (ou utilisée comme swap). Si le disque n'est pas
utilisé, les modifications sont prises en compte tout de suite.
Pour avoir un peu étudié le sujet, il semble que le kernel pourrait
être un peu plus malin et tenir compte des modifications si les
partitions montées n'ont pas changé, ce qui est utile sur des machines
qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des
patches de ce genre...)
Dans le doute, il vaut mieux tout le temps rebooter, si possible.
On Sun, 07 Nov 2004 18:13:58 -0400, Christophe PEREZ wrote:
Le Sun, 07 Nov 2004 18:03:37 -0400, Christophe PEREZ a écrit:
Concrètement, je fais quoi pour retrouver quelque chose de plus normal ?
Ben voilà, rien en fait ! :-) Enfin, si, juste un reformatage de la partition. [...]
En conclusion, après avoir touché à un partitionnement, rebooter AVANT de formater les partitions en question.
En fait, l'explication est que le kernel ne tient pas compte des modifications de table de partition si au moins une partition du disque en question est montée (ou utilisée comme swap). Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...) Dans le doute, il vaut mieux tout le temps rebooter, si possible.
Nicolas George
no_spam wrote in message :
Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
no_spam wrote in message <pan.2004.11.08.13.27.25.842207@magic.fr>:
Si le disque n'est pas
utilisé, les modifications sont prises en compte tout de suite.
Pour avoir un peu étudié le sujet, il semble que le kernel pourrait
être un peu plus malin et tenir compte des modifications si les
partitions montées n'ont pas changé, ce qui est utile sur des machines
qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des
patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
Shmurtz
Le Sun, 07 Nov 2004 22:51:19 +0100, TiChou s'exprimait:
Non, du tout, c'est la syntaxe de la commande donnée qui est incorrecte. On doit utiliser la commande 'fdisk' sur des périphériques disques (/dev/hda, /dev/sda, etc)
Exact, j'ai dû confondre avec autre chose.
-- The BEST oxymoron: Microsoft Works®
Le Sun, 07 Nov 2004 22:51:19 +0100, TiChou s'exprimait:
Non, du tout, c'est la syntaxe de la commande donnée qui est incorrecte. On
doit utiliser la commande 'fdisk' sur des périphériques disques (/dev/hda,
/dev/sda, etc)
Le Sun, 07 Nov 2004 22:51:19 +0100, TiChou s'exprimait:
Non, du tout, c'est la syntaxe de la commande donnée qui est incorrecte. On doit utiliser la commande 'fdisk' sur des périphériques disques (/dev/hda, /dev/sda, etc)
Exact, j'ai dû confondre avec autre chose.
-- The BEST oxymoron: Microsoft Works®
no_spam
On Mon, 08 Nov 2004 13:57:12 +0000, Nicolas George wrote:
no_spam wrote in message :
Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
Ca n'a pourtant pas grand rapport. Ce sont les couches génériques de revalidation de disque et de partitions qui refusent de changer le mapping d'un bloc device occupé: dans fs/partitions/check.c:rescan_partitions ça commence par: if (bdev->bd_part_count) return -EBUSY; Quel que soit le type de bloc device en dessous (lvm ou autre), à partir du moment ou une partition est montée, le scan des partitions ne se fait pas. C'est ce test là qui bloque tout: cette fonction est appelée quasi directement quand on utilise l'ioctl BLKRRPART, qui est celui qui sert justement à valider une nouvelle table de partition.
On Mon, 08 Nov 2004 13:57:12 +0000, Nicolas George wrote:
no_spam wrote in message <pan.2004.11.08.13.27.25.842207@magic.fr>:
Si le disque n'est pas
utilisé, les modifications sont prises en compte tout de suite.
Pour avoir un peu étudié le sujet, il semble que le kernel pourrait
être un peu plus malin et tenir compte des modifications si les
partitions montées n'ont pas changé, ce qui est utile sur des machines
qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des
patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
Ca n'a pourtant pas grand rapport.
Ce sont les couches génériques de revalidation de disque et de
partitions qui refusent de changer le mapping d'un bloc device occupé:
dans fs/partitions/check.c:rescan_partitions
ça commence par:
if (bdev->bd_part_count)
return -EBUSY;
Quel que soit le type de bloc device en dessous (lvm ou autre), à partir
du moment ou une partition est montée, le scan des partitions ne se fait
pas.
C'est ce test là qui bloque tout: cette fonction est appelée quasi
directement quand on utilise l'ioctl BLKRRPART, qui est celui qui sert
justement à valider une nouvelle table de partition.
On Mon, 08 Nov 2004 13:57:12 +0000, Nicolas George wrote:
no_spam wrote in message :
Si le disque n'est pas utilisé, les modifications sont prises en compte tout de suite. Pour avoir un peu étudié le sujet, il semble que le kernel pourrait être un peu plus malin et tenir compte des modifications si les partitions montées n'ont pas changé, ce qui est utile sur des machines qu'on ne peut pas ou ne veux pas rebooter (j'ai fait et j'utilise des patches de ce genre...)
C'est un des objets de LVM de faire ça proprement.
Ca n'a pourtant pas grand rapport. Ce sont les couches génériques de revalidation de disque et de partitions qui refusent de changer le mapping d'un bloc device occupé: dans fs/partitions/check.c:rescan_partitions ça commence par: if (bdev->bd_part_count) return -EBUSY; Quel que soit le type de bloc device en dessous (lvm ou autre), à partir du moment ou une partition est montée, le scan des partitions ne se fait pas. C'est ce test là qui bloque tout: cette fonction est appelée quasi directement quand on utilise l'ioctl BLKRRPART, qui est celui qui sert justement à valider une nouvelle table de partition.
