Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Lectures/écritures régulières sur le disque après install à cause de jdb2

7 réponses
Avatar
Francois Lafont
Bonjour à tous,

J'ai installé une Debian Wheezy amd64 sur un serveur avec Processeur
Intel Xeon 4 cœurs, 2 fois 4GB de RAM (DDR3) et 2 disque SATA de 1TB
chacun (des Westen Digital). Il n'y a pas de contrôleur RAID sur le
serveur. Les disques sont formatés en ext4 tous les deux avec l'option
noatime. Le premier disque contient / et le deuxième contient un
répertoire /d qui contiendra des données mais qui à la base est
totalement vide.

Juste après l'installation, après le premier reboot, pas de problème
notable à part le fait que j'ai des petites lectures/écritures
très régulières sur les 2 disques (environ toutes les secondes), alors
que le serveur ne fait strictement rien (pour l'instant c'est une
installation minimaliste, juste un petit ssh). Avec la commande
top, je peux voir des petites phases très brèves de io_wait qui
montent à 0.5% voire 1% mais cela se produit sans cesse toutes les
secondes environ.

Rien de bien méchant, avec un top via ssh je ne me serais sans
doute aperçu de rien, mais c'est surtout perceptible à l'ouie
car on peut bien entre les i/o sur les disques et à l'œil car
on peut voir les leds clignoter toutes les secondes.

J'ai mis du temps avant d'arriver à trouver le ou les process
responsables de ces lectures/écritures : il s'agit de jbd2.
J'ai pu voir que c'est un process qui s'occupe de la journalisation
du fs.

Chose curieuse, ces i/o disques ne durent qu'1h30 environ après
l'installation, ensuite c'est fini, c'est le calme plat, tout
semble redevinir normal. Certes le serveur est totalement oisif,
rien ne me dit que le flot de i/o disques ne peut pas se reproduire
dès que le serveur doit solliciter ces disques.

Si je fais la même installation en ext3, alors je ne constate
pas ces i/o disques.

1. Est-ce un problème au niveau de ma conf bios et/ou du noyau,
ou encore des options de montages indiquer dans fstab ?

2. Après tout, le phénomène finit par s'arrêter au bout
de 1h30 après le premier reboot (dans le cas d'un serveur
oisif tout de même). Est-ce que ces i/o disques sont normales
et ne se produiront que durant un petite période après l'install
uniquement ? Ou bien je peux m'attendre à ce que ça se reproduise
dès que le serveur aura une certaine activité au niveau des
disques ?

3. Quand on tape "ext4 jdb2" sur Google on voit pas mal
de problème identiques au mien (sans vraiment trouver
de solution hélas). Est-ce que ça veut dire que l'ext4
est un mauvais choix de fs pour une Wheezy amd64 ?
Dois-je préférer l'ext3 (pour lequel le problème n'apparaît
pas sur le serveur) ? Ou un autre fs ?

4. Voici par exemple le genre de valeurs que j'obtiens
avec un hdparm :

# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 25028 MB in 2.00 seconds = 12529.67 MB/sec
Timing buffered disk reads: 384 MB in 3.00 seconds = 127.97 MB/sec

Ça vous semble correct par rapport au matériel ?

J'espère n'avoir oublié aucun élément, si c'est le cas je peux
bien sûr fournir toutes les infos nécessaires.

Merci d'avance pour votre aide.

--
François Lafont

7 réponses

Avatar
Damien Wyart
* Francois Lafont
in fr.comp.os.linux.configuration:
Juste après l'installation, après le premier reboot, pas de problème
notable à part le fait que j'ai des petites lectures/écritures très
régulières sur les 2 disques (environ toutes les secondes), alors que
le serveur ne fait strictement rien (pour l'instant c'est une
installation minimaliste, juste un petit ssh). Avec la commande top,
je peux voir des petites phases très brèves de io_wait qui montent
à 0.5% voire 1% mais cela se produit sans cesse toutes les secondes
environ.
[...]
Chose curieuse, ces i/o disques ne durent qu'1h30 environ après
l'installation, ensuite c'est fini, c'est le calme plat, tout
semble redevinir normal. Certes le serveur est totalement oisif,
rien ne me dit que le flot de i/o disques ne peut pas se reproduire
dès que le serveur doit solliciter ces disques.



Cela provient du comportement par défaut de mkfs.ext4, qui fait un
formatage « rapide » ou paresseux afin de rendre la main plus vite. La
suite du formatage est faite lors du montage suivant, en tâche de fond,
et peut prendre du temps.

C'est donc tout à fait normal, et ça ne discrédite pas ext4.

Il y a quelques détails dans la page de man de mkfs.ext4, l'option
étendue s'appelle "lazy_itable_init".

--
DW
Avatar
Francois Lafont
Bonjour,

Le 14/12/2013 11:12, Damien Wyart a écrit :

