Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Résolu] [btrfs] problème de lenteur en écriture/destruction
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index French
View previous topic :: View next topic  
Author Message
d2_racing
Moderator
Moderator


Joined: 25 Apr 2005
Posts: 13046
Location: Ste-Foy,Canada

PostPosted: Sat Dec 15, 2012 6:37 am    Post subject: [Résolu] [btrfs] problème de lenteur en écriture/destruction Reply with quote

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 !
_________________
Sysadmin of GentooQuébec.org
Wiki
Signature
IRC on Freenode : #gentoo-quebec


Last edited by d2_racing on Wed Dec 19, 2012 1:10 pm; edited 2 times in total
Back to top
View user's profile Send private message
guilc
Moderator
Moderator


Joined: 15 Nov 2003
Posts: 3319
Location: Paris - France

PostPosted: Sun Dec 16, 2012 9:33 am    Post subject: Reply with quote

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 :mrgreen:
_________________
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
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2862
Location: Paris

PostPosted: Sun Dec 16, 2012 11:08 am    Post subject: Reply with quote

Je confirme pour discard et noatime, mes 2 options préférées :)
_________________
-PC: 2500K/P8Z68V, 8Go DDR3 1600 1.35V, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC + NF9D-2700, 4Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RDNU2000
Back to top
View user's profile Send private message
d2_racing
Moderator
Moderator


Joined: 25 Apr 2005
Posts: 13046
Location: Ste-Foy,Canada

PostPosted: Sun Dec 16, 2012 8:40 pm    Post subject: Reply with quote

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.
_________________
Sysadmin of GentooQuébec.org
Wiki
Signature
IRC on Freenode : #gentoo-quebec
Back to top
View user's profile Send private message
d2_racing
Moderator
Moderator


Joined: 25 Apr 2005
Posts: 13046
Location: Ste-Foy,Canada

PostPosted: Tue Dec 18, 2012 1:30 pm    Post subject: Reply with quote

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.
_________________
Sysadmin of GentooQuébec.org
Wiki
Signature
IRC on Freenode : #gentoo-quebec
Back to top
View user's profile Send private message
d2_racing
Moderator
Moderator


Joined: 25 Apr 2005
Posts: 13046
Location: Ste-Foy,Canada

PostPosted: Wed Dec 19, 2012 2:33 am    Post subject: Reply with quote

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.
_________________
Sysadmin of GentooQuébec.org
Wiki
Signature
IRC on Freenode : #gentoo-quebec
Back to top
View user's profile Send private message
El_Goretto
Advocate
Advocate


Joined: 29 May 2004
Posts: 2862
Location: Paris

PostPosted: Wed Dec 19, 2012 9:46 am    Post subject: Reply with quote

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).
_________________
-PC: 2500K/P8Z68V, 8Go DDR3 1600 1.35V, R9-290, ARC1220+5xWD500RE3, M4 256Go
-Home servers (hardened): µ-serv N40L, 2Go ECC + NF9D-2700, 4Go
-Réseau: ERL-3 + 3x switches GS108Tv2
-NAS: RDNU2000
Back to top
View user's profile Send private message
d2_racing
Moderator
Moderator


Joined: 25 Apr 2005
Posts: 13046
Location: Ste-Foy,Canada

PostPosted: Wed Dec 19, 2012 1:09 pm    Post subject: Reply with quote

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.
_________________
Sysadmin of GentooQuébec.org
Wiki
Signature
IRC on Freenode : #gentoo-quebec
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index French All times are GMT
Page 1 of 1

 
Jump to:  
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