Pour les SAN ou les VMs, tu réponds encore à côté, car tu opposes LVM au partitionnement. Ce qui n'est absolument pas le sujet ici
Ton LVM, que tu lui rajoutes un disque entier ou une partition, ne change strictement rien aux possibilités qu'il offre.
Je vais te donner un exemple pour que l'on parle bien de la même chose: tu loues une VM avec disque OS + 1TB de stockage à un client. Le client t'appelle (ou ton monitoring): il manque 100GB. Deux solutions: 1. tu resizes le disque à 1.1TB 2. tu ajoutes un disque de 100GB, ([1]). Les deux fonctionnent, au mois suivant du facture 10% de stockage en plus, tu es content! La différence c'est qu'au 15me appel on va soit se retrouver avec 16 disques, soit avec 1. Hormis l'aspect esthétique et une subtilité technique qui peut être importante (e.g. pour une bdd [2]), il n'y a pas de différence fonctionnelle fondamentale.
Par contre si tu choisis de n'avoir qu'un disque avec une table de partition, il te faudra à chaque fois redimensionner la table des partitions (ce qui est à la fois casse-pieds avec les conversion secteurs/KiBi/Kilo, respecter les alignements, etc—il ne faut pas se planter quoi, soit impossible avec redhat - lol). Donc ne pas avoir de table de partition rend la procédure plus simple. On passe de 5 étapes ("rescan scsi bus"-"rewrite partition table"-pvresize-lvresize-growfs) à 4 ("rescan scisi bus"-pvresize-lvresize-growfs), ce qui est plus court et sans l'étape complexe et dangereuse. Ce qui me semble est l'argument de totof2000.
Si tu décide d'ajouter un device (ce qui n'est pas toujours possible, i.e. emulation ide ou serveur physique plein), la procédure serait en 5 étapes sans partitions ("rescan scsi"-pvcreate-vgextend-lvresize-growfs), ou bien 6 avec partitions ("rescan scsi"-"create partition"-pvcreate-vgextend-lvresize-growfs), ce qui contient autant d'étapes voire une de plus que précédemment.
Donc la question devrait être: pourquoi vouloir utiliser des partitions lorsque cela introduit, au mieux, une étape supplémentaire, ou, au pire, une source d'erreur catastrophique ?
La réponse: "je préfère comme ça, je sais pertinemment ou je ne veux pas savoir comment la couche block de linux interagi avec mon SAN et je n'ai jamais utilisé de redhat ni fait d'erreur catastrophique de ma vie" est tout à fait valable hein[3].
[1]: On peut aussi ajouter un disque de 1.1TB puis faire un pvremove mais c'est (beaucoup) plus long, ça impacte les perfs, et c'est parfois tout simplement pas possible car on a rarement 110% de capacité en spare.
[2]: linux va utiliser 16x plus de queues "virtuelles" sur ton SAN, donc au final il sera très probable que la latence va fortement augmenter.
[3]: Perso j'aime bien avoir des partitions, mais je dois reconnaître qu'utiliser des devices directement présente une certaine praticité (et je n'ai pas encore fait d'erreur catastrophique :D).
[^] # Re: hou la ça remonte a loin ;)
Posté par benja . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1. Dernière modification le 01 janvier 2022 à 00:22.
Je vais te donner un exemple pour que l'on parle bien de la même chose: tu loues une VM avec disque OS + 1TB de stockage à un client. Le client t'appelle (ou ton monitoring): il manque 100GB. Deux solutions: 1. tu resizes le disque à 1.1TB 2. tu ajoutes un disque de 100GB, ([1]). Les deux fonctionnent, au mois suivant du facture 10% de stockage en plus, tu es content! La différence c'est qu'au 15me appel on va soit se retrouver avec 16 disques, soit avec 1. Hormis l'aspect esthétique et une subtilité technique qui peut être importante (e.g. pour une bdd [2]), il n'y a pas de différence fonctionnelle fondamentale.
Par contre si tu choisis de n'avoir qu'un disque avec une table de partition, il te faudra à chaque fois redimensionner la table des partitions (ce qui est à la fois casse-pieds avec les conversion secteurs/KiBi/Kilo, respecter les alignements, etc—il ne faut pas se planter quoi, soit impossible avec redhat - lol). Donc ne pas avoir de table de partition rend la procédure plus simple. On passe de 5 étapes ("rescan scsi bus"-"rewrite partition table"-pvresize-lvresize-growfs) à 4 ("rescan scisi bus"-pvresize-lvresize-growfs), ce qui est plus court et sans l'étape complexe et dangereuse. Ce qui me semble est l'argument de totof2000.
Si tu décide d'ajouter un device (ce qui n'est pas toujours possible, i.e. emulation ide ou serveur physique plein), la procédure serait en 5 étapes sans partitions ("rescan scsi"-pvcreate-vgextend-lvresize-growfs), ou bien 6 avec partitions ("rescan scsi"-"create partition"-pvcreate-vgextend-lvresize-growfs), ce qui contient autant d'étapes voire une de plus que précédemment.
Donc la question devrait être: pourquoi vouloir utiliser des partitions lorsque cela introduit, au mieux, une étape supplémentaire, ou, au pire, une source d'erreur catastrophique ?
La réponse: "je préfère comme ça, je sais pertinemment ou je ne veux pas savoir comment la couche block de linux interagi avec mon SAN et je n'ai jamais utilisé de redhat ni fait d'erreur catastrophique de ma vie" est tout à fait valable hein[3].
[1]: On peut aussi ajouter un disque de 1.1TB puis faire un pvremove mais c'est (beaucoup) plus long, ça impacte les perfs, et c'est parfois tout simplement pas possible car on a rarement 110% de capacité en spare.
[2]: linux va utiliser 16x plus de queues "virtuelles" sur ton SAN, donc au final il sera très probable que la latence va fortement augmenter.
[3]: Perso j'aime bien avoir des partitions, mais je dois reconnaître qu'utiliser des devices directement présente une certaine praticité (et je n'ai pas encore fait d'erreur catastrophique :D).