In data martedì 24 gennaio 2017 17:25:39, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, Patrick Serru a écrit :
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est…
l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux.
Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication
de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi.
J’ai longtemps gardé en commentaire la ligne où il était fait référence
à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 ->
UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1
En attendant la confirmation, je vais tenter de rebooter après avoir
commenté les lignes de fstab relatives aux st500.
Pour ma défense, Grub, X et Open Suse n’ont pas toujours été
merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab !
Cordialement,
Patrick
---------------------- Je viens de booter deux fois sans problème avec - les deux lignes relatives aux partitions du disque dur non moté en commantaire, - grub installé depuis mon système "quitidient", dont la partition racine est également sur le SSD.
Bug ?
Cordialement,
Patrick Oui je pense bug report serait indiqué.
noatime: voyons, normalement on disait (surtout pour les premiers ssd, que avoir le swap sur ssd va détruire le ssd. Je ne peut pas confirmer ceci, j'ai un adata pro 900 est il marche toujours a merveille. Donc, pour swap en tous cas noatimes est une valeur bonne. Aussi pour /root j'ai l'expérience que ceci peut induire une vitesse de démarrage légèrement plus rapide. Malheureusement, je n'ai pas un ssd pour le home pour le moment. Je pense noatime pour le /home va se rendre utile quand on ha a déplacer des grandes quantités de petit fichier. Une autre chose, je pense tu utilise (intelligemment, moi de même) ext4 pour tes partitions. Ext4 ha un très bonne support pour trim, cependant pour une question d'économie des temps de démarrage je préfère de ne le pas mettre "institutionnalisé" en fstab ce valeur. (valeur serait: discard). Il suffit en effet chaque 6 mois de ouvrir la CLI est taper: sudo fstrim -a -v /linux (dans ton cas naturellement) et attendre longtemps - il va te dire ce qu'il a fait. En combinaison avec noatime, ceci donne, à mon expérience, des bonnes résultats. Amuse toi bien ;-) "stak" -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org