Comment puis-je défragmenter mon SSD sous Linux?

En général, vous pouvez simplement ignorer la fragmentation. Plus encore pour les SSD qui ne souffrent pas de time de search comme le disque dur. La défragmentation d'un disque SSD ne fera rien d'autre que des cycles d'écriture perdus.

Bien qu'il puisse y avoir des cas extrêmes où la fragmentation a un effet notable, comme un file fragmenté écrit dans un ordre random (comme le font certains clients BitTorrent), ou lorsque le disque est à court d'espace libre, lorsque le dernier file écrit être divisé en milliers de fragments car il n'y avait pas d'autre espace consécutif disponible pour répondre aux besoins.

Mais c'est l'exception. Cela n'arrive pas habituellement. La plupart des filesystems sont très efficaces pour éviter la fragmentation, et le kernel Linux est bon pour éviter les effets néfastes causés par la fragmentation. Une fois que plus d'un process de lecture / écriture de files concurremment, le disque devra être partout à la fois de toute façon.

Il n'y a pas trop de solutions de défragmentation pour Linux. XFS a xfs_fsr qui fonctionne très bien, donc si vous voulez absolument utiliser la défragmentation, XFS est un bon choix.

Vous pouvez vérifier la fragmentation des files en utilisant filefrag ou hdparm :

 # filefrag debian-6.0.6-amd64-netinst.iso debian-6.0.6-amd64-netinst.iso: 4 extents found # hdparm --fibmap debian-6.0.6-amd64-netinst.iso debian-6.0.6-amd64-netinst.iso: filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 3003928 3072407 68480 35061760 2872856 2938391 65536 68616192 2171576 2302647 131072 135725056 56259072 56338047 78976 

Si cela ne vous donne pas des centaines ou des milliers d'étendues (fragments), il n'y a rien à craindre.

Une méthode de défragmentation générique consiste à faire une copy du file, puis à replace l'original, par exemple:

 cp -a yourfile yourfile.defrag mv yourfile.defrag yourfile 

