logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 03-03-2019 07:02:00

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

[Résolu] Partitionnement entre SSD 32 Go et HDD

Bonjour,

Je cherche une bonne manière de partitionner un SSD de 32Go et un HDD de 500Go pour une installation de Debian 9 avec LXDE.
L'ordinateur portable a 8 Go de RAM, je voudrais faire une installation en single-boot, bien profiter des performances du SSD sans trop réduire sa durée de vie, et utiliser l'hibernation.
Mon usage sera minimal : j'utiliserai surtout Firefox (pas plus d'une douzaine d'onglets en même temps), LibreOffice, un client mail, et peut-être parfois Gimp.

Cette étape du partitionnement manuel me donne mal au crâne, il y a tellement de paramètres à déterminer, d'autant plus que les avis sont très partagés sur les forums (mais le pire, c'est que je suis perfectionniste!)
Ainsi, après de multiples recherches sur la question ainsi que des conseils avisés de raleur sur une autre discussion, j'ai plusieurs éléments à éclaircir pour comprendre et optimiser mes choix.
Je serais également curieux de savoir ce que vous feriez à ma place.


Voici une ébauche :

SSD :
partition 1 : /
partition 2 : swap de 9 Go
partition 3 : /home de (23-taille de la partition 1) Go

HDD :
partition 1 : /var de 5 Go
partition 2 : /home/data de 495 Go


Et voilà les questions que je me pose :

- swap : je pense qu'une taille de 9 Go est convenable (because "You need a swap partition that is larger than your DRAM to save all the DRAM content securely for hibernation.").
Est-ce une bonne idée de le mettre sur le SSD, pour l'usure? J'ai lu qu'il était aussi possible de le configurer comme fichier, qu'en pensez-vous?

- tmp : d'après raleur, l'utilisation de tmpfs est adaptée. Dois-je créer une partition séparée sur le SSD pour tmp afin de configurer tmpfs par la suite? Quelle taille est raisonnable?

- d'après ce que j'ai lu sur cette page, je pense « occuper tout l'espace [du SSD] avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option “discard”). » (dixit raleur) Mais « Cette valeur [=le seuil en question] de 50% est totalement arbitraire et exagérée » (idem)
Quel genre de seuil est raisonnable? Pour le TRIM, j'ai lu sur cette page qu'il était recommandé de remplacer l'option "discard" par l'usage de fstrim : qu'en pensez-vous? D'autre part, il est ensuite écrit que « l'option "discard" n'est pas nécessaire si le SSD a assez d'overprovisioning ». Mais comment savoir si c'est le cas?

- noatime/relatime, data=ordered/data=journal... je m'y perds, ces options sont-elles importantes pour chaque partition?

- quelle taille attribuer à la partition racine?

