| View previous topic :: View next topic |
| Author |
Message |
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
 Posted: Sat Dec 15, 2012 6:37 am Post subject: [Résolu] [btrfs] problème de lenteur en écriture/destruction |
 |
|
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 :
| Code: |
/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 :
| Code: |
/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 |
|
| Back to top |
|
 |
guilc
Bodhisattva
Joined: 15 Nov 2003
Posts: 3326
Location: Paris - France
|
| Posted: Sun Dec 16, 2012 9:33 am Post subject: |
|
|
Pour ext4, je dirais, histoire d'utiliser TRIM :
| Code: | 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 
_________________
Merci de respecter les règles du forum.
Mon site perso : https://www.xwing.info
Mon PORTDIR_OVERLAY : https://gentoo.xwing.info ou layman -a xwing |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Sun Dec 16, 2012 11:08 am Post subject: |
|
|
Je confirme pour discard et noatime, mes 2 options préférées 
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Sun Dec 16, 2012 8:40 pm Post subject: |
|
|
J'ai trouvé quelque chose d'intéressant je pense :
| Code: |
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.
| Code: |
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. |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Tue Dec 18, 2012 1:30 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Wed Dec 19, 2012 2:33 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Wed Dec 19, 2012 9:46 am Post subject: |
|
|
| 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
--
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).
_________________
-TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Wed Dec 19, 2012 1:09 pm Post subject: |
|
|
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 :
| Code: |
/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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
