Reprise du message précédent :
Merci à tous pour vos réponses    
Je n'ai qu'un seul disque dur interne, donc dans tous les cas je ne peux faire qu'un transfert entre celui ci et un périphérique externe en USB ( j'utilise de l'USB3 la plupart du temps )
Effectivement c'est bizarre ce ralentissement : lancer Firefox pendant un transfert de fichier peut prendre plus d'une minute, c'est incroyable comme ça rame  ( sans transfert, il se lance instantanément )
D'autant plus que le PC est extrêmement rapide le reste du temps : Archlinux Mate est super réactif et léger  

Ca ne fait pas avancer le soucis mais je suis dans le même cas que toi.

Moi c'est tout le pc qui freeze surtout dolphin (je suis sous KDE).

Transfert entre SSD interne et disque usb3, disque en sata vers disque USB 3...tout le temps.

Je ne me rappelle pas de ce genre de soucis quand j'étais encore sous Debian.

Aujourd'hui je lance mes transferts le soir et je laisse le truc bosser car c'est vraiment un irritant.

Conf: i7 4770k, 16Go de RAM, SSD et plusieurs disques internes WD

Tiens au passage, un bon bug après la maj de ma machine ce midi, après mettre loguer sur ssdm, écran noir sur le bureau...seul possibilité faire un alt+F2 pour afficher le petite boîte de dialogue qui permet de lancer des applications

Sur mon PC portable Dell avec Ubuntu 18.10 Mate, ça rame tout autant pendant un gros transfert de fichier -> on ne peut rien faire d'autre avec la machine, faut attendre la fin.
Et sinon j'ai un autre PC avec W10, mais vu le processeur miteux je préfère ne pas essayer de faire autre chose pendant que je fais du transfert de fichier  

Vous avez essayez de faire un trasfert similaire mais en ligne de commande voir si c'est pareil ?
C'est fort probable que je dit de la merde mais il y à peu être une couche qui merde au niveau framework genre kio pour plasma, gvfs pour les bureaux gtk ou je sais pas quoi d'autre...

Vous vous prenez trop la tête, c'est un problème du noyau, cf https://bugzilla.kernel.org/show_bug.cgi?id=12309

C'est un problème équivalent mais si les mecs font le rapport sur la page du 3.3, je ne sais pas si cela va le faire d'autant plus qu'elle est fermée.

Il y à du monde qui utilise F2FS comme système de fichier principal ?
J'ai encore jamais essayer et j’hésite.
 
Il y à un article récent sur https://www.phoronix.com/scan.php?p [...] tems&num=1  

j'utilise que du ext4,  
 
le F2FS a été conçu à destination des unités de stockage utilisant la mémoire flash :
https://korben.info/f2fs-systeme-de [...] aller.html
https://en.wikipedia.org/wiki/F2FS

J'ai une question concernant l'UEFI ; j'ai acheté un nouveau PC portable que je vais recevoir la semaine prochaine, qui a Windows 10 préinstallé. Du coup, j'imagine qu'il est en UEFI.

J'ai installé plein d'Arch en mode Bios, mais jamais en UEFI. L'idée serait de remplacer le Windows 10 par Arch, en mode UEFI (vu que Windows sera déjà dans ce mode-là) (à la base je voulais faire un dual boot, mais ça m'a l'air un peu compliqué vu que je n'y connais rien en UEFI pour l'instant).

C'est facile ? Quelles sont les étapes, grosso modo, à suivre ? Est-ce qu'il suffit de formater la partition Windows 10 en Ext4 et voilà ? Quid de la partition EFI, est-ce qu'il faut en recréer une ou celle qui existe avec Windows fait l'affaire ? Et est-ce qu'il y a mieux que Grub pour gérer l'UEFI ?

Bon, j'ai déjà la réponse à une de mes questions sur le wiki français, page de l'EFI :  
 

 
C'est déjà ça de moins à faire, en gros il faut simplement penser à monter cette partition.

Tu as les tutos de Fred Bezies sinon
 
https://www.youtube.com/watch?v=3h5nOFkk1sg
 
http://frederic.bezies.free.fr/blog/?p=17815

Justement j'ai regardé, son tuto ne mentionne pas le cas où une partition ESP existe déjà, lors de la préinstallation d'un Windows par exemple.

