pour Asus la fréquence mémoire (sans OC ) est de 2666Mhz sur la série X570 (si je me suis pas tromper )
un exemple pour une FuryX DDR4
la fréquence de base 2400 , XPM est un profil intel a choisir dans le bios
ps: pour que la barrette fonctionne bien sa tension a 3200 passe de 1.2V a 1.35V
sinon tu a bien placer tes barrettes et bien verrouiller
Asus a un utilitaire dans le bios pour voir la configuration des barrettes actuelle
tu commence par une barrette par exemple
=> https://www.corsair.com/fr/fr/Cat%C3%A9 … tech-specs]]>
Qu'entends-tu par "RAM Intel" ? A ma connaissance Intel ne fabrique plus de RAM depuis des décennies
celle là : https://www.amazon.fr/gp/product/B07RW6 … UTF8&psc=1
ram compatible intel
par opposition à celle là : https://www.topachat.com/pages/detail2_ … 19301.html
ram compatible AMD.]]>
donc a partir de sda je travaille sur sdb4 et sdb3 avec gparted
ps: le swap est de 7,7Go environ il est maintenant de 15Go maintenant (mémoire installé 16Go)
le log de gparted
pour sda4
le log pour le swap
a priori rien modifier dans le fstab
ma partition "document" n'est pas monter (il faut que je le fasse pour archiver et changer son nom , elle est vide en ext4 )
je comprend pas pourquoi tu a autant de soucis
je pourrai l'utiliser pour déplacer mon /home de sdb2 vers sdb4 aussi
remarque:
ma ram est de 14,6Gio pour un swap de 15,6Gio]]>
Il y aurait une différence avec une partition swap trop petite ?
Non, donc ce n'est pas mieux.
En dehors du fait que l'espace libre, quand correctement réfléchit est largement supérieur à la taille d'une partition swap, chez moi, on parle de 60Go d'espace libre
Une partie de cet espace "libre" doit être disponible pour l'agrandissement du swap donc tu ne peux pas en disposer librement. De ce point de vue il n'y a pas vraiment d'avantage par rapport à une partition de swap.]]>
Parce que le noyau ne sait pas vraiment utiliser un fichier normal comme swap. Donc il doit cartographier les blocs occupés par le fichier pour ensuite y accéder directement sans passer par le système de fichiers. Non seulement cela viole l'abstraction du système de fichiers, mais cela ne fonctionne pas avec tous les types de systèmes de fichiers (notamment btrfs avant le noyau 5.0) ni tous les types de fichiers (fichier creux ou copy-on-write par exemple) pour lesquels la cartographie est impossible ou instable.
Merci pour tes réponses
Bon, effectivement, je n'ai d'expérience que sur ext4.
Jamais eu d'incidents par contre sur 60+ installs (je n'utilise pas l'hibernation dont je n'ai jamais compris l'intérêt : quand je n'utilise pas un ordi longtemps, eh ben je l'éteins.
nam1962 a écrit :En tous cas systemd-swap évite deux choses :
- bloquer en permanence une partition, on sait pas pourquoi
- avoir une taille trop grande ou trop petite pour ce machin bloqué
C'est une fausse impression car l'espace nécessaire au swap doit être disponible en cas de besoin. Que se passerait-il si le système a besoin d'ajouter du swap alors qu'il n'y a plus d'espace disque disponible ?
Il y aurait une différence avec une partition swap trop petite ? En dehors du fait que l'espace libre, quand correctement réfléchit est largement supérieur à la taille d'une partition swap, chez moi, on parle de 60Go d'espace libre (12Go de RAM)]]>
un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
et pour une clé usb 2.0/3.0 ? , c'est lent ?
Hélas non. L'expérience récente m'a rappelé que si l'USB 3 peut améliorer la vitesse de lecture des clés USB, la vitesse d'écriture reste médiocre et dans cet ordre de grandeur.]]>
je comprend pas comment tu peux avoir le même soucis si tu as tout réinstallé
pardon croutons , j'ai pas été clair .
première tentative : post #1 ,
puis Gparted (17 heures) : résultat : à peine .
arrêt gparted puis poweroff brutal .
partition abîmée (normal)
deuxième tentative : post #11 ,
tout réinstallé sans redimensionnement .
pas encore lancé gparted .
Debian Alain a écrit :
plus de 17 heures pour déplacer 40,000 Mo , c'est trop
Non, pour déplacer 800 Go. Néanmoins un SSD n'est pas affecté par les allers-retours incessants des têtes de lecture/écriture comme le serait un disque dur pour réaliser cette opération, donc un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
(râleur) et pour réduire (cas présent) de 100 Go sur la gauche (à peu près) sdb4 ?
tu prévois combien de temps ? à la louche ...
un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
et pour une clé usb 2.0/3.0 ? , c'est lent ?]]>
plus de 17 heures pour déplacer 40,000 Mo , c'est trop
Non, pour déplacer 800 Go. Néanmoins un SSD n'est pas affecté par les allers-retours incessants des têtes de lecture/écriture comme le serait un disque dur pour réaliser cette opération, donc un débit effectif < 800 Go / 17 h = 13 Mo/s est très faible pour un SSD.
si qqun a une astuce en cli . rapide
Je ne connais qu'un seul programme en ligne de commande capable de déplacer une partition et son contenu, sfdisk avec l'option --move-data. Jamais utilisée en revanche.
reste la solution de LVM . mais je l'utilise rarement
Et il faut y penser au moment de l'installation. Après, quand on en a besoin, c'est trop tard.]]>
Donc à mon avis le plus simple est de supprimer la partition de swap actuelle, réduire la partition /home par la droite et créer une nouvelle partition de swap à la fin du SSD.
oui , je pense . mais là ... repos . je verrai plus tard .
notes : ah oui , reste la solution de LVM . mais je l'utilise rarement .
Pour l'agrandir, je suppose ?
oui .
trouvé : https://lecrabeinfo.net/redimensionner- … linux.html
j'attends vos avis .
]]>