Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par masa (12-03-2019 19:23:55)
Hors ligne
- 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
- 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
- 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.
/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.
- 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.
- 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
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.
"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.
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.
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
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.
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.
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.
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.
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.
/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).
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.
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.
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
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 
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
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 .
je remets ça à demainDernière modification par masa (04-03-2019 04:22:19)
Hors ligne
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é).
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 ?
je suis pas pour utiliser un logiciel pour entretenir le ssd
Qu'entends-tu par "entretenir", et à quel genre de logiciel fais-tu allusion ?
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.
je sais pas si avec smartctl - on peu voir si des cellules HS
On digresse du sujet, mais c'est intéressant.
Aucun bloc défectueux réalloué.
Aucune erreur d'écriture ou d'effacement.
Aucun événement de réallocation (cohérent avec l'attribut n° 5).
Aucun secteur illisible détecté lors d'un accès en ligne ou de l'auto-test hors ligne.
L'usure estimée est inférieure à 1%.
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%.
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.
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.
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
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.
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 
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
/hors sujet début
pris sur la documentation de la carte mère X370-A intel (modifié)
ps: pas trop confiance 
/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)
Dernière modification par anonyme (04-03-2019 12:16:27)
Il vaut mieux montrer que raconter.
Hors ligne
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?
5Go c'est bien. tu peux remplir ton HDD sans souci.
HDD? tu voulais dire SSD?
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! 
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?
Si tu mets le swap sur le SSD, il faut aussi retrancher sa taille.
Oui, effectivement, oubli corrigé!
Le TRIM est supporté, n'est-ce pas?
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?
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à :
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 :
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?
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?
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!
Dernière modification par masa (06-03-2019 06:22:00)
Hors ligne
.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
Hors ligne
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 :
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.
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?
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
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
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
Hors ligne
Le TRIM est supporté, n'est-ce pas?
Oui :
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.
l'opération peut-elle se lancer lorsque le système est éteint, ou en hibernation?
Non, le système doit être opérationnel.
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.
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.
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).
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.
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.
À 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.
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
-->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
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
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
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 ? 
Dernière modification par smolski (07-03-2019 06:54:58)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par raleur (07-03-2019 20:35:26)
Il vaut mieux montrer que raconter.
Hors ligne
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
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
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
Hors ligne
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?)
Non, le système doit être opérationnel.
Et en veille, ça fonctionne?
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!).
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
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.
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
Hors ligne