la partition EFI ? c'est tout simple, les dossiers nécessaire à chaque OS se mettent dedans.  
Je pense que tu as juste besoin de reduire la partition windows et lancer une installation de Arch. Mais il faudrait mieux faire une image disque avant de bidouiller.
Dans mon cas sur mon vieux Dell, c'est avec le bios que tu choisis quel système lancer, mais tu peux aussi lancer windows depuis grub, c'est encore plus simple.

Pour l'UEFI il faut déja que la table de partitionnement de ton SSD/HDD soit converti au format GPT si c'est pas le cas (l'autre format, plus ancien c'est MBR). Cela se fait une seul fois, grosso-modo avant la création des partitions. (Je ne sais plus si on peu faire la conversion à chaud sans devoir tout effacer, bref à voir si tu t'en fou ou pas)
 
Après au niveau des partition il faut que ta première partition soit celle qu'on appel ESP (c'est juste une partition d'une taille recommandée de~550Mio au formaté en vfat)
Ça permet à ton BIOS d'y accéder.
 
Pour l'install après c'est comme d'habitude, Les guides "recommandent" de monter la partition ESP dans "/boot/ESP" mais si t'à pas besoins de faire dans l’exotique tu peu très bien faire plus simple te servir directement de ta partition ESP monter en /boot
 
Dans les guides celui de Arch est très bien : https://wiki.archlinux.org/index.ph [...] _Interface
 
 
Pour le démarrage après, soit tu reste dans le classique en installant un bootloader (grub & co) comme d'habitude, soit, tu peu essayer de complètement t'en passer si ton matos te le permet en essayant de boot directement sur ton kernel.
La 2eme méthode s'appel EFISTUB (https://wiki.archlinux.org/index.php/EFISTUB)
(C'est l'avantage d'être en GPT/ESP)
 
Le choix ce fait / ce permute en fait dans ton BIOS en indiquant quelle fichier te sert à boot :
soit tu pointe sur le fichier générer par grub pour passer par lui / soit tu pointe sur ton kernel (avec les paramètres qui vont bien)
 
tu peu très par exemple boot en EFISTUB si ça marche mais avoir grub d'installer à coté en secours (et vis versa)  
 
 
 
PS : est après tout ça tu à encore un autre truc possible qui s'appel le secure boot (https://wiki.archlinux.org/index.php/Secure_Boot) qui viens en surcouche à tout ce que tu à fait précédemment mais ça j'ai jamais essayer de le mettre en place.C'est une option à activer dans ton BIOS + d'autres manips à faire dans nux.

C'est complètement glucose  

 
 
C’était essentiellement pour expliquer que c'est indépendant et que l'un n’empêche/n’écrase pas l'autre.  
 
Si l'EFISTUB marche bien out of stock c'est pas utile mais après ta toujours des bios de merde, même en 2018, qui font que passer par un bootloader classique reste utile  
(ein Dell ein ein, c'est pour quand un BIOS qui prennent en compte les paramètres passés au kernel    )

Ah non mais merci pour l'explication, moi l'uefi ya pas à faire ça rentre pas. (Bon j'ai jamais été personnellement confronté au problème). Si quelqu'un me demande, je fuis

si ton disque dur fait moins de 2.2 To, que tu veux supprimer windows 10 et que tu ne veux pas utiliser UEFI :

- activer le mode "bios legacy" dans ton bios, s'il existe, si c'est pas le cas alors inutile d'aller plus loin
- partitionner ton disque en mbr
- installer archlinux et grub

si ton portable est fourni avec un numéro de licence windows 10 compatible avec les images iso de windows 10 (téléchargeable légalement sur le site de microsoft) alors tu peux tenter de le virtualiser sous archlinux avec qemu,
j'ai tenté le coup, ça marche mais c'est hyper lent (j'ai un vieux PC, ton portable encaissera peut-être mieux l'effort de virtualisation),

UEFI pour moi ça vaut le coup que si tu as des disques de plus de 2.2 To, ceci dit bientôt on aura plus le choix :
https://www.anandtech.com/show/1206 [...] fi-by-2020

Tous les PC avec un W10 pré-installé disposent d'une licence intégrée qui permet de télécharger l'ISO de W10    
Il n'y a pas à se poser de question de ce point de vue la ( d'autant plus que cet ISO est dispo pour tout le monde et tous les OS )
On peut même supprimer complétement Windows de la machine, la licence perdurera.
Faut juste vérifier avant suppression que W10 est en licence numérique, et c'est bon.

Merci pour vos réponses, je reçois le PC lundi, je verrai à ce moment-là. L'idée est bien d'utiliser UEFI et non d'utiliser le BIOS Legacy.

Je crois que certains cartes mères permettent d'utiliser un double système EFI et Bios en mettant.  
 
Quid du cas des doubles disque dur? Un pour Windows et un pour Linux avec la solution de choisir soit même son boot via F8?

oui ça devrait marcher, c'est ce que j'avais fait au moment de ma transition "windows xp vers archlinux" (j'ai zappé windows 7) il y a quelques années,

je ne suis pas très fan du multiboot, qui a un coté un peu désuet et compliqué par rapport aux alternatives comme la virtualisation ou le programme wine, à moins d'être un amateur de jeux vidéos windowsien

Quelle galère l'UEFI avec rEFInd, quand ça ne marche pas du premier coup.

Le script refind-install me montait ma clé USB d'installation d'Arch comme répertoire root, du coup ça ne bootait pas... Le temps de m'en apercevoir, de comprendre, de corriger, j'y ai passé la journée d'hier...  

Aujourd’hui, les MAJ ont entraîné un changement dans les thèmes Adwaita : ils sont globalement plus clairs qu’avant… mais uniquement dans les applications GTK3 (et sur XFCE, ça ne s’applique pas aux barres de titre).
 
De fait, ça entraîne une perte de cohérence visuelle entre applis Qt-GTK2 et GTK3 (du moins, si on utilise les thèmes Adwaita ; sachant qu’avec GTK3, ce n’est plus un thème mais une feuille de style CSS), et à titre personnel, j’aimais bien comme c’était avant.
 
S’il y a moyen de retrouver les thèmes Adwaita d’antan, ce serait cool. Au pire, je me ferai au changement, mais j’aurais au moins aimé qu’il fût généralisé et pas limité qu’à certaines applications et pas à toutes…

je remarque aussi un fond beaucoup plus clair au niveau du gris dans les applications qui utilisent ce thème adwaita, ça fait un peu mal aux yeux

@tromzy :
 
Pour installer en UEFI, rien de plus simple :
1- Tu crées une partition de 100Mo, (ex /dev/sda2)
2- Tu formates en Fat32 via un "mkfs.vfat -F32 /dev/sda2
3- Tu crées le répertoire /boot/efi et tu montes la partition que tu viens de créer => mount -t vfat /dev/sda2 /boot/efi
4- Tu installes "grub" et "efibootmgr"
5- Tu crées le fichier efi adéquate => grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=archlinux --recheck
6- Tu crées le fichier grub.cfg comme d'habitude => grub-mkconfig -o /boot/grub/grub.cfg
 
Pour Arch, rien de plus simple. FredBeziers c'est un boulet car se prend pour le Dieu d'Arch et même pas capable de faire une installation en UEFI. Il gueule sans cesse au gens de lire le Wiki d'Archlinux alors qu'il suffit de lire la page Grub du wiki Fr ou c'est correctement expliqué pour un cas d'installation sur une partition GPT avec un ESP

on peut aussi s'entrainer sur une machine virtuelle pour le boot uefi,  
https://wraihan.com/posts/install-a [...] ed-for-vm/
https://wiki.archlinux.org/index.ph [...] ve_support
 
une fois la technique maîtrisée on tente alors le coup sur un PC physique

attention énorme bug dans les dernières mises à jour concernant qt5 version , ça fait planter kde/plasma au prochain reboot  

on est pour l'instant que deux à avoir rapporté le problème :
https://bugs.archlinux.org/task/61638

j'ai été contraint de downgrader les paquets qt5-*** (5.12.1-1 --> 5.12.0-3), 25 paquets qt5 à downgrader,

le problème n'apparait que si on reboot après avoir fait la mise à jour de qt5, au reboot on constate que plasma est extremement lent à démarrer, avec le bureau qui s'affiche qu'à moitié (il manque la barre des tâches en bas), la souris qui ne bouge plus, la led disque dur qui s'allume en permanence, et un message d'erreur indiquant qu'une partition n'est plus accessible,

si j'ouvre un terminal (ctrl-alt-f2) je constate pourtant que la partition mentionnée par le message d'erreur est accessible, je ne trouve rien d'anormal dans dmesg,

du coup la seule solution c'est de downgrader qt5 vers la version 5.12.0.3

si j'utilise le thème "breeze" (brise en version française) alors le bug disparait, tout redevient ok,
 
si j'utilise le thème "oxygen" alors le bug réapparaît avec la dernière version de qt5, il se peut que le problème apparaisse aussi avec d'autres thèmes de bureau plasma

Oh purée, Je viens de redémarrer, j'ai eu du bol, je suis en brise sombre.
et j'avais bien la mise à jour : 5.12.1-1

avec Kvantum j'ai pas constaté de problème (Arch / KDE / qt5-base 5.12.1-1)
tu à essayé de virer le cache ?

j'ai testé avec un nouvel utilisateur (profil kde vierge) :

- avec le thème brise et qt5 5.12.1 --> pas de problèmes
- avec le thème oxygen et qt5 5.12.1 --> après un re-démarrage le bureau se freeze (souris qui ne bouge plus), la led du disque dur qui s'affole

à noter que pour avoir le problème il faut redémarrer ou se déconnecter, puis se connecter à une nouvelle session kde pour observer le problème avec le thème oxygen, au niveau compositeur l'accélération openGL 2.0 est utilisée pour plasma, pas de wayland à priori (je ne pense pas l'avoir activé),

le thème de bureau oxygen pour ceux qui veulent tester la reproductibilité du bug (pas garantie, j'ai testé avec le pilote libre radeon et une carte radeon hd4650, il se peut que le bug ne se produise pas avec un pilote et une carte différente) :
https://www.archlinux.org/packages/extra/x86_64/oxygen/

faites le test qu'après avoir crée un compte utilisateur de test, pas dans votre compte habituel,

il existe un autre bug pour ceux qui utilisent un pilote nvidia et une configuration bi-écran : le bureau kde ne se charge pas lorsqu'on a installé qt5 5.12.1, et ce quelque soit le thème de bureau choisi

il a l'air pas mal ce thème de bureau kvantum, un thème en 3D à la oxygen, qui prend le contre-pied de la tendance actuelle du flat-design (android, windows 10),
https://store.kde.org/p/1005410/

son seul défaut d'après la capture d'écran c'est qu'il utilise un fond sombre, est-ce qu'il existe une variante proche d'oxygen avec un peu plus de couleurs, et du gris métal comme arrière plan plutôt que le noir ?

Qui peut me faire un "What is the output of "pacman -V|base32|head -1" que je puisse m'inscrire sur leur wiki à la con
Je vais pour éditer un truc et je peux pas m'inscrire

BIQC4LJNFYQCAIBAEAQCAIBAEAQCAIBAEAQCAICQMFRW2YLOEB3DKLRRFYZCALJANRUWEYLMOBWS

 
la plupart des thèmes disponibles sont sur Opendesktop.org,  
kvantum propose de base 10-20 lorsque tu l'installe et sinon il en a peu etre quelques autres qui traînent sur github / reddit
 
 
C'est vraiment un très bon moteur de thème, j'ai réaliser ceux là mais c'est du flat   (ils sont aussi sur opendesktop):
https://github.com/Rokin05/darkine-kde
https://github.com/Rokin05/midnight-kde
https://github.com/Rokin05/nocturnal-kde
https://github.com/Rokin05/starcraft-kde

le bug semble confirmé par des utilisateurs d'archlinux, ils ont trouvé une consommation mémoire très excessive quand ils utilisent le thème oxygen dans kde-plasma et lorsque Qt5 5.12.1 est installé :
https://bbs.archlinux.org/viewtopic.php?pid=1830703

ça explique le bureau gelé (pointeur de souris qui ne bouge quasiment plus), la lenteur excessive, car le swap disque est alors utilisé vu que la ram est saturée,
en downgradant vers la version 5.12.0 le problème disparaît,

la difficulté c'est de trouver le composant Qt5 qui crée ce problème, pas évident car je n'ai pas réussi à trouver d'informations utiles dans les logs, ça semble être un bug qui ne laisse pas de traces dans les logs

j'ai fait un git bisect et j'ai trouvé le commit qui crée ce bug de fuite mémoire quand on utilise le thème oxygen :

https://github.com/qt/qtbase/commit [...] 339639ca79

j'ai crée un patch qui annule ce commit, le bug disparait alors, tout est ok, j'ai crée un PKGBUILD avec le patch pour reconstruire le paquet qt5-base, vous pouvez le télécharger ici :
https://bugs.archlinux.org/task/61638?getfile=17204

C'est tip top Cantata pour gérer sa bibliothèque de musiques, merci Fred Bezies    
 
http://frederic.bezies.free.fr/blog/?p=18534

Plasma 5.15 est sorti il y a à peine quelques heures et est déjà dispo sur Arch :  
 
https://www.kde.org/announcements/plasma-5.15.0.php