Cela provient du comportement par défaut de mkfs.ext4, qui fait un
formatage « rapide » ou paresseux afin de rendre la main plus vite. La
suite du formatage est faite lors du montage suivant, en tâche de fond,
et peut prendre du temps.



Ok. Et bien j'ai appris quelque chose. Je ne savais pas du tout et
ce phénomène m'avait jusque là complètement échappé.

C'est donc tout à fait normal, et ça ne discrédite pas ext4.

Il y a quelques détails dans la page de man de mkfs.ext4, l'option
étendue s'appelle "lazy_itable_init".



Effectivement, on peut voir :

lazy_itable_init[= <0 to disable, 1 to enable>]
If enabled and the uninit_bg feature is enabled, the
inode table will not be fully initialized by mke2fs.
This speeds up filesystem initialization noticeably,
but it requires the kernel to finish initializing
the filesystem in the background when the filesystem
is first mounted. If the option value is omitted,
it defaults to 1 to enable lazy inode table initial‐
ization.

Mais en fait, en regardant tout ça, déjà je me suis rendu
que je tombais sur la page man de mke2fs.

On est d'accord que :

mkfs.ext4 ...
mkfs -t ext4 ...
mke2fs -t ext4 ...

sont totalement équivalents ?

Si je comprends bien, pour ne plus avoir ce problème,
il faut que je fasse :

mkfs.ext4 -L label -E lazy_itable_init=0 /dev/sdb1

Et là effectivement après le montage je n'ai plus les
petites écritures. Certes, le formatage est plus long mais
ce n'est pas méchant. Ça prend 2 ou 3 minutes au lieu de
30 secondes ou un truc dans le style. Du coup, il n'y a pas
photo entre :

- avoir un formatage de 20s et ensuite des petites écritures
pendant plus d'1h30 après le premier mount,
- et avoir un formatage de 2 ou 3 mn et pas ces petites
écritures ensuite,

personnellement je préfère de loin de deuxième solution.

Il faudra que je regarde comment mettre en place cette
option lors d'une installation via pxe.

Au passage, je pense avoir compris pourquoi le phénomène
ne se produisait pas avec du ext3. En effet, avec ext3
lors de l'installation de la Wheezy, je pouvais voir la
barre de progression se bloquer à 33% pendant un certain
temps lors du formatage. Je suis prêt à parier que
c'est parce qu'avec ext3 il n'y a pas cette options
lazy_itable_init par défaut.

Merci beaucoup pour ton aide Damien, j'y vois nettement
plus clair maintenant.

--
François Lafont
Avatar
Pascal Hambourg
Salut,

Francois Lafont a écrit :

Mais en fait, en regardant tout ça, déjà je me suis rendu
que je tombais sur la page man de mke2fs.

On est d'accord que :

mkfs.ext4 ...
mkfs -t ext4 ...
mke2fs -t ext4 ...

sont totalement équivalents ?



$ ls -1if /sbin/mkfs.ext[234] /sbin/mke2fs /sbin/mkfs
209875 /sbin/mkfs.ext2
209875 /sbin/mkfs.ext3
209875 /sbin/mkfs.ext4
209875 /sbin/mke2fs
209778 /sbin/mkfs

On peut voir que mke2fs et les mkfs.ext* ont le même inode, ce sont le
même exécutable. Quant à mkfs -t ext4, c'est un frontal qui recherche et
exécute mkfs.ext4.

Si je comprends bien, pour ne plus avoir ce problème,



En quoi est-ce un problème ?

il faut que je fasse :

mkfs.ext4 -L label -E lazy_itable_init=0 /dev/sdb1

Et là effectivement après le montage je n'ai plus les
petites écritures. Certes, le formatage est plus long mais
ce n'est pas méchant. Ça prend 2 ou 3 minutes au lieu de
30 secondes ou un truc dans le style. Du coup, il n'y a pas
photo entre :

- avoir un formatage de 20s et ensuite des petites écritures
pendant plus d'1h30 après le premier mount,
- et avoir un formatage de 2 ou 3 mn et pas ces petites
écritures ensuite,

personnellement je préfère de loin de deuxième solution.



Pourquoi, si ce n'est pas indiscret ?
Avatar
Erwan David
Pascal Hambourg écrivait :

Salut,

Francois Lafont a écrit :

Mais en fait, en regardant tout ça, déjà je me suis rendu
que je tombais sur la page man de mke2fs.

On est d'accord que :

mkfs.ext4 ...
mkfs -t ext4 ...
mke2fs -t ext4 ...

sont totalement équivalents ?



$ ls -1if /sbin/mkfs.ext[234] /sbin/mke2fs /sbin/mkfs
209875 /sbin/mkfs.ext2
209875 /sbin/mkfs.ext3
209875 /sbin/mkfs.ext4
209875 /sbin/mke2fs
209778 /sbin/mkfs

On peut voir que mke2fs et les mkfs.ext* ont le même inode, ce sont le
même exécutable. Quant à mkfs -t ext4, c'est un frontal qui recherche et
exécute mkfs.ext4.