Votre système de files devrait avoir une bonne quantité d'espace libre, sinon la probabilité est élevée que le nouveau file sera aussi fragmenté que l'ancien. (Vérifiez si le nouveau file est meilleur que l'ancien avant de le replace).

Mais comme je l'ai dit, il n'est généralement pas nécessaire de le faire à less qu'un file n'ait vraiment un cas de fragmentation.

D'autres ont mentionné que la défragmentation pourrait ne pas avoir d'effet sur le SSD. (Je me rends count que c'est une vieille question, mais j'aimerais append un context.)

Je voudrais avancer une version plus forte du même argument: le concept de défragmentation n'a aucun sens pour SSD du tout. Le SSD n'écrit pas de blocs logiques séquentiels sur des blocs séquentiels en flash; afin de maximiser le débit, le controller SSD va répartir les blocs sur plusieurs puces NAND (un peu comme un mini-RAID).

Voir: http://www.anandtech.com/show/2829/5

Le controller SSD détermine où écrire des blocs pour la meilleure vitesse et aussi de porter chaque cellule flash uniformément. Par conséquent, même les blocs logiques qui apparaissent (à l'OS) dans l'ordre séquentiel sont effectivement stockés dans un ordre complètement différent sur NAND – et c'est une bonne chose. L'idée de défragmenter quelque chose qui est supposé être fragmenté n'a aucun sens.

L'auteur de l'article vend snakeoil. Il est vrai que vous verrez une baisse de performance sur un SSD si vous faites un IO de petit bloc (4k) complètement random, cela ne se produit jamais en pratique, même sur des filesystems Windows notoirement mal fragmentés. L'effet de la fragmentation sur un disque SSD est quelque chose de l'ordre de 100 à 1000 fois less qu'un disque dur. Une search introduite même tous les 64k a un impact négligeable sur le débit sur un SSD. Lorsque vous considérez que les filesystems Linux ne se fragmentent pas suffisamment en pratique pour nécessiter une défragmentation même sur un disque dur, le fait que les écritures introduites par toute tentative de défragmentation réduisent la durée de vie du disque doit être évité.

Si vous insistez pour défragmenter ext [234], vous pouvez le faire avec l'ancien programme e2defrag .

Pour ext4 la défragmentation est appelée e4defrag . (Il fait maintenant partie des e2fsprogs officiels).

Il y a aussi une command fssortingm qui devrait fonctionner à la fois sur ext4 et (je pense) xfs . Il envoie des requests de rejet pour l'espace inutilisé sur le système de files. Cela pourrait s'avérer particulièrement utile si votre système de files n'était pas monté avec -o discard (c.-à-d. Envoi immédiat de files supprimés pour les files supprimés).

Rien de tout cela ne s'installe automatiquement. À less que vous ne soyez très inhabituel, vous n'avez pas besoin d' e4defrag .

Le truc TRIM est plus pertinent. Il a été désactivé par défaut parce que l'histoire de la performance à l'époque était vraiment peu claire (c.-à-d. Qu'elle permettait parfois de grands ralentissements). Désolé, c'est linux w / nouveau matériel :). J'ai tendance à activer l'option de assembly de mise au rebut au moment de l'installation, et je n'ai pas vu de pauses horribles lors de la suppression de files. (SSD Crucial m500).

Si vous lisez les avis SSD, la plupart d'entre eux fonctionnent mieux si vous ne les gardez pas à 100% plein :). Ce n'est pas obligatoire, mais une seule façon de réserver l'espace (par ex. 10%) et d'empêcher son utilisation n'est tout simplement pas d'allouer l'intégralité du périphérique lorsque vous le partitionnez.

La fragmentation est mauvaise pour les disques SSD car elle provoque une amplification en écriture (les SSD doivent copyr des blocs d'effacement entiers pour des écritures beaucoup plus petites, les SSD récents de faible qualité pouvant aller jusqu'à 2 Mo de blocs d'effacement). La défragmentation n'est pas non plus une bonne idée, car elle ne fait que passer à travers les cellules pour rendre la prochaine écriture un peu plus rapide (votre lien fait ce point: juste parce que la fragmentation est mauvaise, cela ne signifie pas que la défragmentation est meilleure).

Au lieu de cela, vous devriez vous concentrer sur l'utilisation d'un système de files qui ne cause pas de fragmentation. XFS / ext4 / Btrfs preallocate des extensions entières. Les filesystems structurés en log (nilfs2, f2fs) sont aussi bons. Si vous le configurez avec la taille de bloc d'effacement correcte, bcache se comporte également comme un système de files structuré par un journal.

L'outil que vous searchz est fssortingm . Il peut être programmé tous les jours, toutes les semaines ou pendant la nuit si vous n'éteignez pas votre ordinateur portable / server:

 cat /etc/cron.weekly/01-fssortingm #!/bin/sh fssortingm / fssortingm /home chmod +x /etc/cron.weekly/01-fssortingm 

Essayez d'exécuter le script maintenant, il ne devrait pas imprimer de message d'erreur. Si vous avez changé la configuration LUKS, vous devrez peut-être redémarrer avant de faire cela.

http://lukas.zapletalovi.com/2013/11/how-to-sortingm-your-ssd-in-fedora-19.html

Il y a un guide de l'user de chaque fabricant de disque dur, et j'ai lu un tel. Ce n'est pas une bonne idée de défragmenter le SSD. Il n'y a pas de pièces mécaniques dans le SSD comme dans le HDD-s et l'organisation de DATA est un autre type. La search de données dans SSD est différente et pas besoin d'être défragmenté. La vie de SSD sera plus courte, si-défragmenter fréquemment. Par exemple: http://download.intel.com/support/ssdc/hpssd/sb/intel_ssd_toolbox_30_user_guide.pdf Si le lien ne fonctionne pas, vous devez essayer dans google "GUIDE DE L'UTILISATEUR SSD". Le guide de l'user est évident, il n'y a pas besoin de défragmenter. Peu importe le operating system, le lecteur SSD fonctionne de la même façon, c'est ainsi que ce matériel fonctionne.