Je me pose 2 questions, liées dans mon cas, mais indépendantes :
1) Un Raid 1 sur du SSD, ça a un sens ou c'est stupide pour une raison
que je ne connais pas ?
C'est juste pour mon serveur perso. Je voudrais en accélérer le
fonctionnement, en particulier pour le montage NFS du /home (Linux).
Et à l'heure actuelle j'ai 2 HD en raid 1, et j'aime bcp le principe.
J'aurais passé le /home sur 1 (ou 2 si raid) SSD.
2) Soit 2 disques identiques en raid 1. Moi j'ai partitionné mes 2
disques de façons identiques, et j'ai ensuite lié les partitions par le
raid.
Mais j'ai cru comprendre (bien après l'avoir mis en place) que j'aurais
aussi pu lier les 2 disques dans leur ensemble, puis partitionner le
résultat.
Vrai ou faux ?
Si vrai, comme à priori , dans l'usage, ça revient au même, quel est donc
l'intérêt d'une façon de faire plutôt que l'autre (si intérêt il y a) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Le 07/07/2018 à 23:07, Christophe PEREZ a écrit :
1) Un Raid 1 sur du SSD, ça a un sens ou c'est stupide pour une raison que je ne connais pas ?
Les SSD ne tombent jamais en panne ? (Précisons pour les lecteurs que la suite concerne le RAID logiciel de Linux)
2) Soit 2 disques identiques en raid 1. Moi j'ai partitionné mes 2 disques de façons identiques, et j'ai ensuite lié les partitions par le raid. Mais j'ai cru comprendre (bien après l'avoir mis en place) que j'aurais aussi pu lier les 2 disques dans leur ensemble, puis partitionner le résultat. Vrai ou faux ?
Vrai. Le RAID logiciel de Linux fonctionne sur n'importe quel type de périphérique bloc.
Si vrai, comme à priori , dans l'usage, ça revient au même, quel est donc l'intérêt d'une façon de faire plutôt que l'autre (si intérêt il y a) ?
Disclaimer : ce qui suit n'est que mon avis. Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de pouvoir créer des ensembles RAID de niveau différent en fonction des besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID 10... Si tous les ensembles ont le même niveau, c'est une méthode très lourde et très peu flexible car modifier un ensemble RAID n'est pas facile. D'autre part en cas de remplacement d'un disque défaillant, il faut reconstruire chaque ensemble RAID un par un. Utiliser les disque entiers non partitionnés a plusieurs inconvénients. 1) Quand on veut voir la structure d'un disque, le premier réflexe est d'utiliser un programme de gestion des partitions. Mais la structure d'un disque organisé de cette façon n'est pas visible avec ce type de programme puisqu'il n'a pas de table de partition. Le risque d'erreur et d'incompréhension est grand. 2) Cela peut poser un problème pour l'amorçage à partir de ces disques. L'espace disponible pour un chargeur d'amorçage BIOS est limité à quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non partitionnés de toute façon). L'absence de table de partition est aussi incompatible avec l'amorçage EFI qui a besoin d'une table de partition DOS ou GPT. Il y a une méthode intermédiaire qui évite les inconvénients des deux autres méthodes : partitionner les disques avec une seule partition RAID qui occupe tout l'espace et créer un unique ensemble RAID. Pour organiser le contenu de l'ensemble RAID, il y a deux méthodes : a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions. b) Utiliser l'ensemble RAID comme volume physique LVM et créer des volumes logiques. C'est la solution la plus flexible si on doit être amené à redimensionner les volumes.
Le 07/07/2018 à 23:07, Christophe PEREZ a écrit :
1) Un Raid 1 sur du SSD, ça a un sens ou c'est stupide pour une raison
que je ne connais pas ?
Les SSD ne tombent jamais en panne ?
(Précisons pour les lecteurs que la suite concerne le RAID logiciel de
Linux)
2) Soit 2 disques identiques en raid 1. Moi j'ai partitionné mes 2
disques de façons identiques, et j'ai ensuite lié les partitions par le
raid.
Mais j'ai cru comprendre (bien après l'avoir mis en place) que j'aurais
aussi pu lier les 2 disques dans leur ensemble, puis partitionner le
résultat.
Vrai ou faux ?
Vrai. Le RAID logiciel de Linux fonctionne sur n'importe quel type de
périphérique bloc.
Si vrai, comme à priori , dans l'usage, ça revient au même, quel est donc
l'intérêt d'une façon de faire plutôt que l'autre (si intérêt il y a) ?
Disclaimer : ce qui suit n'est que mon avis.
Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de
pouvoir créer des ensembles RAID de niveau différent en fonction des
besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID
10... Si tous les ensembles ont le même niveau, c'est une méthode très
lourde et très peu flexible car modifier un ensemble RAID n'est pas
facile. D'autre part en cas de remplacement d'un disque défaillant, il
faut reconstruire chaque ensemble RAID un par un.
Utiliser les disque entiers non partitionnés a plusieurs inconvénients.
1) Quand on veut voir la structure d'un disque, le premier réflexe est
d'utiliser un programme de gestion des partitions. Mais la structure
d'un disque organisé de cette façon n'est pas visible avec ce type de
programme puisqu'il n'a pas de table de partition. Le risque d'erreur et
d'incompréhension est grand.
2) Cela peut poser un problème pour l'amorçage à partir de ces disques.
L'espace disponible pour un chargeur d'amorçage BIOS est limité à
quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non
partitionnés de toute façon). L'absence de table de partition est aussi
incompatible avec l'amorçage EFI qui a besoin d'une table de partition
DOS ou GPT.
Il y a une méthode intermédiaire qui évite les inconvénients des deux
autres méthodes : partitionner les disques avec une seule partition RAID
qui occupe tout l'espace et créer un unique ensemble RAID. Pour
organiser le contenu de l'ensemble RAID, il y a deux méthodes :
a) Créer une table de partition classique DOS ou GPT et des partitions
dans l'ensemble RAID avec les outils classiques de gestion des partitions.
b) Utiliser l'ensemble RAID comme volume physique LVM et créer des
volumes logiques. C'est la solution la plus flexible si on doit être
amené à redimensionner les volumes.
1) Un Raid 1 sur du SSD, ça a un sens ou c'est stupide pour une raison que je ne connais pas ?
Les SSD ne tombent jamais en panne ? (Précisons pour les lecteurs que la suite concerne le RAID logiciel de Linux)
2) Soit 2 disques identiques en raid 1. Moi j'ai partitionné mes 2 disques de façons identiques, et j'ai ensuite lié les partitions par le raid. Mais j'ai cru comprendre (bien après l'avoir mis en place) que j'aurais aussi pu lier les 2 disques dans leur ensemble, puis partitionner le résultat. Vrai ou faux ?
Vrai. Le RAID logiciel de Linux fonctionne sur n'importe quel type de périphérique bloc.
Si vrai, comme à priori , dans l'usage, ça revient au même, quel est donc l'intérêt d'une façon de faire plutôt que l'autre (si intérêt il y a) ?
Disclaimer : ce qui suit n'est que mon avis. Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de pouvoir créer des ensembles RAID de niveau différent en fonction des besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID 10... Si tous les ensembles ont le même niveau, c'est une méthode très lourde et très peu flexible car modifier un ensemble RAID n'est pas facile. D'autre part en cas de remplacement d'un disque défaillant, il faut reconstruire chaque ensemble RAID un par un. Utiliser les disque entiers non partitionnés a plusieurs inconvénients. 1) Quand on veut voir la structure d'un disque, le premier réflexe est d'utiliser un programme de gestion des partitions. Mais la structure d'un disque organisé de cette façon n'est pas visible avec ce type de programme puisqu'il n'a pas de table de partition. Le risque d'erreur et d'incompréhension est grand. 2) Cela peut poser un problème pour l'amorçage à partir de ces disques. L'espace disponible pour un chargeur d'amorçage BIOS est limité à quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non partitionnés de toute façon). L'absence de table de partition est aussi incompatible avec l'amorçage EFI qui a besoin d'une table de partition DOS ou GPT. Il y a une méthode intermédiaire qui évite les inconvénients des deux autres méthodes : partitionner les disques avec une seule partition RAID qui occupe tout l'espace et créer un unique ensemble RAID. Pour organiser le contenu de l'ensemble RAID, il y a deux méthodes : a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions. b) Utiliser l'ensemble RAID comme volume physique LVM et créer des volumes logiques. C'est la solution la plus flexible si on doit être amené à redimensionner les volumes.
Christophe PEREZ
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici : https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances. De plus, le titre "PC des particuliers", bien que je sois un particulier, me semble plus orienté PC desktop, donc pas tout à fait le même usage que le mien. Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici :
https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances.
De plus, le titre "PC des particuliers", bien que je sois un particulier,
me semble plus orienté PC desktop, donc pas tout à fait le même usage que
le mien.
Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un
seul disque, ça vaut déjà le détour.
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici : https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances. De plus, le titre "PC des particuliers", bien que je sois un particulier, me semble plus orienté PC desktop, donc pas tout à fait le même usage que le mien. Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
Christophe PEREZ
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
Les SSD ne tombent jamais en panne ?
Ben selon moi si, c'est bien pour ça que je m'accroche à mon raid.
(Précisons pour les lecteurs que la suite concerne le RAID logiciel de Linux)
Exact, j'ai complètement omis de le préciser. JE l'ai dit "ailleurs" mais oublié dans ce post.
Disclaimer : ce qui suit n'est que mon avis.
Et c'est bien ce qui compte à mes yeux ;)
Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de pouvoir créer des ensembles RAID de niveau différent en fonction des besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID 10... Si tous les ensembles ont le même niveau, c'est une méthode très lourde et très peu flexible car modifier un ensemble RAID n'est pas facile.
Clair, ils sont tous en raid 1.
D'autre part en cas de remplacement d'un disque défaillant, il faut reconstruire chaque ensemble RAID un par un.
Bon, ça, on lance tout et ça se fait séquentiellement, donc au final, ça ne change pas grand chose, à mes yeux, mais c'est vrai que plus simple c'est mieux, forcément.
Utiliser les disque entiers non partitionnés a plusieurs inconvénients. 1) Quand on veut voir la structure d'un disque, le premier réflexe est d'utiliser un programme de gestion des partitions. Mais la structure d'un disque organisé de cette façon n'est pas visible avec ce type de programme puisqu'il n'a pas de table de partition. Le risque d'erreur et d'incompréhension est grand.
Au début oui, mais on s'y habitue ;)
2) Cela peut poser un problème pour l'amorçage à partir de ces disques. L'espace disponible pour un chargeur d'amorçage BIOS est limité à quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non partitionnés de toute façon). L'absence de table de partition est aussi incompatible avec l'amorçage EFI qui a besoin d'une table de partition DOS ou GPT.
Pas de GPT sur cette machine. Sinon, pour le reste, heureusement, je n'ai jamais eu de problème, et j'y ai GRUB (1).
Il y a une méthode intermédiaire qui évite les inconvénients des deux autres méthodes : partitionner les disques avec une seule partition RAID qui occupe tout l'espace et créer un unique ensemble RAID. Pour organiser le contenu de l'ensemble RAID, il y a deux méthodes : a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;) Je garde l'idée de côté, j'achèterai sans doute 2 SSD, et je testerai ça.
b) Utiliser l'ensemble RAID comme volume physique LVM et créer des volumes logiques. C'est la solution la plus flexible si on doit être amené à redimensionner les volumes.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions. Merci beaucoup pour tes éclairages toujours pédagogiques, argumentés, complets et accessibles.
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
Les SSD ne tombent jamais en panne ?
Ben selon moi si, c'est bien pour ça que je m'accroche à mon raid.
(Précisons pour les lecteurs que la suite concerne le RAID logiciel de
Linux)
Exact, j'ai complètement omis de le préciser. JE l'ai dit "ailleurs" mais
oublié dans ce post.
Disclaimer : ce qui suit n'est que mon avis.
Et c'est bien ce qui compte à mes yeux ;)
Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de
pouvoir créer des ensembles RAID de niveau différent en fonction des
besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID
10... Si tous les ensembles ont le même niveau, c'est une méthode très
lourde et très peu flexible car modifier un ensemble RAID n'est pas
facile.
Clair, ils sont tous en raid 1.
D'autre part en cas de remplacement d'un disque défaillant, il
faut reconstruire chaque ensemble RAID un par un.
Bon, ça, on lance tout et ça se fait séquentiellement, donc au final, ça
ne change pas grand chose, à mes yeux, mais c'est vrai que plus simple
c'est mieux, forcément.
Utiliser les disque entiers non partitionnés a plusieurs inconvénients.
1) Quand on veut voir la structure d'un disque, le premier réflexe est
d'utiliser un programme de gestion des partitions. Mais la structure
d'un disque organisé de cette façon n'est pas visible avec ce type de
programme puisqu'il n'a pas de table de partition. Le risque d'erreur et
d'incompréhension est grand.
Au début oui, mais on s'y habitue ;)
2) Cela peut poser un problème pour l'amorçage à partir de ces disques.
L'espace disponible pour un chargeur d'amorçage BIOS est limité à
quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non
partitionnés de toute façon). L'absence de table de partition est aussi
incompatible avec l'amorçage EFI qui a besoin d'une table de partition
DOS ou GPT.
Pas de GPT sur cette machine. Sinon, pour le reste, heureusement, je n'ai
jamais eu de problème, et j'y ai GRUB (1).
Il y a une méthode intermédiaire qui évite les inconvénients des deux
autres méthodes : partitionner les disques avec une seule partition RAID
qui occupe tout l'espace et créer un unique ensemble RAID. Pour
organiser le contenu de l'ensemble RAID, il y a deux méthodes :
a) Créer une table de partition classique DOS ou GPT et des partitions
dans l'ensemble RAID avec les outils classiques de gestion des
partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas
bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;)
Je garde l'idée de côté, j'achèterai sans doute 2 SSD, et je testerai ça.
b) Utiliser l'ensemble RAID comme volume physique LVM et créer des
volumes logiques. C'est la solution la plus flexible si on doit être
amené à redimensionner les volumes.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot.
De plus, en général, je compte assez large, et ne redimensionneme pas mes
partitions.
Merci beaucoup pour tes éclairages toujours pédagogiques, argumentés,
complets et accessibles.
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
Les SSD ne tombent jamais en panne ?
Ben selon moi si, c'est bien pour ça que je m'accroche à mon raid.
(Précisons pour les lecteurs que la suite concerne le RAID logiciel de Linux)
Exact, j'ai complètement omis de le préciser. JE l'ai dit "ailleurs" mais oublié dans ce post.
Disclaimer : ce qui suit n'est que mon avis.
Et c'est bien ce qui compte à mes yeux ;)
Le seul intérêt de ta méthode de créer N ensembles RAID, c'est de pouvoir créer des ensembles RAID de niveau différent en fonction des besoins du contenu de chaque ensemble : RAID 0, RAID 1, RAID 6, RAID 10... Si tous les ensembles ont le même niveau, c'est une méthode très lourde et très peu flexible car modifier un ensemble RAID n'est pas facile.
Clair, ils sont tous en raid 1.
D'autre part en cas de remplacement d'un disque défaillant, il faut reconstruire chaque ensemble RAID un par un.
Bon, ça, on lance tout et ça se fait séquentiellement, donc au final, ça ne change pas grand chose, à mes yeux, mais c'est vrai que plus simple c'est mieux, forcément.
Utiliser les disque entiers non partitionnés a plusieurs inconvénients. 1) Quand on veut voir la structure d'un disque, le premier réflexe est d'utiliser un programme de gestion des partitions. Mais la structure d'un disque organisé de cette façon n'est pas visible avec ce type de programme puisqu'il n'a pas de table de partition. Le risque d'erreur et d'incompréhension est grand.
Au début oui, mais on s'y habitue ;)
2) Cela peut poser un problème pour l'amorçage à partir de ces disques. L'espace disponible pour un chargeur d'amorçage BIOS est limité à quelques secteurs, insuffisant pour GRUB (qui n'aime pas les disques non partitionnés de toute façon). L'absence de table de partition est aussi incompatible avec l'amorçage EFI qui a besoin d'une table de partition DOS ou GPT.
Pas de GPT sur cette machine. Sinon, pour le reste, heureusement, je n'ai jamais eu de problème, et j'y ai GRUB (1).
Il y a une méthode intermédiaire qui évite les inconvénients des deux autres méthodes : partitionner les disques avec une seule partition RAID qui occupe tout l'espace et créer un unique ensemble RAID. Pour organiser le contenu de l'ensemble RAID, il y a deux méthodes : a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;) Je garde l'idée de côté, j'achèterai sans doute 2 SSD, et je testerai ça.
b) Utiliser l'ensemble RAID comme volume physique LVM et créer des volumes logiques. C'est la solution la plus flexible si on doit être amené à redimensionner les volumes.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions. Merci beaucoup pour tes éclairages toujours pédagogiques, argumentés, complets et accessibles.
Pascal Hambourg
Le 08/07/2018 à 14:43, Christophe PEREZ a écrit :
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;)
fdisk /dev/mdX Les partitions seront nommées /dev/mdXpY. Une difficulté peut apparaître lors de l'installation si l'outil de partitionnement de l'installateur ne permet pas de partitionner (créer une table de partition sur) un ensemble RAID. C'est le cas de partman, le partitionneur de l'installateur Debian. Il faut créer la table de partition par un autre moyen (le shell de l'installateur par exemple) et ensuite partman permet de créer des partitions.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut être utile pour récupérer une erreur ou faire les sauvegardes.
Le 08/07/2018 à 14:43, Christophe PEREZ a écrit :
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
a) Créer une table de partition classique DOS ou GPT et des partitions
dans l'ensemble RAID avec les outils classiques de gestion des
partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas
bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;)
fdisk /dev/mdX
Les partitions seront nommées /dev/mdXpY.
Une difficulté peut apparaître lors de l'installation si l'outil de
partitionnement de l'installateur ne permet pas de partitionner (créer
une table de partition sur) un ensemble RAID. C'est le cas de partman,
le partitionneur de l'installateur Debian. Il faut créer la table de
partition par un autre moyen (le shell de l'installateur par exemple) et
ensuite partman permet de créer des partitions.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot.
De plus, en général, je compte assez large, et ne redimensionneme pas mes
partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut
être utile pour récupérer une erreur ou faire les sauvegardes.
Le Sun, 08 Jul 2018 11:00:52 +0200, Pascal Hambourg a écrit :
a) Créer une table de partition classique DOS ou GPT et des partitions dans l'ensemble RAID avec les outils classiques de gestion des partitions.
Du coup, je suppose que ça serait l'idéal pour moi, mais j'avoue ne pas bien saisir le truc. Faut que je manipule le cas pour sentir la chose ;)
fdisk /dev/mdX Les partitions seront nommées /dev/mdXpY. Une difficulté peut apparaître lors de l'installation si l'outil de partitionnement de l'installateur ne permet pas de partitionner (créer une table de partition sur) un ensemble RAID. C'est le cas de partman, le partitionneur de l'installateur Debian. Il faut créer la table de partition par un autre moyen (le shell de l'installateur par exemple) et ensuite partman permet de créer des partitions.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut être utile pour récupérer une erreur ou faire les sauvegardes.
Pascal Hambourg
Le 08/07/2018 à 14:34, Christophe PEREZ a écrit :
Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
Le RAID 1 avec de disques durs pouvait déjà être plus rapide qu'un disque seul pour les accès aléatoires en lecture, notamment grâce à la parallélisation des temps d'accès. Mais la vitesse de lecture séquentielle n'était pas améliorée pour des raisons liées à la mécanique des disques (un disque met autant de temps à sauter un bloc qu'à le lire). Pour améliorer le débit séquentiel en lecture, il fallait utiliser l'agrégation en bandes comme en RAID 10 par exemple. Je n'ai pas eu l'occasion de faire ou de voir des résultats de tests du RAID 1 de Linux avec des SSD.
Le 08/07/2018 à 14:34, Christophe PEREZ a écrit :
Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un
seul disque, ça vaut déjà le détour.
Le RAID 1 avec de disques durs pouvait déjà être plus rapide qu'un
disque seul pour les accès aléatoires en lecture, notamment grâce à la
parallélisation des temps d'accès. Mais la vitesse de lecture
séquentielle n'était pas améliorée pour des raisons liées à la mécanique
des disques (un disque met autant de temps à sauter un bloc qu'à le
lire). Pour améliorer le débit séquentiel en lecture, il fallait
utiliser l'agrégation en bandes comme en RAID 10 par exemple. Je n'ai
pas eu l'occasion de faire ou de voir des résultats de tests du RAID 1
de Linux avec des SSD.
Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
Le RAID 1 avec de disques durs pouvait déjà être plus rapide qu'un disque seul pour les accès aléatoires en lecture, notamment grâce à la parallélisation des temps d'accès. Mais la vitesse de lecture séquentielle n'était pas améliorée pour des raisons liées à la mécanique des disques (un disque met autant de temps à sauter un bloc qu'à le lire). Pour améliorer le débit séquentiel en lecture, il fallait utiliser l'agrégation en bandes comme en RAID 10 par exemple. Je n'ai pas eu l'occasion de faire ou de voir des résultats de tests du RAID 1 de Linux avec des SSD.
olivier B.
Le 08/07/2018 à 14:34, Christophe PEREZ a écrit :
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici : https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances. De plus, le titre "PC des particuliers", bien que je sois un particulier, me semble plus orienté PC desktop, donc pas tout à fait le même usage que le mien. Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le 08/07/2018 à 14:34, Christophe PEREZ a écrit :
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici :
https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances.
De plus, le titre "PC des particuliers", bien que je sois un particulier,
me semble plus orienté PC desktop, donc pas tout à fait le même usage que
le mien.
Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un
seul disque, ça vaut déjà le détour.
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le Sun, 08 Jul 2018 10:49:06 +0200, Yves Tabouret a écrit :
Pour la question 1 il y a un des éléments de réponse ici : https://is.gd/UtuZyn
Merci, mais ils n'y parlent que performances. De plus, le titre "PC des particuliers", bien que je sois un particulier, me semble plus orienté PC desktop, donc pas tout à fait le même usage que le mien. Ceci dit, apprendre que c'est plus rapide en lecture en raid 1 qu'avec un seul disque, ça vaut déjà le détour.
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Christophe PEREZ
Le Mon, 09 Jul 2018 10:32:21 +0000, olivier B. a écrit :
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le raid soft n'est pas transparent pour le contrôleur ?
Le Mon, 09 Jul 2018 10:32:21 +0000, olivier B. a écrit :
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le raid soft n'est pas transparent pour le contrôleur ?
Le Mon, 09 Jul 2018 10:32:21 +0000, olivier B. a écrit :
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le raid soft n'est pas transparent pour le contrôleur ?
Christophe PEREZ
Le Sun, 08 Jul 2018 15:15:54 +0200, Pascal Hambourg a écrit :
fdisk /dev/mdX Les partitions seront nommées /dev/mdXpY.
Effectivement. Les SSD sont en commandes. Je verrai tout ça dans 2 semaines.
Une difficulté peut apparaître lors de l'installation si l'outil de partitionnement de l'installateur ne permet pas de partitionner (créer une table de partition sur) un ensemble RAID. C'est le cas de partman, le partitionneur de l'installateur Debian. Il faut créer la table de partition par un autre moyen (le shell de l'installateur par exemple) et ensuite partman permet de créer des partitions.
Alors déjà, il n'est pas question ici d'installateur. La distrib gentoo est en place, et n'en bougera pas ;) Et l'outil sera sans doute un gparted des familles ou cfdisk auquel je suis le plus habitué.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut être utile pour récupérer une erreur ou faire les sauvegardes.
Oui ben voilà, les affinités ça ne se décrète pas. Déjà le raid avait été compliqué à accepter à l'époque. Et le raid hard était inacceptable ;)
Le Sun, 08 Jul 2018 15:15:54 +0200, Pascal Hambourg a écrit :
fdisk /dev/mdX Les partitions seront nommées /dev/mdXpY.
Effectivement.
Les SSD sont en commandes. Je verrai tout ça dans 2 semaines.
Une difficulté peut apparaître lors de l'installation si l'outil de
partitionnement de l'installateur ne permet pas de partitionner (créer
une table de partition sur) un ensemble RAID. C'est le cas de partman,
le partitionneur de l'installateur Debian. Il faut créer la table de
partition par un autre moyen (le shell de l'installateur par exemple) et
ensuite partman permet de créer des partitions.
Alors déjà, il n'est pas question ici d'installateur. La distrib gentoo
est en place, et n'en bougera pas ;)
Et l'outil sera sans doute un gparted des familles ou cfdisk auquel je
suis le plus habitué.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot.
De plus, en général, je compte assez large, et ne redimensionneme pas
mes partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut
être utile pour récupérer une erreur ou faire les sauvegardes.
Oui ben voilà, les affinités ça ne se décrète pas. Déjà le raid avait été
compliqué à accepter à l'époque. Et le raid hard était inacceptable ;)
Le Sun, 08 Jul 2018 15:15:54 +0200, Pascal Hambourg a écrit :
fdisk /dev/mdX Les partitions seront nommées /dev/mdXpY.
Effectivement. Les SSD sont en commandes. Je verrai tout ça dans 2 semaines.
Une difficulté peut apparaître lors de l'installation si l'outil de partitionnement de l'installateur ne permet pas de partitionner (créer une table de partition sur) un ensemble RAID. C'est le cas de partman, le partitionneur de l'installateur Debian. Il faut créer la table de partition par un autre moyen (le shell de l'installateur par exemple) et ensuite partman permet de créer des partitions.
Alors déjà, il n'est pas question ici d'installateur. La distrib gentoo est en place, et n'en bougera pas ;) Et l'outil sera sans doute un gparted des familles ou cfdisk auquel je suis le plus habitué.
Je n'ai jamais été attiré par LVM. Je sais, c'est sans doute idiot. De plus, en général, je compte assez large, et ne redimensionneme pas mes partitions.
LVM a d'autres avantages comme les "instantanés" (snapshots). Ça peut être utile pour récupérer une erreur ou faire les sauvegardes.
Oui ben voilà, les affinités ça ne se décrète pas. Déjà le raid avait été compliqué à accepter à l'époque. Et le raid hard était inacceptable ;)
olivier B.
Le 09/07/2018 à 15:40, Christophe PEREZ a écrit :
Le Mon, 09 Jul 2018 10:32:21 +0000, olivier B. a écrit :
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le raid soft n'est pas transparent pour le contrôleur ?
ben, c'est à dire que sur ce groupe normalement c'est plutôt matériel, on me l'a dit et répété, alors je porte la bonne parole ;-)
Le 09/07/2018 à 15:40, Christophe PEREZ a écrit :
Le Mon, 09 Jul 2018 10:32:21 +0000, olivier B. a écrit :
ça dépend du contrôleur, il peut aussi ne lire qu'un disque.
Le raid soft n'est pas transparent pour le contrôleur ?
ben, c'est à dire que sur ce groupe normalement c'est plutôt matériel,
on me l'a dit et répété, alors je porte la bonne parole ;-)
