Je cherche un objet qui, comme les licornes qui font caca des arcs en
ciel, semble n'exister que dans mes rêves les plus audacieux:
- Un NAS susceptible d'acceuilir un lot hétérogène de disques (tailles
différentes mais tous en SATA 2 ou 3) _et_ capable non pas de faire du
RAID mais du LVM.
En clair, j'ai plusieurs disques de tailles variables et j'aurai
souhaité les agréger pour faire un NAS de la taille de la somme des
espaces disques.
Ce NAS pourrait se contenter d'être joignable via USB (USB3 dans
l'idéal) mais une connection par réseau uniquement n'est pas un frein.
Existe-ti une solution 'sur étagère' (genre NAS) à ce genre de
problème ?
Toutes les solutions NAS ce que j'ai pu trouver sur Internet semblent ne
faire que du RAID ce qui ne convient pas dans mon cas puisque mes
disques ne sont pas tous de la même taille.
Bien entendu je pourrais mettre en place une slackware minimaliste dotée
d'une interface réseau et qui exporterait un NFS/SSHFS du LV composé de
l'ensemble des disques mais j'aimerai éviter de devoir laisser sous
tension une machine par trop energivore *supplémentaire*.
Merci de vos conseils.
--
Le ciel est bleu, le jour est J.
La bombe est H mais mon grand-père s'ennuie
Comme un chien dans un cimetière le quatorze juillet.
-- H.F. Thiéfaine, Comme un chien dans un cimetière
Le Mon, 12 Feb 2018 20:59:14 +0100, Pascal Hambourg a écrit :
A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence, mais quel est le contre du partitionnement et le pour de son absence ?
Pour être honnête... je ne m'en souviens plus :-p J'avais lu ça dans un article écrit par l'un des devs de LVM il y a quelques années ou il défendait le fait de ne pas partitionner le disque pour un usage exclusif avec LVM, mais je ne me souviens plus de son argumentaire. Il y a au moins un avantage à se passer de partitionnement: dans le cas ou on étend un bloc device (présenté par un SAN par exemple), la prise en compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce bloc device a été partitionné, il faudra d'abord re-partitionner le bloc device. (ok, c'est léger comme argument...) Un autre argument en faveur de LVM directemetn sur le raw disk serait la migration de données: on peut déplacer à chaud avec un pvmove, ce qui serait impossible si le PV est sur une partition ? à vérifier, je n'ai jamais eu à efefctuer ce genre de manip. Il y a aussi la question de l'alignement à gérer si on partitionne... -- Rico
Le Mon, 12 Feb 2018 20:59:14 +0100, Pascal Hambourg a écrit :
A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence,
mais quel est le contre du partitionnement et le pour de son absence ?
Pour être honnête... je ne m'en souviens plus :-p
J'avais lu ça dans un article écrit par l'un des devs de LVM il y a
quelques années ou il défendait le fait de ne pas partitionner le disque
pour un usage exclusif avec LVM, mais je ne me souviens plus de son
argumentaire.
Il y a au moins un avantage à se passer de partitionnement: dans le cas ou
on étend un bloc device (présenté par un SAN par exemple), la prise en
compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce
bloc device a été partitionné, il faudra d'abord re-partitionner le bloc
device. (ok, c'est léger comme argument...)
Un autre argument en faveur de LVM directemetn sur le raw disk serait la
migration de données: on peut déplacer à chaud avec un pvmove, ce qui
serait impossible si le PV est sur une partition ? à vérifier, je n'ai
jamais eu à efefctuer ce genre de manip.
Il y a aussi la question de l'alignement à gérer si on partitionne...
Le Mon, 12 Feb 2018 20:59:14 +0100, Pascal Hambourg a écrit :
A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence, mais quel est le contre du partitionnement et le pour de son absence ?
Pour être honnête... je ne m'en souviens plus :-p J'avais lu ça dans un article écrit par l'un des devs de LVM il y a quelques années ou il défendait le fait de ne pas partitionner le disque pour un usage exclusif avec LVM, mais je ne me souviens plus de son argumentaire. Il y a au moins un avantage à se passer de partitionnement: dans le cas ou on étend un bloc device (présenté par un SAN par exemple), la prise en compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce bloc device a été partitionné, il faudra d'abord re-partitionner le bloc device. (ok, c'est léger comme argument...) Un autre argument en faveur de LVM directemetn sur le raw disk serait la migration de données: on peut déplacer à chaud avec un pvmove, ce qui serait impossible si le PV est sur une partition ? à vérifier, je n'ai jamais eu à efefctuer ce genre de manip. Il y a aussi la question de l'alignement à gérer si on partitionne... -- Rico
Ascadix
Pascal Hambourg a écrit dans <p5srmi$vqi$: <news:p5srmi$vqi$
Le 12/02/2018 à 11:41, Eric Belhomme a écrit :
LVM n'impose pas de partitionner un disque préalabmement à son utilisation avec LVM ! Il est parfaitement possible d'utiliser la commande suivante : pvcreate /dev/sda Et le volume /dev/sda sera parfaitement disponible pour être ajouté à un VG, bien que les outils de partitionnement (fdisk, parted) verront un disque non initilisé. Ou alors on peut créer une table de partition avec un unique (ou plusieurs) volume LVM. A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence, mais quel est le contre du partitionnement et le pour de son absence ?
Gain de qq manips & secondes pendant la configuration Perte de qq Mo d'espace HDD L'amour du risque :-)
(personnelement je préfère partitionner et créer un volume LVM, ça evite la confusion surtout si je ne suis pas le seul à opérer sur les machines)
Pareil.
ça pour le même principe d'éviter les pbs de destructions accidentelle de données qu'un DD partitionné en GPT dispose généralement d'une pseudo table "MBR protector" qui vis à vis des outils incompatibles GPT déclare que le DD dispose d'une unique partition de type "GPT" ingérable par ces outils. -- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Pascal Hambourg a écrit dans <p5srmi$vqi$2@saria.nerim.net>:
<news:p5srmi$vqi$2@saria.nerim.net>
Le 12/02/2018 à 11:41, Eric Belhomme a écrit :
LVM n'impose pas de partitionner un disque préalabmement à son
utilisation avec LVM !
Il est parfaitement possible d'utiliser la commande suivante :
pvcreate /dev/sda
Et le volume /dev/sda sera parfaitement disponible pour être ajouté à un
VG, bien que les outils de partitionnement (fdisk, parted) verront un
disque non initilisé.
Ou alors on peut créer une table de partition avec un unique (ou
plusieurs) volume LVM.
A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence, mais
quel est le contre du partitionnement et le pour de son absence ?
Gain de qq manips & secondes pendant la configuration
Perte de qq Mo d'espace HDD
L'amour du risque :-)
(personnelement je préfère partitionner et créer un volume LVM, ça evite
la confusion surtout si je ne suis pas le seul à opérer sur les machines)
Pareil.
ça pour le même principe d'éviter les pbs de destructions accidentelle
de données qu'un DD partitionné en GPT dispose généralement d'une
pseudo table "MBR protector" qui vis à vis des outils incompatibles GPT
déclare que le DD dispose d'une unique partition de type "GPT"
ingérable par ces outils.
--
@+
Ascadix
adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça
arrive.
Pascal Hambourg a écrit dans <p5srmi$vqi$: <news:p5srmi$vqi$
Le 12/02/2018 à 11:41, Eric Belhomme a écrit :
LVM n'impose pas de partitionner un disque préalabmement à son utilisation avec LVM ! Il est parfaitement possible d'utiliser la commande suivante : pvcreate /dev/sda Et le volume /dev/sda sera parfaitement disponible pour être ajouté à un VG, bien que les outils de partitionnement (fdisk, parted) verront un disque non initilisé. Ou alors on peut créer une table de partition avec un unique (ou plusieurs) volume LVM. A vrai dire, il y a du pour et du contre pour les 2 approches
Je vois bien le pour du partitionnement et le contre de son absence, mais quel est le contre du partitionnement et le pour de son absence ?
Gain de qq manips & secondes pendant la configuration Perte de qq Mo d'espace HDD L'amour du risque :-)
(personnelement je préfère partitionner et créer un volume LVM, ça evite la confusion surtout si je ne suis pas le seul à opérer sur les machines)
Pareil.
ça pour le même principe d'éviter les pbs de destructions accidentelle de données qu'un DD partitionné en GPT dispose généralement d'une pseudo table "MBR protector" qui vis à vis des outils incompatibles GPT déclare que le DD dispose d'une unique partition de type "GPT" ingérable par ces outils. -- @+ Ascadix adresse @mail valide, mais ajoutez "sesame" dans l'objet pour que ça arrive.
Pascal Hambourg
Le 13/02/2018 à 09:49, Eric Belhomme a écrit :
Il y a au moins un avantage à se passer de partitionnement: dans le cas ou on étend un bloc device (présenté par un SAN par exemple), la prise en compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce bloc device a été partitionné, il faudra d'abord re-partitionner le bloc device. (ok, c'est léger comme argument...)
Plutôt léger en effet.
Un autre argument en faveur de LVM directemetn sur le raw disk serait la migration de données: on peut déplacer à chaud avec un pvmove, ce qui serait impossible si le PV est sur une partition ? à vérifier, je n'ai jamais eu à efefctuer ce genre de manip.
Je ne vois pas pourquoi ce serait impossible avec une partition. Pour LVM, un block device est un block device, que ce soit un disque ou une partition.
Il y a aussi la question de l'alignement à gérer si on partitionne...
Avec l'alignement standard actuel sur des blocs de 1 Mio, ça ne pose pas de problème sur les SSD et les disques durs au format avancé 512e. Il y a fort longtemps, on pouvait invoquer la limite à 2 Tio du partitionnement DOS pour les gros stockages, mais elle a été levée par le partitionnement GPT.
Le 13/02/2018 à 09:49, Eric Belhomme a écrit :
Il y a au moins un avantage à se passer de partitionnement: dans le cas ou
on étend un bloc device (présenté par un SAN par exemple), la prise en
compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce
bloc device a été partitionné, il faudra d'abord re-partitionner le bloc
device. (ok, c'est léger comme argument...)
Plutôt léger en effet.
Un autre argument en faveur de LVM directemetn sur le raw disk serait la
migration de données: on peut déplacer à chaud avec un pvmove, ce qui
serait impossible si le PV est sur une partition ? à vérifier, je n'ai
jamais eu à efefctuer ce genre de manip.
Je ne vois pas pourquoi ce serait impossible avec une partition. Pour
LVM, un block device est un block device, que ce soit un disque ou une
partition.
Il y a aussi la question de l'alignement à gérer si on partitionne...
Avec l'alignement standard actuel sur des blocs de 1 Mio, ça ne pose pas
de problème sur les SSD et les disques durs au format avancé 512e.
Il y a fort longtemps, on pouvait invoquer la limite à 2 Tio du
partitionnement DOS pour les gros stockages, mais elle a été levée par
le partitionnement GPT.
Il y a au moins un avantage à se passer de partitionnement: dans le cas ou on étend un bloc device (présenté par un SAN par exemple), la prise en compte par LVM se limite à "pvresize /dev/blockdevice" alors que si ce bloc device a été partitionné, il faudra d'abord re-partitionner le bloc device. (ok, c'est léger comme argument...)
Plutôt léger en effet.
Un autre argument en faveur de LVM directemetn sur le raw disk serait la migration de données: on peut déplacer à chaud avec un pvmove, ce qui serait impossible si le PV est sur une partition ? à vérifier, je n'ai jamais eu à efefctuer ce genre de manip.
Je ne vois pas pourquoi ce serait impossible avec une partition. Pour LVM, un block device est un block device, que ce soit un disque ou une partition.
Il y a aussi la question de l'alignement à gérer si on partitionne...
Avec l'alignement standard actuel sur des blocs de 1 Mio, ça ne pose pas de problème sur les SSD et les disques durs au format avancé 512e. Il y a fort longtemps, on pouvait invoquer la limite à 2 Tio du partitionnement DOS pour les gros stockages, mais elle a été levée par le partitionnement GPT.
