# [Résolu] [btrfs] problème de lenteur en écriture/destruction

## d2_racing

Salut tout le monde, depuis que j'utilise btrfs avec mon Intel SSD 520 serie, j'ai remarqué que Btrfs vérouille mon système lorsque je lance des emerge -C.

C'est assez pénible, car ça gèle carrément mon ordi quand ça arrive.

De plus, lorsque je lance des snapshots, ceux-ci prennent entre 10 secondes et 10 minutes pour s'exécuter.

J'utilise présentement ces options :

```

/dev/sda4      /                btrfs      defaults,noatime,ssd,discard,compress=lzo,subvol=@racine 0 1

```

Est-ce que EXT4 serait mieux et si oui, on utilise quels options de montage quand on a un SSD qui date de 2012 ?

J'ai pensé à ceci, sauf que je ne suis pas certain :

```

/dev/sda4      /                ext4      defaults,discard,noatime, 0 1

```

Merci !Last edited by d2_racing on Wed Dec 19, 2012 1:10 pm; edited 2 times in total

----------

## guilc

Pour ext4, je dirais, histoire d'utiliser TRIM :

```
discard         Controls whether ext4 should issue discard/TRIM

nodiscard(*)        commands to the underlying block device when

            blocks are freed.  This is useful for SSD devices

            and sparse/thinly-provisioned LUNs, but it is off 

            by default until sufficient testing has been done.
```

Concernant data=ordered, c'est le défaut, donc inutile de le préciser.

Et pour btrfs, aucune idée, tant que ce n'est pas marqué stable, je touche pas. J'ai vu passer trop de pertes de données dessus  :Mr. Green: 

----------

## El_Goretto

Je confirme pour discard et noatime, mes 2 options préférées  :Smile: 

----------

## d2_racing

J'ai trouvé quelque chose d'intéressant je pense :

```

 read  writ|files  inodes

   0   408k| 2784   7264 

   0   460k| 2784   7264 

   0   496k| 2784   7264 

   0   424k| 2784   7264 

   0   440k| 2784   7264 

   0  1280k| 2784   7264 

   0   500k| 2784   7264 

   0   592k| 2784   7264 

   0   600k| 2784   7264 

   0   568k| 2784   7264 

   0   792k| 2784   7264 

   0   756k| 2784   7264 

   0   480k| 2784   7264 

   0   592k| 2784   7264 

   0   432k| 2784   7264 

   0   544k| 2784   7264 

   0   512k| 2784   7264 

   0  2912k| 2784   7264 

   0  3332k| 2784   7264 

   0    40M| 2784   7264 

   0    52M| 2784   7264 

   0  1280k| 2784   7264 

   0    69M| 2784   7264 

-dsk/total- --filesystem-

 read  writ|files  inodes

   0  5584k| 2784   7264 

   0   784k| 2784   7264 

   0   624k| 2784   7264 

   0   616k| 2784   7264 

   0   744k| 2784   7264 

   0   736k| 2784   7264 

   0   652k| 2784   7264 

   0   540k| 2784   7264 

   0   752k| 2784   7264 

   0   780k| 2784   7264 

   0   888k| 2784   7264 

   0   480k| 2784   7264 

   0   504k| 2784   7264 

   0   548k| 2784   7264 

   0   892k| 2784   7264 

   0   580k| 2784   7264 

   0   576k| 2784   7264 

   0   636k| 2784   7264 

   0   544k| 2784   7264 

   0   760k| 2784   7264 

   0   752k| 2784   7264 

   0   648k| 2784   7264 

   0   744k| 2784   7264 

-dsk/total- --filesystem-

 read  writ|files  inodes

   0   516k| 2784   7264 

   0   608k| 2784   7264 

   0   672k| 2784   7264 

   0   524k| 2784   7264 

   0   524k| 2784   7264 

   0   520k| 2784   7264 

   0   476k| 2784   7264 

   0   520k| 2784   7264 

   0   568k| 2784   7264 

   0   520k| 2784   7264 

   0   548k| 2784   7264 

   0   616k| 2784   7264 

   0   832k| 2784   7264 

   0   824k| 2784   7264 

   0   700k| 2784   7264 

   0   864k| 2784   7264 

   0  1208k| 2784   7264 

   0  1064k| 2784   7264 

   0   588k| 2784   7264 

   0   688k| 2784   7264 

   0    41M| 2784   7264 

 308k   17M| 2784   7269 

7488k  456k| 2784   7268 

-dsk/total- --filesystem-

 read  writ|files  inodes

8192B  496k| 2784   7268 ^C

```

