Dois-je utiliser btrfs ou Ext4 pour mon SSD?

Dois-je utiliser btrfs (avec les options discard, compress = lzo et space_cache) ou Ext4 (avec option discard) pour le SSD pour ma partition racine de bureau amd64 Ubuntu 11.10 (Oneiric) de ma machine de bureau?

/ home sera un disque dur, donc la fiabilité de fs affecte le système d'exploitation et non mes données.

Selon les tests de Phoronix cela dépend toujours de nombreux facteurs. Dans un cas, ce Btrfssera beaucoup mieux que EXT4lors de la lecture de gros fichiers sur un SSD. De même, tout en considérant les performances des transactions sur disque, Ext4peut être plus performant que les versions ultérieures.

Vous pouvez consulter ces tests ici , ici et ici (AVERTISSEMENT: longs articles).

Mais en résumé, Btrfs n'a actuellement pas d'avantage quantitatif sur les performances par rapport au système de fichiers EXT4 , même en mode SSD.

Vous pouvez donc choisir Ext4pour le moment.

Pour ceux qui sont tombés sur cette question en 2016 ... Utilisez ext4. J'ai essayé btrfs et la différence est substantielle. Sur une période de 10 jours, les EI d'écriture sur ext4 représentaient 17 800 secteurs. Btrfs? 490 400 secteurs. Même SSD, système de fichiers identique, différentes partitions. Fondamentalement, même charge de travail.

Ext4 et btrfs deviennent "silencieux" lorsqu'il n'y a aucune activité d'écriture sur le lecteur. C'est bon.

Ext4 écrira les données modifiées, plus des frais généraux. Les frais généraux concernent les données écrites. Une écriture 4K (1 bloc) pousse environ 50 à 80 blocs de surcharge lors de la prochaine validation. (Le journal ext4 est entièrement activé)

Modifiez un seul bloc 4K sur btrfs et vous pousserez entre 4000 et 5000 blocs de surcharge lors du prochain commit. La validation par défaut est de 30 secondes, je crois. J'en ai utilisé 120.

Maintenant, cela dépend de la façon dont vous utilisez le SSD. En tant que root, il y a généralement un flux d'écritures assez constant et de bas niveau. Fichiers journaux, fichiers de dérive ntp, reconstructions man db, mises à jour de topologie opensm, etc., etc. Chaque événement martèlera un lecteur btrfs avec encore 4000 à 5000 écritures.

Les numéros de 10 jours ci-dessus sont pour mon SSD "écriture limitée". La majeure partie de ces 17 800 secteurs sont le résultat d'une mise à jour du système de petite taille. Une copie de btrfs n'a pas souffert. Mes rédacteurs sont, exactement, ntp drift, opensm topology et man db updates (nightly). Rien d'autre ne frappe ce disque, à l'exception de choses initiées activement comme les mises à niveau du système,vim /etc/whatever , etc.

Sur les SSD entiers, beaucoup d'écrits souffriront vraiment. Je ne vois pas l'intérêt de les gaspiller, car les médias chassent les lapins et les arcs-en-ciel. Si vous voulez payer ce prix pour COW, allez-y. Pour la "performance", pas tant que ça. C'est un SSD et vous pourriez probablement y installer le pire "système de fichiers" connu de l'homme, tout en obtenant un certain niveau de performances - juste par la force brute. Ext4 n'est, de loin, pas le pire système de fichiers connu de l'homme.

Pas de vérification fs mensuelle. Essayez le script ci-dessous. C'est un hack à 100%, ne fonctionnera pas pour les points de montage md,

#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
    vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
    lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
    if [ "$vm" != "$vmx" ]
    then
        tim=`date +%s`
        dif=`dc <<< "$vm $vmx - p"`
        lbad=`dc <<< "$lba $lbax - p"`
        timd=`dc <<< "$tim $timx - p"`
        echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
        vmx="$vm"
        lbax="$lba"
        timx="$tim"
        find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
        touch "$tmpnam" 
    fi
    sleep 1 
done

Il vous dira combien de blocs ont été écrits, selon le lecteur lui-même, et exactement quels fichiers ont été mis à jour. Besoin de privilèges root. Voir par vous-même. J'exécute SSD sur le système de fichiers racine et appelle le script stat.sh. Donc...sudo ./stat.sh /

La dernière fois que je l'ai testé, et je n'ai encore rien entendu de différent, ext4 mange supports à semi-conducteurs. (clés USB, disques SSD, etc.) Je ne recommande pas de l'utiliser sur un tel appareil. Utilisez plutôt ext3. Pour la plupart des cas sur SSD, vous ne pourrez pas faire la différence de toute façon.

BTRFS n'est pas encore assez stable. Cependant, il est suffisamment stable pour les applications non critiques. C'est ce que j'utilise pour créer des lecteurs flash amorçables. Si vous utilisez compress = zlib et ssd comme options de montage, la compression compensera les vitesses d'écriture plus faibles de la plupart des supports à semi-conducteurs et le ssd change l'algorithme d'allocation en un algorithme qui fonctionne nettement mieux sur ces périphériques et compensera tout mauvaise usure par le matériel. Le seul domaine de performances qui reste un problème est que les appels de synchronisation sont lents. Ce n'est pas un problème pour une utilisation générale, mais dpkg appelle la synchronisation après chaque opération, donc l'installation et la mise à jour du logiciel peuvent être lentes. BTRFS propose également des instantanés et d'autres fonctionnalités avancées qui sont très utiles dans certaines circonstances.

Si vous décidez d'utiliser BTRFS, assurez-vous d'utiliser une distribution utilisant le noyau 3.2.0-2 ou une version ultérieure. 3.1.x est réalisable si nécessaire. Pour les noyaux plus anciens, vous devrez compiler les derniers modules BTRFS vous-même. Les versions intégrées sont presque stables, mais la correction d'erreur ne fonctionne pas dans les anciennes versions, ce qui peut vous laisser un ruisseau en cas de problème. Les dernières versions ont fsck qui peut réellement réparer les défauts les plus courants.

Une dernière mise en garde, j'ai entendu des rapports que les fichiers d'échange sur un système de fichiers BTRFS le corrompraient. Ce problème a peut-être été résolu, mais assurez-vous de vérifier attentivement avant d'en implémenter un.

Si vous avez besoin d'aide pour configurer une configuration BTRFS comme vous le souhaitez, faites-le moi savoir. J'en ai fait quelques fous qui fonctionnent plutôt bien pour des choses spécifiques.

Je n'utiliserais pas ext4 sur un disque SSD basé sur des preuves anecdotiques et ma propre expérience qui suggère que ext4 peut considérablement réduire la durée de vie d'un SSD en raison du nombre de lectures et d'écritures associées au système de fichiers. Un article que j'ai lu récemment suggérait qu'ext4 non optimisé (en tenant compte de la taille de la page, etc.) sur un SSD pouvait réduire de moitié la durée de vie du disque. Après une semaine de dépannage, je suis arrivé à la conclusion que mes propres SSD n'ont duré que huit mois en raison de ce problème. Si vous utilisez un SSD, faites beaucoup de lecture sur la façon d'optimiser le système de fichiers en fonction de choses comme la taille de la page flash qui peut être différente de la taille de cylindre typique pour laquelle le système de fichiers est configuré.