Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis
sur les questions suivantes :
- pensez-vous utile de faire une partition séparée pour /home (ou autre) ?
- peut-on mettre le swap dans un fichier plutôt que dans une partition
dédiée, si oui est-ce souhaitable ?
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une
utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD
(discard, stripe-width**). Peut-on faire un ext4 sans journal ?
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC
portable, pas un serveur) ?
- /tmp en RAM ?
- d'autres conseils ?
(*) J'ai lu que le journal permet une vérification plus rapide du fs en
cas de crash. Vu que ma machine crashe extrêmement rarement... Si le
temps de vérification est celui de "e2fsck -f" je suis largement prêt à
faire le sacrifice (du journal pour limiter l'usure).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cyprien Nicolas
Le 08/11/2013 12:50, Lucas Levrel écrivit :
Bonjour,
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou autre) ?
Ça permet de choisir de ne pas la journaliser par exemple, selon l'utilité que tu en as. Ou l'inverse d'ailleurs.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Oui, on peut. C'est pas forcément souhaitable, ça ajoute une indirection qui peut diminuer légèrement les perfs en cas d'utilisation intensive du swap. Après faut voir si tu as vraiment besoin d'un swap aussi, c'est pas indispensable hormis pour le suspend2disk.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
Oui on peut faire du ext4 sans journal, ou du ext3/4 avec un journal externe à la partition. Si tu veux pas de journal, ya toujours ext2.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Pas d'avis sur les options, à part le man de e2fsck qui dit que discard peut, dans quelques cas, empêcher la récupération de données.
- /tmp en RAM ?
Oui.
- d'autres conseils ?
Tu peux augmenter le cache lié au disque, et le temps de commit des écritures depuis le cache du noyau, je sais plus le nom des options, mais ça peut limiter les écritures en partie.
Voir aussi http://blog.sebian.fr/tag/ssd/
(*) J'ai lu que le journal permet une vérification plus rapide du fs en cas de crash. Vu que ma machine crashe extrêmement rarement... Si le temps de vérification est celui de "e2fsck -f" je suis largement prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de fichiers en cas de crash. Par exemple, lors de la suppression d'un fichier, cette entrée est notée dans le journal, commitée, puis ensuite le fs peut procédér à la suppression de l'inode associée au fichier et à marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir l'inode qui indique toujours des blocs qui sont pourtant marqués comme libéres, affichant un contenu corrompu du fichier. Le journal sert seulement à garantir cette cohérence dans ces données, pas dans le contenu des fichiers.
Mes 0,02 €
-- « Le fromage gratuit ne se trouve que dans les pièges à souris. - Donc si c'est gratuit, c'est toi la souris ! »
Le 08/11/2013 12:50, Lucas Levrel écrivit :
Bonjour,
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos
avis sur les questions suivantes : - pensez-vous utile de faire une
partition séparée pour /home (ou autre) ?
Ça permet de choisir de ne pas la journaliser par exemple, selon
l'utilité que tu en as. Ou l'inverse d'ailleurs.
- peut-on mettre le swap dans un fichier plutôt que dans une
partition dédiée, si oui est-ce souhaitable ?
Oui, on peut. C'est pas forcément souhaitable, ça ajoute une
indirection qui peut diminuer légèrement les perfs en cas d'utilisation
intensive du swap. Après faut voir si tu as vraiment besoin d'un swap
aussi, c'est pas indispensable hormis pour le suspend2disk.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour
une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux
SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
Oui on peut faire du ext4 sans journal, ou du ext3/4 avec un journal
externe à la partition. Si tu veux pas de journal, ya toujours ext2.
- utiliser discard ou faire un trim manuel de temps en temps (c'est
un PC portable, pas un serveur) ?
Pas d'avis sur les options, à part le man de e2fsck qui dit que discard
peut, dans quelques cas, empêcher la récupération de données.
- /tmp en RAM ?
Oui.
- d'autres conseils ?
Tu peux augmenter le cache lié au disque, et le temps de commit des
écritures depuis le cache du noyau, je sais plus le nom des options,
mais ça peut limiter les écritures en partie.
Voir aussi http://blog.sebian.fr/tag/ssd/
(*) J'ai lu que le journal permet une vérification plus rapide du fs
en cas de crash. Vu que ma machine crashe extrêmement rarement... Si
le temps de vérification est celui de "e2fsck -f" je suis largement
prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de
fichiers en cas de crash. Par exemple, lors de la suppression d'un
fichier, cette entrée est notée dans le journal, commitée, puis ensuite
le fs peut procédér à la suppression de l'inode associée au fichier et à
marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir
l'inode qui indique toujours des blocs qui sont pourtant marqués comme
libéres, affichant un contenu corrompu du fichier. Le journal sert
seulement à garantir cette cohérence dans ces données, pas dans le
contenu des fichiers.
Mes 0,02 €
--
« Le fromage gratuit ne se trouve que dans les pièges à souris.
- Donc si c'est gratuit, c'est toi la souris ! »
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou autre) ?
Ça permet de choisir de ne pas la journaliser par exemple, selon l'utilité que tu en as. Ou l'inverse d'ailleurs.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Oui, on peut. C'est pas forcément souhaitable, ça ajoute une indirection qui peut diminuer légèrement les perfs en cas d'utilisation intensive du swap. Après faut voir si tu as vraiment besoin d'un swap aussi, c'est pas indispensable hormis pour le suspend2disk.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
Oui on peut faire du ext4 sans journal, ou du ext3/4 avec un journal externe à la partition. Si tu veux pas de journal, ya toujours ext2.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Pas d'avis sur les options, à part le man de e2fsck qui dit que discard peut, dans quelques cas, empêcher la récupération de données.
- /tmp en RAM ?
Oui.
- d'autres conseils ?
Tu peux augmenter le cache lié au disque, et le temps de commit des écritures depuis le cache du noyau, je sais plus le nom des options, mais ça peut limiter les écritures en partie.
Voir aussi http://blog.sebian.fr/tag/ssd/
(*) J'ai lu que le journal permet une vérification plus rapide du fs en cas de crash. Vu que ma machine crashe extrêmement rarement... Si le temps de vérification est celui de "e2fsck -f" je suis largement prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de fichiers en cas de crash. Par exemple, lors de la suppression d'un fichier, cette entrée est notée dans le journal, commitée, puis ensuite le fs peut procédér à la suppression de l'inode associée au fichier et à marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir l'inode qui indique toujours des blocs qui sont pourtant marqués comme libéres, affichant un contenu corrompu du fichier. Le journal sert seulement à garantir cette cohérence dans ces données, pas dans le contenu des fichiers.
Mes 0,02 €
-- « Le fromage gratuit ne se trouve que dans les pièges à souris. - Donc si c'est gratuit, c'est toi la souris ! »
moi-meme
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes :
un fil sur linux.debian.user.french : "[Un peu HS] Retour sur l'utilisation des SSD sous debian"
Si ça peut t'aider.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis
sur les questions suivantes :
un fil sur linux.debian.user.french :
"[Un peu HS] Retour sur l'utilisation des SSD sous debian"
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes :
un fil sur linux.debian.user.french : "[Un peu HS] Retour sur l'utilisation des SSD sous debian"
Si ça peut t'aider.
Emmanuel Florac
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
Bonjour,
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou autre)
Oui, toujours pratique d'avoir le home séparé, en cas de problème sur le système.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Non, ce n'est pas souhaitable.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Non, garde le journal.
- /tmp en RAM ?
Oui, c'est mieux.
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie non formatée de ton SSD. Le mécanisme de wear-leveling utilisera la partie non formatée pour répartir les écritures. Il faut savoir que les SSD existent toujours en deux modèles à peu près identiques, par exemple en 100 et 128 Go de capacité, et le 100 Go est un peu plus cher en général: en fait les SSD 100 Go ont bien 128 Go de flash, mais les 28 Go supplémentaires sont réservés pour le wear leveling, c'est ce qui distingue les modèles pros ou haut de gamme des modèles basiques.
Donc si tu as un modèle basique, il est quand même de bon ton de ne pas utiliser au moins 10% de l'espace, par sécurité.
-- Three may keep a secret, if two of them are dead. Benjamin Franklin.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
Bonjour,
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis
sur les questions suivantes :
- pensez-vous utile de faire une partition séparée pour /home (ou autre)
Oui, toujours pratique d'avoir le home séparé, en cas de problème sur le
système.
- peut-on mettre le swap dans un fichier plutôt que dans une partition
dédiée, si oui est-ce souhaitable ?
Non, ce n'est pas souhaitable.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une
utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD
(discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier
les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un
PC
portable, pas un serveur) ?
Non, garde le journal.
- /tmp en RAM ?
Oui, c'est mieux.
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie
non formatée de ton SSD. Le mécanisme de wear-leveling utilisera la
partie non formatée pour répartir les écritures. Il faut savoir que les
SSD existent toujours en deux modèles à peu près identiques, par exemple
en 100 et 128 Go de capacité, et le 100 Go est un peu plus cher en
général: en fait les SSD 100 Go ont bien 128 Go de flash, mais les 28 Go
supplémentaires sont réservés pour le wear leveling, c'est ce qui
distingue les modèles pros ou haut de gamme des modèles basiques.
Donc si tu as un modèle basique, il est quand même de bon ton de ne pas
utiliser au moins 10% de l'espace, par sécurité.
--
Three may keep a secret, if two of them are dead.
Benjamin Franklin.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
Bonjour,
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos avis sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou autre)
Oui, toujours pratique d'avoir le home séparé, en cas de problème sur le système.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Non, ce n'est pas souhaitable.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Non, garde le journal.
- /tmp en RAM ?
Oui, c'est mieux.
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie non formatée de ton SSD. Le mécanisme de wear-leveling utilisera la partie non formatée pour répartir les écritures. Il faut savoir que les SSD existent toujours en deux modèles à peu près identiques, par exemple en 100 et 128 Go de capacité, et le 100 Go est un peu plus cher en général: en fait les SSD 100 Go ont bien 128 Go de flash, mais les 28 Go supplémentaires sont réservés pour le wear leveling, c'est ce qui distingue les modèles pros ou haut de gamme des modèles basiques.
Donc si tu as un modèle basique, il est quand même de bon ton de ne pas utiliser au moins 10% de l'espace, par sécurité.
-- Three may keep a secret, if two of them are dead. Benjamin Franklin.
Lucas Levrel
Le 8 novembre 2013, Cyprien Nicolas a écrit :
Merci pour les avis et le lien.
(*) J'ai lu que le journal permet une vérification plus rapide du fs en cas de crash. Vu que ma machine crashe extrêmement rarement... Si le temps de vérification est celui de "e2fsck -f" je suis largement prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de fichiers en cas de crash. Par exemple, lors de la suppression d'un fichier, cette entrée est notée dans le journal, commitée, puis ensuite le fs peut procédér à la suppression de l'inode associée au fichier et à marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir l'inode qui indique toujours des blocs qui sont pourtant marqués comme libéres, affichant un contenu corrompu du fichier. Le journal sert seulement à garantir cette cohérence dans ces données, pas dans le contenu des fichiers.
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ? Je l'interprétais comme ceci : après un crash, le système fait un fsck. S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à corriger, la réparation est très rapide. S'il n'y a pas de journal, il faut vérifier intégralement le fs ; la procédure étant la même qu'un "fsck -f", c'est nettement plus long.
-- LL
Le 8 novembre 2013, Cyprien Nicolas a écrit :
Merci pour les avis et le lien.
(*) J'ai lu que le journal permet une vérification plus rapide du fs
en cas de crash. Vu que ma machine crashe extrêmement rarement... Si
le temps de vérification est celui de "e2fsck -f" je suis largement
prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de
fichiers en cas de crash. Par exemple, lors de la suppression d'un
fichier, cette entrée est notée dans le journal, commitée, puis ensuite
le fs peut procédér à la suppression de l'inode associée au fichier et à
marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir
l'inode qui indique toujours des blocs qui sont pourtant marqués comme
libéres, affichant un contenu corrompu du fichier. Le journal sert
seulement à garantir cette cohérence dans ces données, pas dans le
contenu des fichiers.
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ?
Je l'interprétais comme ceci : après un crash, le système fait un fsck.
S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à
corriger, la réparation est très rapide. S'il n'y a pas de journal, il
faut vérifier intégralement le fs ; la procédure étant la même qu'un
"fsck -f", c'est nettement plus long.
(*) J'ai lu que le journal permet une vérification plus rapide du fs en cas de crash. Vu que ma machine crashe extrêmement rarement... Si le temps de vérification est celui de "e2fsck -f" je suis largement prêt à faire le sacrifice (du journal pour limiter l'usure).
C'est faux. Le journal sert à garantir la cohérence du système de fichiers en cas de crash. Par exemple, lors de la suppression d'un fichier, cette entrée est notée dans le journal, commitée, puis ensuite le fs peut procédér à la suppression de l'inode associée au fichier et à marquer les blocks utilisés par le fichier comme libérés.
Sans journal, en cas de crash au milieu de la suppression, tu peux avoir l'inode qui indique toujours des blocs qui sont pourtant marqués comme libéres, affichant un contenu corrompu du fichier. Le journal sert seulement à garantir cette cohérence dans ces données, pas dans le contenu des fichiers.
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ? Je l'interprétais comme ceci : après un crash, le système fait un fsck. S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à corriger, la réparation est très rapide. S'il n'y a pas de journal, il faut vérifier intégralement le fs ; la procédure étant la même qu'un "fsck -f", c'est nettement plus long.
-- LL
Lucas Levrel
Le 8 novembre 2013, moi-meme a écrit :
un fil sur linux.debian.user.french : "[Un peu HS] Retour sur l'utilisation des SSD sous debian"
Si ça peut t'aider.
Vu et lu, merci !
-- LL
Le 8 novembre 2013, moi-meme a écrit :
un fil sur linux.debian.user.french :
"[Un peu HS] Retour sur l'utilisation des SSD sous debian"
un fil sur linux.debian.user.french : "[Un peu HS] Retour sur l'utilisation des SSD sous debian"
Si ça peut t'aider.
Vu et lu, merci !
-- LL
Lucas Levrel
Le 8 novembre 2013, Emmanuel Florac a écrit :
Merci pour les infos.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé les paragraphes ?
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie non formatée de ton SSD.
Oui. J'ai vu, sur hardware.fr je crois, que le Samsung 840 Pro aurait 7% d'espace caché. De plus, la notice constructeur parle d'over-provisioning, le mot over semble confirmer l'info. Je compte laisser un morceau non partitionné de toute façon.
-- LL
Le 8 novembre 2013, Emmanuel Florac a écrit :
Merci pour les infos.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une
utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD
(discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier
les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un
PC portable, pas un serveur) ?
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé
les paragraphes ?
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie
non formatée de ton SSD.
Oui. J'ai vu, sur hardware.fr je crois, que le Samsung 840 Pro aurait 7%
d'espace caché. De plus, la notice constructeur parle d'over-provisioning,
le mot over semble confirmer l'info. Je compte laisser un morceau non
partitionné de toute façon.
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit:
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ?
ext4 est beaucoup plus performant. Définitivement ext4, il faut oublier les OS des années 80.
- utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé les paragraphes ?
- d'autres conseils ?
Si tu veux maximiser la performance et la durabilité, garde une partie non formatée de ton SSD.
Oui. J'ai vu, sur hardware.fr je crois, que le Samsung 840 Pro aurait 7% d'espace caché. De plus, la notice constructeur parle d'over-provisioning, le mot over semble confirmer l'info. Je compte laisser un morceau non partitionné de toute façon.
-- LL
Nicolas George
Lucas Levrel , dans le message , a écrit :
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ? Je l'interprétais comme ceci : après un crash, le système fait un fsck. S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à corriger, la réparation est très rapide.
C'est une question d'acception des termes, ce n'est pas clair s'il faut considérer l'exécution du journal comme une vérification.
Lucas Levrel , dans le message
<alpine.LNX.2.10.1311091050120.1600@localhost>, a écrit :
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ?
Je l'interprétais comme ceci : après un crash, le système fait un fsck.
S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à
corriger, la réparation est très rapide.
C'est une question d'acception des termes, ce n'est pas clair s'il faut
considérer l'exécution du journal comme une vérification.
Mais ce que tu dis est-il incompatible avec l'affirmation que j'ai lue ? Je l'interprétais comme ceci : après un crash, le système fait un fsck. S'il y a un journal, il suffit de le lire pour savoir ce qu'il y a à corriger, la réparation est très rapide.
C'est une question d'acception des termes, ce n'est pas clair s'il faut considérer l'exécution du journal comme une vérification.
Philippe
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos
avis
sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou
autre) ? C'est une bonne pratique, plus que «utile», indispensable.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Il est possible de se passer de swap si la RAM est en quantité importante. Mais sinon, sur le SSD, le swap a sa place.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ? - utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Je crois que c'est géré a l'installation quand le SSD est détecté. Il y a des infos un peu partout sur le net.
- /tmp en RAM ?
oui: dans fstab tmpfs /tmp tmpfs defaults,noatime,mode77 0 0
-- https://www.youtube.com/watch?v=JhideeG12zw Philippe Vessaire Ò¿Ó¬
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos
avis
sur les questions suivantes :
- pensez-vous utile de faire une partition séparée pour /home (ou
autre) ?
C'est une bonne pratique, plus que «utile», indispensable.
- peut-on mettre le swap dans un fichier plutôt que dans une partition
dédiée, si oui est-ce souhaitable ?
Il est possible de se passer de swap si la RAM est en quantité
importante. Mais sinon, sur le SSD, le swap a sa place.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une
utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD
(discard, stripe-width**). Peut-on faire un ext4 sans journal ?
- utiliser discard ou faire un trim manuel de temps en temps (c'est un
PC portable, pas un serveur) ?
Je crois que c'est géré a l'installation quand le SSD est détecté. Il y a
des infos un peu partout sur le net.
- /tmp en RAM ?
oui: dans fstab
tmpfs /tmp tmpfs defaults,noatime,mode77 0 0
--
https://www.youtube.com/watch?v=JhideeG12zw
Philippe Vessaire Ò¿Ó¬
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
Je m'apprête à installer Linux sur un SSD (Samsung). J'aimerais vos
avis
sur les questions suivantes : - pensez-vous utile de faire une partition séparée pour /home (ou
autre) ? C'est une bonne pratique, plus que «utile», indispensable.
- peut-on mettre le swap dans un fichier plutôt que dans une partition dédiée, si oui est-ce souhaitable ?
Il est possible de se passer de swap si la RAM est en quantité importante. Mais sinon, sur le SSD, le swap a sa place.
- quelle version d'ext ? Le journal cause beaucoup d'écritures, pour une utilité réduite*, mais ext4 semble avoir des fonctions utiles aux SSD (discard, stripe-width**). Peut-on faire un ext4 sans journal ? - utiliser discard ou faire un trim manuel de temps en temps (c'est un PC portable, pas un serveur) ?
Je crois que c'est géré a l'installation quand le SSD est détecté. Il y a des infos un peu partout sur le net.
- /tmp en RAM ?
oui: dans fstab tmpfs /tmp tmpfs defaults,noatime,mode77 0 0
-- https://www.youtube.com/watch?v=JhideeG12zw Philippe Vessaire Ò¿Ó¬
Emmanuel Florac
Le Sat, 09 Nov 2013 11:01:08 +0100, Lucas Levrel a écrit:
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé les paragraphes ?
Pas de rapport avec le trim, on parle bien du journal. Tous les systèmes de fichiers modernes étant journalisés, tous les SSD de qualité correcte ont un mécanisme d'optimisation pour gérer le journal (une stratégie de cache spécifique); sacrifier le journal n'est pas une bonne idée.
-- I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. A. Whitney Brown
Le Sat, 09 Nov 2013 11:01:08 +0100, Lucas Levrel a écrit:
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé
les paragraphes ?
Pas de rapport avec le trim, on parle bien du journal. Tous les systèmes
de fichiers modernes étant journalisés, tous les SSD de qualité correcte
ont un mécanisme d'optimisation pour gérer le journal (une stratégie de
cache spécifique); sacrifier le journal n'est pas une bonne idée.
--
I am not a vegetarian because I love animals; I am a vegetarian
because I hate plants.
A. Whitney Brown
Le Sat, 09 Nov 2013 11:01:08 +0100, Lucas Levrel a écrit:
Non, garde le journal.
Est-ce que le journal a un rapport avec le trim, ou as-tu juste inversé les paragraphes ?
Pas de rapport avec le trim, on parle bien du journal. Tous les systèmes de fichiers modernes étant journalisés, tous les SSD de qualité correcte ont un mécanisme d'optimisation pour gérer le journal (une stratégie de cache spécifique); sacrifier le journal n'est pas une bonne idée.
-- I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. A. Whitney Brown
Eric Belhomme
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
- d'autres conseils ?
Sur un portable : - ext4, avec noatime, et trim - /tmp en ramfs - pas de swap (inutile avec les machines modernes à 4 ou 8G de ram, et le suspend2disk peut être fait sur un fichier d'échange)
Mes 2 cents
-- Rico
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
- d'autres conseils ?
Sur un portable :
- ext4, avec noatime, et trim
- /tmp en ramfs
- pas de swap (inutile avec les machines modernes à 4 ou 8G de ram, et le
suspend2disk peut être fait sur un fichier d'échange)
Le Fri, 08 Nov 2013 12:50:32 +0100, Lucas Levrel a écrit :
- d'autres conseils ?
Sur un portable : - ext4, avec noatime, et trim - /tmp en ramfs - pas de swap (inutile avec les machines modernes à 4 ou 8G de ram, et le suspend2disk peut être fait sur un fichier d'échange)