Quand le snapshot s'exécute, on voit le nombre d'octets monter en flèche.

Voici un exemple que j'ai fait cette après-midi.

```

gentootux ~ # mount /dev/sda4 -o noatime,ssd,discard,compress=lzo,noacl,space_cache,subvolid=0 /mnt/disklayout/ 

gentootux ~ # cd /mnt/disklayout/

gentootux disklayout # ls

@backup  @racine

gentootux disklayout # time btrfs subvolume delete @backup

Delete subvolume '/mnt/disklayout/@backup'

real   0m0.005s

user   0m0.001s

sys   0m0.002s

gentootux disklayout # ls

@racine

gentootux disklayout # time btrfs subvolume snapshot @racine @backup

Create a snapshot of '@racine' in './@backup'

real   0m2.850s

user   0m0.000s

sys   0m0.010s

gentootux disklayout # ls

@backup  @racine

gentootux disklayout # time btrfs subvolume delete @backup

Delete subvolume '/mnt/disklayout/@backup'

real   0m0.001s

user   0m0.000s

sys   0m0.000s

gentootux disklayout # time btrfs subvolume snapshot @racine @backup

Create a snapshot of '@racine' in './@backup'

real   3m53.616s

user   0m0.000s

sys   0m0.299s

```

On est passé de très rapide à très lent.

----------

## d2_racing

J'ai posté sur la liste officiel de btrfs et il semble que c'est plus sage d'ajouter la commande sync quand on crée ou quand on détruit un snapshot.

----------

## d2_racing

Enfin, dans mon cas, je pourrais enlever le paramètre discard de mon fstab et lancer manuellement fstrim / -v de temps en temps.

J'ai fait le test et ça ne lagge plus quand je lance un emerge -C sur un package.

C'est bizarre de voir qu'un paramètre peut autant ralentir les accès sur le disque.

Il parait que les SSD aujourd'hui sont en mesure de faire des trims automatiquement.

----------

## El_Goretto

 *d2_racing wrote:*   

> Il parait que les SSD aujourd'hui sont en mesure de faire des trims automatiquement.

 

Oui et non, c'est un mécanisme interne de garbage collector qui peut exister, suivant les contrôleurs (donc plus ou moins performant). Donc dans le cas du btrfs, j'ai envie de dire non, à la lecture de cette explication.

Il existe aussi des commandes pour faire un trim "à la mano" avec hdparm (je n'ai plus le lien, mais j'avais du coller çà dans un thread sur le fofo).

Oui, le trim/discard peut ralentir un pouillème (par rapport à "sans", pour une même opération E/S), mais à ce point là, ça m'épate un peu beaucoup. Je n'ai absolument pas de problème avec un emerge -C de mon côté sur du ext4.

Faut se méfier de btrfs quand même, je me rappelle d'un bench où le mode SSD était plus lent que le mode normal, sur un SSD  :Smile: 

--

edit: l'article wikipedia a l'air de dire que, définitivement, non, le GC, ça ne trim pas/plus du tout (cf File-system aware GC).

----------

## d2_racing

Tu as raison, hier soir, j'ai fait un Rsync de mon installation sur mon disque dur externe et j'ai testé ceci avec EXT4 :

```

/dev/sda4      /                ext4       defaults,noatime,discard                    0 1

```

J'ai vu une nette différence.

Je n'ai plus de problème lors des emerge -C et même lorsque je ferme mon ordinateur, il n'y a plus de lagge.

C'est comme si le TRIM sous EXT4 était nettement supérieur à celui qui est développé sous BTRFS.

Bref, je garde un oeil sur BTRFS mais pour le moment, je vais passer mon tour.

----------