- quelle taille attribuer à /var, avec mon usage? (j'ai mis 5 Go de façon arbitraire) Faut-il remplir tout le reste du HDD avec la deuxième partition, ou y a-t-il un intérêt à laisser de l'espace libre?

- /home sur une partition séparée, c'est important en cas de défaillance de la partition racine, n'est-ce pas? qu'en est-il d'une partition /boot?

- tout cela sera en ext4, aucun problème?

- est-il important de définir les partitions selon un certain ordre sur le disque dur? et sur le SSD?


Si vous avez une idée concernant une ou plusieurs questions, je suis preneur!

merci.gif

Dernière modification par masa (12-03-2019 19:23:55)

Hors ligne

#2 03-03-2019 13:06:10

woinche
Membre
Lieu : rhone alpes
Distrib. : debian 9
Noyau : Linux 4.9.0-8-amd64
(G)UI : KDE
Inscription : 17-11-2018

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

bonjour,

- tmp : d'après raleur, l'utilisation de tmpfs est adaptée. Dois-je créer une partition séparée sur le SSD pour tmp afin de configurer tmpfs par la suite? Quelle taille est raisonnable?



oui tmpfs marche tres bien. sur mon laptop j'ai pulsieur partitions en RAM. a savoir quand mene que contraiment a un FS sur disque si tu as une erreur d'ecriture dans la RAM ton fichier est irrecuperable (là ou un disque dispose de solution de reconstrution). mais a ce jour je n'ai jamais eu de probleme, et tu n'aura pas de probleme si ta RAM est fiable.

si tu souhaite utilisé tmpfs alors ne crée pas partion dédié a /tmp, tu configura tmpfs apres l'installations de debian avec le fichier /etc/fstab. voici un exemple de symtaxe a declarer dans /etc/fstab


# /tmp en ram
tmpfs /tmp tmpfs mode=1777,nosuid,nodev 0 0
 



- d'après ce que j'ai lu sur cette page, je pense « occuper tout l'espace [du SSD] avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option “discard”). » (dixit raleur) Mais « Cette valeur [=le seuil en question] de 50% est totalement arbitraire et exagérée » (idem)
Quel genre de seuil est raisonnable? Pour TRIM, j'ai lu sur cette page qu'il était recommandé de remplacer l'option "discard" est par l'usage de fstrim : qu'en pensez-vous? D'autre part, il est ensuite écrit que « l'option "discard" n'est pas nécessaire si le SSD a assez d'overprovisioning ». Mais comment savoir si c'est le cas?



en seuil j'ai souvent entendu 20%, sans jamais vérifié plus que ça la véracité de l'info. dans tout les cas si ta partition / fait 32Go et que tu reste sur un usage "bureautique" tu n'aura, pas de souci d'espace libre.
encore une fois a titre de comparaison, sur mon laptop j'ai fait une partions de 32Go - or mon système consomme seulement 9Go (debian 9 + kde + tout un tas de logiciel). donc tu devrais avoir de quoi anticipé....

pour la différence entre "discard" et "fstrim". je ne sais pas, désolé.

- noatime/relatime, data=ordered/data=journal... je m'y perds, ces options sont-elles importantes pour chaque partition?



ces option sont des paramètres fourni au FS, elles sont utiles lorsque l'on cherche a faire quelque chose de precis/specifique (activer les ACL pour un partage samba, bloquer l’exécution de fichier sur un dossier ftp partager etc....). dans ton cadre d'utilisation PC / bureautique / surf etc.... tu n'a pas vraiment besoin de t'en préoccuper. tu es là sur des points de détails.

- quelle taille attribuer à la partition racine?



a toi de voir, comme dit plus haut 32Go est overkill. mais ca te permet de me pas être déranger si un jour tes besoins évolue et que tu as la nécessité de plus d'espaces.
de mémoire LXDE prend environ 5Go a l’installe. alors disons qu'il faut entre 10 et 30 Go pour la racine.

- quelle taille attribuer à /var, avec mon usage? (j'ai mis 5 Go de façon arbitraire) Faut-il remplir tout le reste du HDD avec la deuxième partition, ou y a-t-il un intérêt à laisser de l'espace libre?



tu veux faire une partition dedié sur le HDD pour économiser le SSD ? a ta place je laisserais le var dans la partions / sur le SSD. var contient certaine info qui me semble t'il on un intérêt a être lu rapidement.
5Go c'est bien. tu peux remplir ton HDD sans souci. il faut juste laisser de la place (20%) dans les partions afin d’éviter que ext4 fragnemte.

- /home sur une partition séparée, c'est important en cas de défaillance de la partition racine, n'est-ce pas? qu'en est-il d'une partition /boot?


oui, en quelque sorte, cela permet surtout de copier/cloner ton home plus facilement et aussi de pouvoir réinstaller le système sans toucher a ton /home. en effet la mène logique est applicable a /boot

- tout cela sera en ext4, aucun problème?



nickel, ext4 est le FS par défaut sous Debian. il est stable et bien connu. pour info tu peux documenter sur BTRFS qui propose un peu plus de fonctionnalité (snapshot notamment) si tu en voit l'utilité tu peux alors utilisé btrfs pour ton home. sinon ext4 de partout.

- est-il important de définir les partitions selon un certain ordre sur le disque dur? et sur le SSD?


mon et mon, tu peux avoir sd3 en / sd1 en boot et sd2 en swap si tu as envie. c'est certes moins intuitif et moins lisible pour l'homme, mais ça marche

Hors ligne

#3 03-03-2019 13:19:02

Frosch
Membre
Distrib. : FreeBSD
(G)UI : Xfce
Inscription : 09-12-2015

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Alors moi à ta place je mettrais:

SSD
1. /

Macintosh HD HDD
1. swap
2. /home

masa a écrit :

- swap : je pense qu'une taille de 9 Go est convenable (because "You need a swap partition that is larger than your DRAM to save all the DRAM content securely for hibernation.").

Je pense qu'en réalité il faut juste un tout petit peu plus que la RAM, moi j'ai laissé faire l'installateur debian pour choisir la taille de la swap, et il m'a créé une partition de 15,88GiB (ma RAM "16GB" faisant plus précisément 15,54GiB). Le truc un peu agaçant en la matière est l'utilisation aléatoire de GB (Go) ou GiB (Gio) selon le logiciel, par exemple les outils KDE ainsi que GParted donnent des valeurs en GiB, tandis que l'installateur debian veut des valeurs en GB... quoi qu'il en soit avec 9GB tu devrais être tranquille.

masa a écrit :

/home sur une partition séparée, c'est important en cas de défaillance de la partition racine, n'est-ce pas?

C'est surtout très pratique au cas où tu veux/dois réinstaller ton système, tu auras juste à écraser la partition racine existante et conserver /home, tes données n'auront rien à craindre (sauf fausse manipulation évidemment) et en prime tous tes fichiers de configuration seront conservés.

masa a écrit :

- tout cela sera en ext4, aucun problème?

Personnellement je préfère btrfs qui est plus moderne et a des fonctionnalités intéressantes, mais ext4 étant le standard, tu devrais pas avoir de souci à ce niveau-là. Toutefois j'ai lu qu'il valait mieux désactiver la journalisation d'ext4 quand utilisé sur un SSD pour le préserver de l'usure. À confirmer, jamais testé moi-même.

masa a écrit :

- est-il important de définir les partitions selon un certain ordre sur le disque dur? et sur le SSD?

Sans importance.

J'ai une configuration assez différente de la tienne, mais à titre d'illustration, mon partitionnement:

SSD 250GB
1.   /boot/efi   fat32   512MiB
2.   /   btrfs   222,10GiB
3.   swap   15,88GiB

HDD 500GB
1.   /HDD   btrfs   465,76GiB

Comme tu peux le constater je n'ai personnellement pas de /home séparé, en revanche j'ai créé un point de montage /HDD pour mon disque dur. La partition /boot/efi est quant à elle nécessaire dans le cas d'un PC qui utilise UEFI.

Dernière modification par Frosch (03-03-2019 13:21:30)

Hors ligne

#4 03-03-2019 14:33:04

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

masa a écrit :

SSD :
partition 1 : /
partition 2 : swap de 9 Go
partition 3 : /home de (32-taille de la partition 1) Go


Si tu mets le swap sur le SSD, il faut aussi retrancher sa taille.

masa a écrit :

"You need a swap partition that is larger than your DRAM to save all the DRAM content securely for hibernation."


Cette phrase est fausse. Ce n'est qu'un ordre de grandeur à moduler en fonction de l'utilisation réelle.
La quantité de swap nécessaire à l'hibernation peut être largement inférieure à la taille de la RAM si une part importante de celle-ci n'est pas occupée par des données qui doivent être sauvegardées. C'est le cas notamment de la mémoire libre (non utilisée) et de la mémoire utilisée pour les divers caches, qui peut occuper couramment plus de la moitié de la RAM. A l'inverse, un swap de la taille de la RAM n'est pas toujours suffisant : si le swap contient déjà des données swappées par manque de mémoire, l'espace disponible restant peut être insuffisant pour contenir toutes les données qui doivent être sauvegardées.

Comme toujours en la matière, il n'y a pas de réponse définitive et absolue.

masa a écrit :

Dois-je créer une partition séparée sur le SSD pour tmp afin de configurer tmpfs par la suite?


Non car cette partition serait inutilisée ensuite. Si tu as peur de laisser des fichiers dans le répertoire /tmp qui seront masqués par le montage du tmpfs, tu n'as pas à t'en faire car
- l'espace habituellement occupé dans /tmp est faible (à voir avec "du -hs /tmp" en root) ;
- il est possible d'accéder à ces fichiers pour les supprimer même avec le tmpfs monté sur /tmp, grâce à un montage de la racine en "bind".

Concernant la taille du tmpfs, tu peux laisser la taille par défaut (la moitié de la RAM), sachant qu'un tmpfs n'occupe réellement la mémoire qu'à hauteur de son remplissage. D'autre part sa taille peut être modifiée à chaud en le remontant avec les options remount,size=xxx.

masa a écrit :

je pense « occuper tout l'espace [du SSD] avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM


Tu comptes donc faire de l'overprovisioning (en plus de celui fait en interne par le SSD) de cette façon, ce qui permet au système de fichiers de mieux "respirer', plutôt qu'en laissant une zone non partitionnée. Vérifie avant que le SSD supporte effectivement le TRIM avec

hdparm -I /dev/sdX


masa a écrit :

Pour TRIM, j'ai lu sur cette page qu'il était recommandé de remplacer l'option "discard" est par l'usage de fstrim : qu'en pensez-vous?


Dans un monde parfait, le TRIM "en ligne" réalisé par l'option discard serait la méthode la plus simple pour utiliser le TRIM. Mais dans la réalité, il y a quelques arguments en sa défaveur.

- Il existe deux variantes de commande TRIM : la première est "bloquante", ce qui empêche de l'utiliser en même temps que des commandes de lecture ou d'écriture.On doit donc arrêter d'envoyer des commandes de lecture/écriture, attendre qu'elles se terminent, envoyer la commande TRIM et attendre qu'elle se termine avant de recommencer à envoyer des commandes de lecture/écriture. Cela affecte les performances en lecture/écriture. La seconde variante (queued TRIM) n'est pas bloquante et peut être utilisée en même temps que les commandes de lecture/écriture, mais (ce serait trop beau, il y a toujours un mais) elle n'est pas forcément supportée par tous les SSD et notamment les plus anciens, et sur certains modèles elle est buggée et peut provoquer des pertes de données donc son usage par le noyau est désactivé avec les modèles de SSD identifiés.

- En théorie le TRIM ne fait que marquer les secteurs ne contenant plus de données utiles et ne déclenche pas forcément d'action immédiate du SSD pour effacer ces secteurs (car on ne peut réécrire dans une cellule de mémoire flash qu'après l'avoir effacée). Cette information devrait servir lors de la prochaine exécution du "garbage collector" pour effacer les données inutiles, idéalement déclenchée à un moment où le SSD est peu sollicité. Malheureusement, certains SSD peuvent avoir tendance à déclencher immédiatement le garbage collector suite à une commande TRIM, ce qui affecte négativement les performances et la durée de vie du SSD.

C'est pourquoi l'application d'un TRIM "hors ligne" avec la commande fstrim à un moment choisi de faible activité est plutôt recommandé actuellement.

masa a écrit :

D'autre part, il est ensuite écrit que « l'option "discard" n'est pas nécessaire si le SSD a assez d'overprovisioning ».


Je ne suis pas d'accord avec cette affirmation. Quel que soit l'overprovisioning, le TRIM est toujours utile pour éviter de recopier des données obsolètes lors du garbage collector (amplification d'écriture) et moins il y a d'écritures, moins on use la mémoire flash.

masa a écrit :

noatime/relatime, data=ordered/data=journal... je m'y perds, ces options sont-elles importantes pour chaque partition?


Si tu t'y perds, laisse les options par défaut. noatime provoque un peu moins d'écritures que relatime (option par défaut), mais perturbe le fonctionnement de quelques logiciels qui utilisent la date d'accès comme mutt (lecteur de courriel) pour déterminer si un courriel a été lu.

masa a écrit :

quelle taille attribuer à...


Quand je suis face à cette question, je distingue selon deux cas :
- Si l'espace disque n'est pas contraint (cas du disque dur de 1 To), alors je compte très large.
- Si l'espace disque est contraint (cas du SSD de 32 Go), j'utilise LVM et je crée des volumes logique avec des tailles initiales minimum pour l'installation que je j'augmenterai au fur et à mesure de leur remplissage.

Comme tu as choisi de séparer /home de la racine sur le SSD en situation d'espace contraint, il est important de ne pas te retrouver en manque d'espace sur l'une ou l'autre.

masa a écrit :

Faut-il remplir tout le reste du HDD avec la deuxième partition, ou y a-t-il un intérêt à laisser de l'espace libre?


A toi de voir si tu comptes créer d'autres partitions. Note qu'avec LVM, tu n'as pas besoin de te poser cette question.

masa a écrit :

/home sur une partition séparée, c'est important en cas de défaillance de la partition racine, n'est-ce pas?


Disons que cela facilite la maintenance (sauvegarde/restauration, réinstallation).

masa a écrit :

qu'en est-il d'une partition /boot?


Utile (mais pas indispensable) si la racine est un volume logique LVM. Inutile si la racine est une partition classique.

masa a écrit :

tout cela sera en ext4, aucun problème?


Oui, ext4 est le type de système de fichiers généraliste à utiliser par défaut si on n'a pas de bonne raison d'en utiliser un autre. Il supporte le TRIM.

masa a écrit :

est-il important de définir les partitions selon un certain ordre sur le disque dur? et sur le SSD?


Sur le SSD, non. Sur le disque dur, l'ordre peut affecter les performances dans une certaines mesure (mais rien de renversant) sachant que :
- le débit séquentiel est le plus élevé au début du disque (il y a approximativement un facteur 2 entre le début et la fin) ;
- le temps d'accès augmente un peu (facteur 1,5 à 2) avec l'éloignement des données. Donc si on a une grande partition peu remplie et qui se remplit par le début suivie d'une autre partition, ce n'est pas l'idéal. Il vaut mieux mettre la partition la plus petite et la plus utilisée (/var) au début.


Il vaut mieux montrer que raconter.

Hors ligne

#5 03-03-2019 16:31:11

anonyme
Invité

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Bonjour
j'ai regardé cette commande hdparm -I /dev/sdX

j'ai un retour pour le ssd comme ceci


* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
 



je sais pas comment debian supporte les ssd , mais le controleur du ssd doit gérer les cellules (matériel récent)
exact ou pas ?
il existe aussi des fonctions de remise a zéro du ssd (pour repartir avec quelque chose de presque neuf ). bios ou logiciel je sais plus et pas trop confiance roll
dans son cas mSATA de 2013 je sais pas.
je suis pas pour utiliser un logiciel pour entretenir le ssd , dans mon esprit le controleur du ssd fait son job (pour l'instant avec 50 a 75% d'utilisation max du ssd pas de soucis )
garder a l'esprit que le mSATA ne fait pas 32GO , formaté et avec les partitions il fera moins (29 GO peut être moins )
avec le swap de 8GO il reste 21GO , si il garde 5Go de libre , il reste 16Go pour debian
largement suffisant si il met ses données sur le DD
ne pas lancer une compilation du noyau par exemple sur le ssd  qui peu prendre plusieurs  giga

je sais pas si avec smartctl - on peu voir si des cellules HS
mon ssd M2


=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron MX1/2/300, M5/600, 1100 Client SSDs
Device Model:     Crucial_CT275MX300SSD4
Serial Number:    172717D06377
LU WWN Device Id: 5 00a075 117d06377
Firmware Version: M0CR040
User Capacity:    275064201216 bytes [275 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      < 1.8 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Mar  3 16:19:24 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
 



SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   000    Pre-fail  Always       -       0
  5 Reallocate_NAND_Blk_Cnt 0x0032   100   100   010    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       7376
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       333
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 Ave_Block-Erase_Count   0x0032   100   100   000    Old_age   Always       -       12
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       57
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always       -       0
184 Error_Correction_Count  0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   061   029   000    Old_age   Always       -       39 (Min/Max 18/71)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
202 Percent_Lifetime_Used   0x0030   100   100   001    Old_age   Offline      -       0
206 Write_Error_Rate        0x000e   100   100   000    Old_age   Always       -       0
246 Total_Host_Sector_Write 0x0032   100   100   000    Old_age   Always       -       2685792822
247 Host_Program_Page_Count 0x0032   100   100   000    Old_age   Always       -       83931457
248 Bckgnd_Program_Page_Cnt 0x0032   100   100   000    Old_age   Always       -       50298121
180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       1256
210 Success_RAIN_Recov_Cnt  0x0032   100   100   000    Old_age   Always       -       0
 



je fais pas mal de compilation de noyau , ça reste faible par rapport a ce que peu supporter le ssd
il pourra lancer une commande "smartctl -a /dev/sdx" pour vérification .

#6 04-03-2019 02:15:19

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Edit : pardon message envoyé trop tôt par erreur! en cours d'écriture...
Edit2 : j'étais en train de finir ma réponse (je mets bcp de temps car je fais des recherches en même temps) et bim, j'ai tout perdu avec un pomme+Q (=quitter l'app) qui a remplacé le pomme+W habituel... plus qu'à tout réécrire... neutral neutral je remets ça à demain

je voulais quand même vous dire un grand merci à tous les quatre pour vos réponses si complètes!

Dernière modification par masa (04-03-2019 04:22:19)

Hors ligne

#7 04-03-2019 10:59:51

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Frosch a écrit :

j'ai lu qu'il valait mieux désactiver la journalisation d'ext4 quand utilisé sur un SSD pour le préserver de l'usure


Mais la journalisation réduit le risque de corruption du système de fichiers et la nécessité d'exécuter fsck en mode rescue après un arrêt "sale" (plantage, reboot ou arrêt forcé).

anonyme a écrit :

je sais pas comment debian supporte les ssd , mais le controleur du ssd doit gérer les cellules


Qu'entends-tu par "gérer les cellules" ? Tu veux dire l'usure des cellules ?

anonyme a écrit :

je suis pas pour utiliser un logiciel pour entretenir le ssd


Qu'entends-tu par "entretenir", et à quel genre de logiciel fais-tu allusion ?

anonyme a écrit :

le mSATA ne fait pas 32GO , formaté et avec les partitions il fera moins (29 GO peut être moins)


Si, ce SSD a une capacité utile de 32 Go (soit 29,8 Gio). Cf. les sorties de fdisk et de dmesg dans la discussion originelle.
Le partitionnement et le formatage ne réduisent pas significativement la capacité utile. Cette fausse impression peut provenir de l'écart entre la capacité du disque exprimée par le fabricant en Go décimaux et la taille de la partition ou du système de fichiers affichée en Gio binaires par le système d'exploition (1 Gio = 1,07 Go), ou de la soustraction des 5% réservés par défaut dans le calcul de l'espace libre.

anonyme a écrit :

je sais pas si avec smartctl - on peu voir si des cellules HS


On digresse du sujet, mais c'est intéressant.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
   5 Reallocate_NAND_Blk_Cnt 0x0032   100   100   010    Old_age   Always       -       0


Aucun bloc défectueux réalloué.

 171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
 172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0


Aucune erreur d'écriture ou d'effacement.

 196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0


Aucun événement de réallocation (cohérent avec l'attribut n° 5).

 197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
 198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0


Aucun secteur illisible détecté lors d'un accès en ligne ou de l'auto-test hors ligne.

 202 Percent_Lifetime_Used   0x0030   100   100   001    Old_age   Offline      -       0


L'usure estimée est inférieure à 1%.

 246 Total_Host_Sector_Write 0x0032   100   100   000    Old_age   Always       -       2685792822


Avec une capacité utile de 537234768 secteurs, cela correspond à 2685792822/537234768 = 5 écritures par secteur. Compte tenu du nombre moyen de cycles d'écriture/effacement supporté par une cellule de mémoire flash (1000 pour de la TLC), c'est normal que l'usure estimée soit inférieure à 1%.

 247 Host_Program_Page_Count 0x0032   100   100   000    Old_age   Always       -       83931457


Il s'agit du nombre d'écritures de pages directement demandées par le système hôte. On peut en déduire que la taille d'une page d'écriture est égale à 2685792822/83931457 = 32 secteurs. Cette valeur est importante pour l'alignement des partitions et des données. L'alignement standard est de 2048 secteurs qui est un multiple de 32 donc c'est bon.

 248 Bckgnd_Program_Page_Cnt 0x0032   100   100   000    Old_age   Always       -       50298121


A priori il s'agit du nombre d'écritures de pages effectuées en tâche de fond par le contrôleur intégré du SSD, no directement demandées par le système hôte mais liées par exemple aux opérations de maintenance interne comme le garbage collector ou le nivellement de l'usure. Il s'avère que ce n'est pas négligeable du tout puisque cela représente un surcroît de 60% par rapport aux écritures demandées par l'hôte. L'utilisation du TRIM permet typiquement de réduire ce surcroît en évitant la réécriture de données périmées en tâche de fond.

 180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       1256


A priori c'est le nombre de blocs de mémoire flash (bloc d'effacement qui regroupe un certain nombre de pages d'écriture ?) de réserve disponibles pour la réallocation des blocs défectueux.


Il vaut mieux montrer que raconter.

Hors ligne

#8 04-03-2019 11:45:58

anonyme
Invité

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Bonjour

Qu'entends-tu par "entretenir", et à quel genre de logiciel fais-tu allusion ?



par exemple pour Crucial => https://communaute.crucial.com/t5/FAQ-S … ta-p/12350
le but et de mettre le ssd dans l'état initial (neuf) , bon l'usure des cellules sera toujours présentes mais toutes seront vide.

sinon dans le bios il y a une option pour réinitialisé un ssd (asus ou intel et ne doit fonctionner que avec un ssd de la marque il me semble)
il faut que je retrouve l'information , sûrement sur des cartes mères haut de gamme

je n'ai utilisé qu une fois ce logiciel pour un ssd crucial (mise a jour du firmware ) et n'est disponible que pour windows. roll
la panne était lors d une coupure de courant , le disque n'est plus détecté par l'OS au démarrage suivant.
cela a résolu le problème.

sinon le cryptage et l' effacement complet jamais utilisé.


/fin du hors sujet smile
pour les retours que tu a donné sur l'état de mon ssd , ça peu l'aider a connaître l'état de son ssd avec "smartctl -a /dev/sdx"
remarque: en fonction de la marque , du type de ssd et de la version de smartmontools (pour moi 6.6-1) le retour peu être différent roll

/hors sujet début


Secure Erase
La vitesse de lecture/écriture d'un lecteur SSD peut se dégrader au fil du temps comme tout
support de stockage en raison du traitement des données. Secure Erase permet de nettoyer
totalement et en toute sécurité votre SSD pour le restaurer dans un état de performance
comparable à sa sortie d'usine.
Secure Erase est uniquement disponible en mode AHCI. Veillez à régler le mode de
fonctionnement SATA sur AHCI. Cliquez sur
Advanced
 (Avancé) >
PCH Storage
Configuration
 (Configuration de stockage de la puce PCH) >
SATA Mode Selection
(Sélection de mode SATA) >
AHCI
.
Pour exécuter Secure Erase, cliquez sur
Tool
 (Outils) >
Secure Erase
 à partir de l'interface de
configuration avancée du BIOS.
Visitez le site internet d'ASUS pour consulter la liste des lecteurs SSD pleinement
compatibles avec la fonctionnalité Secure Erase. Le lecteur SSD peut devenir instable si
celui-ci est incompatible avec Secure Erase.
•     Le délai de nettoyage du lecteur SSD peut varier en fonction de sa taille. N'éteignez pas
votre ordinateur lors de l'exécution de Secure Erase.
•    Secure Erase n'est pris en charge que par les connecteurs SATA gérés par le
contrôleur Intel. Pour de plus amples informations sur les ports SATA Intel, consultez la
section
1.1.2 Schéma de la carte mère
 de ce manuel

Explication des états :

  Frozen (Gelé).
 L'état Frozen (Gelé) est le résultat d'une mesure de protection
appliquée par le BIOS. Le BIOS protège les lecteurs ne disposant pas de protection
par mot de passe en les gelant avant de démarrer le système. Si votre lecteur est gelé,
l'extinction ou une réinitialisation de l'ordinateur doit être effectuée avant de pouvoir
utiliser la fonctionnalité Secure Erase.

  Locked (Verrouillé).
 L'état Locked (Verrouillé) indique que le SSD a été verrouillé
suite à un processus Secure Erase incomplet ou arrêté. Ceci peut être le résultat d'un
logiciel tiers bloquant l'accès au SSD. Vous devez dans ce cas déverrouiller le SSD
dans le logiciel avant de pouvoir continuer à utiliser Secure Erase.
 



pris sur la documentation de la carte mère X370-A intel (modifié)


•    Secure Erase n'est pris en charge que par les connecteurs SATA gérés par le
contrôleur Intel.
 


ps: pas trop confiance hmm
/fin du hors sujet

tous les constructeurs vont le proposer je pense  (de ssd ou de carte mère )
pour quelqu'un qui se retrouve avec un ssd plein ou très lent ça vaut peu être le coup

Asus fait la même chose pour amd (X399-A)


secure Erase n'est pris en charge que par les connecteurs SATA gérés par le
contrôleur AMD.
 

Dernière modification par anonyme (04-03-2019 12:16:27)

#9 04-03-2019 15:33:51

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Pour moi, "entretenir" consiste en des opérations habituelles pour maintenir le SSD en état de fonctionnement. Je ne classe pas l'effacement sécurisé ni la mise à jour du firmware dans cette catégorie.

Il vaut mieux montrer que raconter.

Hors ligne

#10 06-03-2019 06:19:08

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

bonjour à tous! merci encore pour vos explications! big_smile

woinche a écrit :

var contient certaine info qui me semble t'il on un intérêt a être lu rapidement.


Aurais-tu une idée de la nature des infos auxquelles tu penses?

woinche a écrit :

5Go c'est bien. tu peux remplir ton HDD sans souci.


HDD? tu voulais dire SSD?

Frosch a écrit :

SSD
1. /

Macintosh HD HDD
1. swap
2. /home


En effet, j'utilise Mac actuellement, mais là c'est pour remplacer Windows que je voudrais installer Debian! tongue
Le swap et le /home sur le HDD, c'est en raison de l'usure? Qu'est-ce qui t'a motivé à les mettre sur le SSD dans ta configuration?

raleur a écrit :

Si tu mets le swap sur le SSD, il faut aussi retrancher sa taille.


Oui, effectivement, oubli corrigé!

hdparm -I /dev/sdb



/dev/sdb:

ATA device, with non-removable media
  Model Number:       SAMSUNG MZMPC032HBCD-000L1              
  Serial Number:      S0Y2NEAD702380      
  Firmware Revision:  CXM13L1Q
  Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
  Used: unknown (minor revision code 0x0039)
  Supported: 8 7 6 5
  Likely used: 8
Configuration:
  Logical   max current
  cylinders 16383 16383
  heads   16  16
  sectors/track 63  63
  --
  CHS current addressable sectors:    16514064
  LBA    user addressable sectors:    62533296
  LBA48  user addressable sectors:    62533296
  Logical  Sector size:                   512 bytes
  Physical Sector size:                   512 bytes
  device size with M = 1024*1024:       30533 MBytes
  device size with M = 1000*1000:       32017 MBytes (32 GB)
  cache/buffer size  = unknown
  Nominal Media Rotation Rate: Solid State Device
Capabilities:
  LBA, IORDY(can be disabled)
  Queue depth: 32
  Standby timer values: spec'd by Standard, no device specific minimum
  R/W multiple sector transfer: Max = 16  Current = 16
  DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
       Cycle time: min=120ns recommended=120ns
  PIO: pio0 pio1 pio2 pio3 pio4
       Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
  Enabled Supported:
     *  SMART feature set
        Security Mode feature set
     *  Power Management feature set
     *  Write cache
     *  Look-ahead
     *  Host Protected Area feature set
     *  WRITE_BUFFER command
     *  READ_BUFFER command
     *  DOWNLOAD_MICROCODE
        SET_MAX security extension
     *  48-bit Address feature set
     *  Device Configuration Overlay feature set
     *  Mandatory FLUSH_CACHE
     *  FLUSH_CACHE_EXT
     *  SMART error logging
     *  SMART self-test
     *  General Purpose Logging feature set
     *  WRITE_{DMA|MULTIPLE}_FUA_EXT
     *  WRITE_UNCORRECTABLE_EXT command
     *  {READ,WRITE}_DMA_EXT_GPL commands
     *  Gen1 signaling speed (1.5Gb/s)
     *  Gen2 signaling speed (3.0Gb/s)
     *  Gen3 signaling speed (6.0Gb/s)
     *  Native Command Queueing (NCQ)
     *  Host-initiated interface power management
     *  Phy event counters
     *  DMA Setup Auto-Activate optimization
        Device-initiated interface power management
     *  Software settings preservation
     *  SET MAX SETPASSWORD/UNLOCK DMA commands
     *  WRITE BUFFER DMA command
     *  READ BUFFER DMA command
     *  Data Set Management TRIM supported (limit 8 blocks)
Security:
  Master password revision code = 65534
    supported
  not enabled
  not locked
  not frozen
  not expired: security count
    supported: enhanced erase
  6min for SECURITY ERASE UNIT. 32min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct
 


Le TRIM est supporté, n'est-ce pas?

raleur a écrit :

l'application d'un TRIM "hors ligne" avec la commande fstrim à un moment choisi de faible activité


Je pense l'activer de façon hebdomadaire. Est-ce à moi de choisir ce moment?
Autre question peut-être un peu naïve : l'opération peut-elle se lancer lorsque le système est éteint, ou en hibernation?

raleur a écrit :

Si l'espace disque est contraint (cas du SSD de 32 Go), j'utilise LVM et je crée des volumes logique avec des tailles initiales minimum pour l'installation que je j'augmenterai au fur et à mesure de leur remplissage. [...]
Note qu'avec LVM, tu n'as pas besoin de te poser cette question.


Cela m'a surpris car j'en étais resté là :

raleur a écrit :

Un groupe de volumes LVM peut s'étendre sur plusieurs disques mais en principe on laisse LVM s'occuper de l'allocation de l'espace pour les volumes logiques, mais en contrepartie on ne maîtrise pas où est physiquement situé l'espace disque alloué donc ça n'a pas de sens entre un SSD et un disque dur qui ont des caractéristiques très différentes.


J'en avais conclu, sans doute trop rapidement, que l'utilisation de LVM de manière globale n'avait pas de sens. En réalité, l'utilisation d'un groupe de volumes LVM étendu sur ces deux plateformes de stockage n'a pas de sens, mais celle de deux groupes de volumes LVM distincts, l'un sur le HDD et l'autre sur le SSD, elle, a un sens, n'est-ce pas?
Si c'est le cas, je pense effectivement que LVM est une bonne solution. Me vient alors une interrogation :

raleur a écrit :

j'utilise LVM et je crée des volumes logique avec des tailles initiales minimum

...il reste donc de l'espace libre sur la plateforme de stockage, pas vrai?
Si oui, cet espace est-il occupé par le système de fichiers?

anonyme a écrit :

ne pas lancer une compilation du noyau par exemple sur le ssd


Une compilation du noyau, c'est pour le remplacer, ou le mettre à jour, n'est-ce pas? Dans quelles circonstances aurai-je besoin de faire cela?

anonyme a écrit :

il pourra lancer une commande "smartctl -a /dev/sdx" pour vérification


...si vous avez le courage de déchiffrer tout ça, voilà le retour de la commande! tongue

smartctl -a /dev/sdb


smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-8-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SAMSUNG MZMPC032HBCD-000L1
Serial Number:    S0Y2NEAD702380
Firmware Version: CXM13L1Q
User Capacity:    32,017,047,552 bytes [32.0 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Mar  6 03:16:49 2019 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x02) Offline data collection activity
          was completed without error.
          Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
          without error or no self-test has ever
          been run.
Total time to complete Offline
data collection:    (  180) seconds.
Offline data collection
capabilities:        (0x5b) SMART execute Offline immediate.
          Auto Offline data collection on/off support.
          Suspend Offline collection upon new
          command.
          Offline surface scan supported.
          Self-test supported.
          No Conveyance Self-test supported.
          Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
          power-saving mode.
          Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
          General Purpose Logging supported.
Short self-test routine
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    (   3) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1532
 12 Power_Cycle_Count       0x0032   096   096   000    Old_age   Always       -       3856
175 Program_Fail_Count_Chip 0x0032   100   100   010    Old_age   Always       -       0
176 Erase_Fail_Count_Chip   0x0032   100   100   010    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0013   090   090   017    Pre-fail  Always       -       361
178 Used_Rsvd_Blk_Cnt_Chip  0x0013   095   095   010    Pre-fail  Always       -       18
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   096   096   010    Pre-fail  Always       -       26
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013   096   096   010    Pre-fail  Always       -       790
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   057   042   000    Old_age   Always       -       43
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   253   253   000    Old_age   Always       -       0
233 Media_Wearout_Indicator 0x003a   198   198   000    Old_age   Always       -       169
234 Unknown_Attribute       0x0012   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       32
236 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       250
237 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       361
238 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       26

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

 

Dernière modification par masa (06-03-2019 06:22:00)

Hors ligne

#11 06-03-2019 09:25:28

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Bonjour

.il reste donc de l'espace libre sur la plateforme de stockage, pas vrai?
Si oui, cet espace est-il occupé par le système de fichiers?


non l'espaces est en attente et ne contient pas de systéme de fichier

Perso c'est la première fois que je me suis laissé tenté par LVM sur ce PC c'est que du bonheur
Sur mon installation 7Go pour la racine, 4 le SWAP et 20 le home
L'agrandissement (au cas ou) se fait a chaud avec 2 commandes lvextend pour agrandir le volume logique et resize2fs pour étendre le systéme de fichier a cette nouvelle taille
le tout à chaud sans démonter la partition
Je pense que tu devrais inclure le home sur le SSD et créer des liens symbolique vers ton disque dur pour les données volumineuse car il y a des fichiers de ton profil qui mérite d’être chargé rapidement


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#12 06-03-2019 11:39:41

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Croutons a écrit :

non l'espaces est en attente et ne contient pas de systéme de fichier


Dans ce cas, y a-t-il besoin d'utiliser la fonction TRIM? Je me réfère à cette page où raleur spécifie pour la deuxième façon d'utiliser le TRIM mais pas pour la première :

raleur a écrit :

Il y a deux façons :

1. ne pas occuper tout l'espace avec le système de fichiers ;
2. occuper tout l'espace avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option “discard” pour marquer les blocs des fichiers effacés).



Merci pour les commandes, et pour les tailles de ton installation, cela me donne un ordre d'idée pour les adapter à la mienne.

Croutons a écrit :

créer des liens symbolique vers ton disque dur pour les données volumineuse


Quel est l'avantage des liens symboliques par rapport à un dossier /home/data par exemple, sur lequel est montée une partition du disque dur?

Croutons a écrit :

il y a des fichiers de ton profil qui mérite d’être chargé rapidement


À quels fichiers fais-tu référence? Dans quel(s) dossier(s) se trouvent-ils?

Dernière modification par masa (06-03-2019 11:43:03)

Hors ligne

#13 06-03-2019 14:44:18

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Quel est l'avantage des liens symboliques par rapport à un dossier /home/data par exemple, sur lequel est montée une partition du disque dur?


l'avantage c'est que tu as la vitesse du SSD pour ton home
et par Exemple pour le sous répertoire vidéos il pourrait pointer vers ton HDD de manière transparente sans avoir a recréer un dossier nommé data


À quels fichiers fais-tu référence? Dans quel(s) dossier(s) se trouvent-ils?


je pense au dossier caché dans ton home comme .config et d'autre que je n'ai plus en tête

raleur a écrit :

Ne pas utiliser une partie de la capacité d'un SSD contribue aussi à augmenter le stock de blocs vierges. Il y a deux façons :

  1  ne pas occuper tout l'espace avec le système de fichiers ;
2   occuper tout l'espace avec le système de fichiers mais ne pas remplir le système de fichiers au delà d'un certain seuil (à condition d'utiliser la fonction TRIM avec l'option “discard” pour marquer les blocs des fichiers effacés).

La seconde option a un avantage : un système de fichiers fonctionne également mieux lorsqu'il a beaucoup d'espace libre, cela lui permet d'optimiser l'allocation des blocs. Ainsi il va pouvoir allouer un grand nombre de blocs consécutifs à chaque fichier au lieu de chercher à “remplir les trous”.


peut être ne faudrait il pas utiliser LVM sur le SSD du coup?


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#14 06-03-2019 15:31:06

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

masa a écrit :

Le TRIM est supporté, n'est-ce pas?


Oui :

Data Set Management TRIM supported (limit 8 blocks)



masa a écrit :

Je pense l'activer de façon hebdomadaire. Est-ce à moi de choisir ce moment?


L'exécution périodique de fstrim repose sur un "timer" systemd. Il faut voir s'il est paramétrable.

masa a écrit :

l'opération peut-elle se lancer lorsque le système est éteint, ou en hibernation?


Non, le système doit être opérationnel.

masa a écrit :

En réalité, l'utilisation d'un groupe de volumes LVM étendu sur ces deux plateformes de stockage n'a pas de sens, mais celle de deux groupes de volumes LVM distincts, l'un sur le HDD et l'autre sur le SSD, elle, a un sens, n'est-ce pas?


C'est mon point de vue.

masa a écrit :

il reste donc de l'espace libre sur la plateforme de stockage, pas vrai?
Si oui, cet espace est-il occupé par le système de fichiers?



Avec LVM il y a trois niveaux d'allocation de l'espace de stockage :
- l'espace dans un disque, disponible pour les partitions
- l'espace dans un groupe de volumes LVM (alloué aux partitions servant de volume physique), disponible pour les volumes logiques
- l'espace dans un système de fichiers (alloué à un volume logique), disponible pour les fichiers.

Si par exemple un disque de 500 Go est organisé de la façon suivante :
- une partition de 300 Go contenant le volume physique LVM d'un groupe de volumes de la même taille
- un volume logique LVM de 250 Go dans le groupe de volumes contenant un système de fichiers de la même taille
- 100 Go de fichiers dans le système de fichiers

L'espace libre sur le disque, disponible pour les partitions, est de 500 - 300 = 200 Go.
L'espace libre dans le groupe de volumes, disponible pour les volumes logiques, est de 300 - 250 = 50 Go.
L'espace libre dans le système de fichiers du volume logique, disponible pour les fichiers, est de 250 - 100 = 150 Go.

Si on alloue tout l'espace disque aux partitions et tout l'espace du groupe de volumes aux volumes logiques (comme le fait l'installateur en mode assisté avec LVM), tout l'espace libre est dans les systèmes de fichiers. Le problème se pose quand un système de fichiers se remplit et qu'on veut l'agrandir : il faut d'abord agrandir son volume logique. Mais comme tout l'espace du groupe de volumes est occupé, il faut d'abord réduire un autre volume logique. Mais pour cela il faut d'abord réduire le système de fichiers qu'il contient. Or il n'est pas toujours simple voire possible de réduire un système de fichiers. Par exemple :

- Un système de fichiers ext4 peut être agrandi "à chaud" (monté) mais ne peut être réduit qu'à froid (démonté).
- Un système de fichiers xfs peut être agrandi à chaud mais pas réduit, même à froid.
- Un système de fichiers btrfs peut être agrandi et réduit à chaud.

Si on utilise ext4, il faut démonter le système de fichiers. Faisable, au pire via un système live, mais pas pratique. Il vaut mieux laisser de l'espace libre dans un des deux autres niveaux : groupe de volumes ou disque.

Si on est sûr de ne jamais vouloir installer d'autre système d'exploitation ne supportant pas LVM en parallèle, on peut allouer tout l'espace disque disponible au volume physique LVM. Ainsi l'espace libre sera dans le groupe de volumes et on pourra l'utiliser pour agrandir les volumes logiques à chaud ou en créer de nouveaux.

Dans le cas contraire, on peut laisser de l'espace disque non alloué pour créer de nouvelles partitions. Si nécessaire, on pourra créer une partition et l'utiliser comme volume physique supplémentaire pour agrandir le groupe de volumes.

masa a écrit :

si vous avez le courage de déchiffrer tout ça


Ce SSD semble en bon état. Aucune erreur d'écriture ou effacement. Le taux d'utilisation des blocs de réserve est environ 5%. L'indicateur d'usure est difficile à interpréter dans la mesure où on ne connaît pas la valeur initiale (200 ou 255).

masa a écrit :

Dans ce cas, y a-t-il besoin d'utiliser la fonction TRIM? Je me réfère à cette page où raleur spécifie pour la deuxième façon d'utiliser le TRIM mais pas pour la première :


L'objectif de cet espace libre est différent. Dans le cas 1 que j'exposais précédemment, cet espace non alloué ou dans une partition non utilisée était réservé à l'overprovisioning, alors qu'ici il sert de réserve pour un usage futur.

masa a écrit :

Quel est l'avantage des liens symboliques par rapport à un dossier /home/data par exemple, sur lequel est montée une partition du disque dur?


Les deux fonctionnent ensemble. Le système de fichiers est monté sur /home/data et /home/$USER contient un ou plusieurs liens symboliques qui pointent vers /home/data ou des sous-répertoires.

masa a écrit :

À quels fichiers fais-tu référence? Dans quel(s) dossier(s) se trouvent-ils?


Tous les fichiers et répertoires de configuration et d'état situés dans /home/$USER et dont le nom commence généralement par un point.

Croutons a écrit :

raleur a écrit :

un système de fichiers fonctionne également mieux lorsqu'il a beaucoup d'espace libre, cela lui permet d'optimiser l'allocation des blocs. Ainsi il va pouvoir allouer un grand nombre de blocs consécutifs à chaque fichier au lieu de chercher à “remplir les trous”.


peut être ne faudrait il pas utiliser LVM sur le SSD du coup?


Non, il suffit de ne pas laisser l'espace libre dans un système de fichiers descendre en dessous de 10-20 %, et de l'agrandir quand ce seuil est franchi.


Il vaut mieux montrer que raconter.

Hors ligne

#15 06-03-2019 17:05:52

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

j'ai fais mon installation avec l'installateur LVM assisté , il y a la possibilité de choisir la taille des volumes
dans mon souvenir il me semble que par défaut l'installateur avait défini les volumes logique suivant l'espace disponible dans le VG mais j'ai pu y revenir pour changer la taille des VL avant de valider

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#16 06-03-2019 22:03:56

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Pourrais-tu retrouver la procédure ? Je n'ai jamais vu la possibilité de redimensionner un volume logique LVM dans l'installateur Debian, que ce soit en partitionnement assisté ou en manuel. Je viens de revérifier à l'instant.

Il vaut mieux montrer que raconter.

Hors ligne

#17 06-03-2019 23:37:41

Frosch
Membre
Distrib. : FreeBSD
(G)UI : Xfce
Inscription : 09-12-2015

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

masa a écrit :

Le swap et le /home sur le HDD, c'est en raison de l'usure? Qu'est-ce qui t'a motivé à les mettre sur le SSD dans ta configuration?


Ma proposition était plus une question de place, vu que tu as un petit SSD, autant ne pas l'encombrer avec des choses inutiles comme le swap. Pour /home c'est vrai que c'est discutable, si ça te gêne pas d'avoir une partition /home petite alors effectivement tu peux la mettre sur le SSD. Sinon tu peux aussi faire comme moi et ne pas faire de /home séparé.

Hors ligne

#18 07-03-2019 06:54:42

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

@raleur

Croutons a écrit :

j'ai pu y revenir pour changer la taille des VL avant de valider


Les partitionnements sont définitifs depuis l'installateur après la validation qu'on a faite, sans validation, je suppose qu'il a suffit de faire un retour arrière ? cool

Dernière modification par smolski (07-03-2019 06:54:58)


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#19 07-03-2019 20:35:02

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Tu supposes, mais moi j'ai cherché et je n'ai rien trouvé. On ne peut rien modifier tant que les volumes logiques programmés ne sont pas créés, et ensuite on ne peut pas faire de retour arrière ni modifier ces volume logiques.

Dernière modification par raleur (07-03-2019 20:35:26)


Il vaut mieux montrer que raconter.

Hors ligne

#20 07-03-2019 20:43:47

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Bonsoir
J'ai refais en VM , j'avais déja eu du mal la première fois
C'est un peu chaotique

Après avoir fait le partitionnement assisté , j'ai vu une option pour supprimé un volume logique
après cela apparait l'option de création de volume logique et on renseigne son nom sa taille, le point de montage

configurer le gestionnaire de volumes logique
AJEute0CbvEI.PNG




il faut supprimer un volume pour avoir l'option créer un volume
zdQPQgZe2akQ.PNG
cela fait pas mal de manipulation mais c'est assez rapide vu qu'à ce stade aucun formatage n'a été fait

edit:
au final sur ma Debian

lvscan


 ACTIVE            '/dev/VG1/home' [18,62 GiB] inherit
  ACTIVE            '/dev/VG1/racine' [9,31 GiB] inherit
  ACTIVE            '/dev/VG1/SWAP' [5,59 GiB] inherit
 



fdisk -l


Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x424401f6

Périphérique Amorçage      Début        Fin   Secteurs Taille Id Type
/dev/sda1    *              2048     206847     204800   100M  7 HPFS/NTFS/exFAT
/dev/sda2                 206848 1082509760 1082302913 516,1G  7 HPFS/NTFS/exFAT
/dev/sda3             1924530625 1953520064   28989440  13,8G  7 HPFS/NTFS/exFAT
/dev/sda4             1082511358 1924530175  842018818 401,5G  5 Étendue
/dev/sda5             1082511360 1924530175  842018816 401,5G 8e LVM Linux

La partition 3 ne commence pas sur une frontière de cylindre physique.
La partition 4 ne commence pas sur une frontière de cylindre physique.
Les entrées de la table de partitions ne sont pas dans l'ordre du disque.


Disque /dev/mapper/VG1-home : 18,6 GiB, 19998441472 octets, 39059456 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/mapper/VG1-racine : 9,3 GiB, 9999220736 octets, 19529728 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets


Disque /dev/mapper/VG1-SWAP : 5,6 GiB, 5997854720 octets, 11714560 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
 



vgdisplay


 --- Volume group ---
  VG Name               VG1
  System ID            
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               401,50 GiB
  PE Size               4,00 MiB
  Total PE              102785
  Alloc PE / Size       8582 / 33,52 GiB
  Free  PE / Size       94203 / 367,98 GiB
  VG UUID               DMoC4T-ZiKV-bq2P-MDMQ-FLWN-y5t9-yjzE9D
   

Dernière modification par Croutons (07-03-2019 20:52:43)


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#21 07-03-2019 20:54:23

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

S'il faut supprimer et recréer tous les volumes logiques qu'on veut redimensionner, je ne vois pas l'intérêt par rapport au partitionnement manuel dès le départ.

Il vaut mieux montrer que raconter.

Hors ligne

#22 07-03-2019 21:13:35

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

j'y ai été au pif , je ne fais pas d'installation souvent
La seul que j'avais fais avant c'était HAndylinux2 sur disque entier
enfin je suis retombé sur mes pieds au bout du compte
J'ai pas été voir le mode de partitionnement manuel

raleur a écrit :

Je n'ai jamais vu la possibilité de redimensionner un volume logique LVM dans l'installateur Debian, que ce soit en partitionnement assisté ou en manuel. Je viens de revérifier à l'instant.


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#23 07-03-2019 22:50:07

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Merci pour tes explications et l'analyse raleur!

raleur a écrit :

L'exécution périodique de fstrim repose sur un "timer" systemd. Il faut voir s'il est paramétrable.


D'accord. Et peut-on savoir combien de temps dure cette opération? Aurais-tu un ordre de grandeur? (10 min, 45 min, 3h?)

raleur a écrit :

Non, le système doit être opérationnel.


Et en veille, ça fonctionne?

raleur a écrit :

L'objectif de cet espace libre est différent. Dans le cas 1 que j'exposais précédemment, cet espace non alloué ou dans une partition non utilisée était réservé à l'overprovisioning, alors qu'ici il sert de réserve pour un usage futur.


Cet espace libre est-il celui du groupe de volumes? Si oui, peut-il servir pour l'overprovisioning, au même titre que celui du disque? Et si oui encore, l'usage de la fonction TRIM a-t-il un sens? Car on peut toujours l'activer le moment voulu si j'ai bien compris (c'est-à-dire au moment où, par nécessité, l'espace réservé à l'overprovisioning est ajouté au système de fichiers ; mais il y a beaucoup de "si" dans mon raisonnement!).

Frosch a écrit :

Ma proposition était plus une question de place, vu que tu as un petit SSD, autant ne pas l'encombrer avec des choses inutiles comme le swap.


En effet, cela me donne matière à réflexion! En fait tout dépend surtout de l'usage que je ferai de l'hibernation.

Hors ligne

#24 08-03-2019 16:48:04

raleur
Membre
Inscription : 03-10-2014

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

(fstrim)

masa a écrit :

Et peut-on savoir combien de temps dure cette opération? Aurais-tu un ordre de grandeur? (10 min, 45 min, 3h?)


Non, aucune idée.
La machine doit être active, pas en veille.

masa a écrit :

Cet espace libre est-il celui du groupe de volumes? Si oui, peut-il servir pour l'overprovisioning, au même titre que celui du disque? Et si oui encore, l'usage de la fonction TRIM a-t-il un sens?


Ça dépend s'il s'agit d'espace non partitionné ou d'espace inclus dans un volume physique LVM. Seul l'espace inclus dans un volume physique fait partie du groupe de volumes.
Tout espace libre peut servir pour l'overprovisoning tant qu'on n'écrit pas dedans, qu'il soit non partitionné, dans un volume physique d'un groupe de volumes ou dans le système de fichiers d'un volume logique. L'usage du TRIM a toujours du sens dans tous les cas, mais se justifie d'autant plus qu'on monte dans les couches du disque vers le système de fichiers et que les allocations sont de plus en plus dynamiques.

A noter que l'option discard doit être activée dans la configuration de LVM pour que l'option discard du système de fichiers ou fstrim soit transmis au SSD.


Il vaut mieux montrer que raconter.

Hors ligne

#25 10-03-2019 15:49:03

masa
Membre
Distrib. : Debian Bullseye
Noyau : Linux 5.10.0-10-amd64
(G)UI : Xfce
Inscription : 25-02-2019

Re : [Résolu] Partitionnement entre SSD 32 Go et HDD

Bonjour,

Merci pour tes dernières indications raleur, j'ai enfin pu lancer la procédure de ce fameux partitionnement.
J'ai indiqué l'option discard pour tous les volumes sauf swap. Tout est en ext4, /boot y compris.

Seulement, je crois que j'ai installé GRUB au mauvais endroit car il ne se charge pas au démarrage.
J'ai choisi à cette dernière étape de l'installer sur le disque sdb (SSD) et non sur la partition /boot en sdb1, car j'ai cru qu'il le ferait automatiquement (seuls les disques étaient présents par défaut, il fallait utiliser une option d'installation "manuelle" pour pouvoir choisir une partition en particulier).
J'ai essayé de relancer uniquement cette étape avec l'installateur en priority=medium, mais celui-ci ne veut pas la lancer avant d'avoir effectué l'étape du partitionnement. Je n'ai pas effectué cette dernière de nouveau car il me paraît inutile de formater des disques une fois de plus, pour y réinstaller exactement le même système.

Pourriez-vous me dire si mon intuition est correcte et si oui, comment réinstaller GRUB proprement?

fdisk -l


Disk /dev/sdb: 29.8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5d8d5b83

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sdb1  *      2048   976895   974848  476M 83 Linux
/dev/sdb2       976896 62531583 61554688 29.4G 8e Linux LVM


Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x3d3ceae2

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1        2048 488282111 488280064 232.9G 8e Linux LVM




Disk /dev/sdc: 7.2 GiB, 7746879488 bytes, 15130624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x49506c1e

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1  *        0 7077887 7077888  3.4G  0 Empty
/dev/sdc2       21296   22127     832  416K ef EFI (FAT-12/16/32)


Disk /dev/mapper/SSD-racine: 6.5 GiB, 6996099072 bytes, 13664256 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/SSD-home: 6.5 GiB, 6996099072 bytes, 13664256 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/HDD-var: 4.7 GiB, 4999610368 bytes, 9764864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/HDD-swap: 8.4 GiB, 8996782080 bytes, 17571840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/HDD-data: 46.6 GiB, 49996103680 bytes, 97648640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 

Hors ligne

Pied de page des forums