Mais ça ne garanti pas que le comportement soit le même.


--
Les simplifications c'est trop compliqué
Avatar
Francois Lafont
Bonsoir,

Le 14/12/2013 19:09, Pascal Hambourg a écrit :

On est d'accord que :

mkfs.ext4 ...
mkfs -t ext4 ...
mke2fs -t ext4 ...

sont totalement équivalents ?



$ ls -1if /sbin/mkfs.ext[234] /sbin/mke2fs /sbin/mkfs
209875 /sbin/mkfs.ext2
209875 /sbin/mkfs.ext3
209875 /sbin/mkfs.ext4
209875 /sbin/mke2fs
209778 /sbin/mkfs

On peut voir que mke2fs et les mkfs.ext* ont le même inode, ce sont le
même exécutable. Quant à mkfs -t ext4, c'est un frontal qui recherche et
exécute mkfs.ext4.



Ah ok, j'aurais dû regarder ça. C'est curieux quand même ou alors
dans l'exécutable il y a des instructions pour savoir sous quel nom
il a été appelé alors ?

Si je comprends bien, pour ne plus avoir ce problème,



En quoi est-ce un problème ?

il faut que je fasse :

mkfs.ext4 -L label -E lazy_itable_init=0 /dev/sdb1

Et là effectivement après le montage je n'ai plus les
petites écritures. Certes, le formatage est plus long mais
ce n'est pas méchant. Ça prend 2 ou 3 minutes au lieu de
30 secondes ou un truc dans le style. Du coup, il n'y a pas
photo entre :

- avoir un formatage de 20s et ensuite des petites écritures
pendant plus d'1h30 après le premier mount,
- et avoir un formatage de 2 ou 3 mn et pas ces petites
écritures ensuite,

personnellement je préfère de loin de deuxième solution.



Pourquoi, si ce n'est pas indiscret ?



Pas de problème. :)

C'est juste que, à terme, ce serveur sera fait pour de la
« production » même si c'est pour des tâches assez modestes :
ce sera sûrement un serveur Xen avec une VM pour faire de la
supervision (mais pas de métrologie) et sans doute une deuxième
VM qui fera office de miroir Debian interne. Or, on a un système
d'installation via du pxe + puppet afin d'automatiser toutes
les installations, si bien qu'une fois l'installation terminée,
le serveur est (théoriquement hein ;-)) en production. Ça demande
bien sûr pas mal de boulot en amont. Du coup, dans l'esprit,
je préfère que le formatage soit définitivement terminé
une fois tout installé et la machine en production, quitte
à ce que le formatage prenne 2 ou 3 minutes de plus.

Bon, ok, c'est pas crucial c'est juste pour le principe.
J'espère que j'ai répondu à ta question.

--
François Lafont
Avatar
Erwan David
Francois Lafont écrivait :

Bonsoir,

Le 14/12/2013 19:09, Pascal Hambourg a écrit :

On est d'accord que :

mkfs.ext4 ...
mkfs -t ext4 ...
mke2fs -t ext4 ...

sont totalement équivalents ?



$ ls -1if /sbin/mkfs.ext[234] /sbin/mke2fs /sbin/mkfs
209875 /sbin/mkfs.ext2
209875 /sbin/mkfs.ext3
209875 /sbin/mkfs.ext4
209875 /sbin/mke2fs
209778 /sbin/mkfs

On peut voir que mke2fs et les mkfs.ext* ont le même inode, ce sont le
même exécutable. Quant à mkfs -t ext4, c'est un frontal qui recherche et
exécute mkfs.ext4.



Ah ok, j'aurais dû regarder ça. C'est curieux quand même ou alors
dans l'exécutable il y a des instructions pour savoir sous quel nom
il a été appelé alors ?



C'est très courant sous Unix. Dans le genre on a busybox qui regroupe en
un seul exécutable la plupart des commandes Unix standard.

--
Les simplifications c'est trop compliqué
Avatar
Lucas Levrel
Le 14 décembre 2013, Francois Lafont a écrit :

Ah ok, j'aurais dû regarder ça. C'est curieux quand même ou alors
dans l'exécutable il y a des instructions pour savoir sous quel nom
il a été appelé alors ?



C'est très courant sous Unix. Dans le genre on a busybox qui regroupe en
un seul exécutable la plupart des commandes Unix standard.



Ah, je comprends mieux, merci.
J'avoue que j'ai du mal à voir l'intérêt du truc mais c'est un autre débat. ;-)



L'essentiel du code de mkfs.ext2/3/4 est probablement indépendant de la
version 2/3/4. Du coup ça évite de compiler trois fois quasiment le même
exécutable : gain de place (pour le principe), pas de risque
d'incohérences de version/dépendance avec d'autres lib...

Le code est sans doute plus propre aussi : plutôt qu'un source avec des
directives permettant de produire trois exécutables différents, on a un
source qui produit un seul exécutable.

--
LL