Quand on formate une partition ext2 (ou ext3), les paramètres par
défaut (modifiables avec tune2fs) sont de lancer e2fsck, au démarrage
de la machine, après N montages ou une certaine durée.
Ça signifie que, régulièrement, le démarrage du système prendra une
heure ou deux. Ben oui, aujourd'hui les disques font 2 To, et vérifier
2 To, ça prend du temps.
J'ai donc l'intention de supprimer la vérification automatique, dès
que le PC en question aura démarré (aujourd'hui j'espère).
J'aimerais toutefois savoir comment vous gérez ce problème. Est-ce que
tout le monde a déjà viré cette vérification automatique ? Ou bien, y
a-t-il quelque chose qui m'échappe ?
des sécurités ont été ajoutées à dpkg (Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4).
çafoutlatrouille (cTMr)
-- Je cherche un nouveau travail... http://tboudet.free.fr/cv-thierry-boudet.pdf http://sigfood.dinorama.fr/
NiKo
Le 06/06/2011 23:12, Tonton Th a écrit :
On 06/06/2011 10:42 PM, NiKo wrote:
des sécurités ont été ajoutées à dpkg (Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4).
çafoutlatrouille (cTMr)
Oui, surtout avec une configuration raid avec de nombreux disques ... La première fois que j'ai eu à faire à ça, j'ai cru que mes disques allaient exploser.
Bon, heureusement, en s'y prenant bien, on peut éviter le problème si on à pas d'autre choix que mettre le système sur de l'ext4 :
Ouff, enfin un système qui s'installe en moins de 30 mn et qui ne burine pas les disques.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 06/06/2011 23:12, Tonton Th a écrit :
On 06/06/2011 10:42 PM, NiKo wrote:
des
sécurités ont été ajoutées à dpkg (Il fait un sync() sur chaque fichier
qu'il écrit sur un disque ext4).
çafoutlatrouille (cTMr)
Oui, surtout avec une configuration raid avec de nombreux disques ...
La première fois que j'ai eu à faire à ça, j'ai cru que mes disques
allaient exploser.
Bon, heureusement, en s'y prenant bien, on peut éviter le problème si on
à pas d'autre choix que mettre le système sur de l'ext4 :
des sécurités ont été ajoutées à dpkg (Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4).
çafoutlatrouille (cTMr)
Oui, surtout avec une configuration raid avec de nombreux disques ... La première fois que j'ai eu à faire à ça, j'ai cru que mes disques allaient exploser.
Bon, heureusement, en s'y prenant bien, on peut éviter le problème si on à pas d'autre choix que mettre le système sur de l'ext4 :
Ouff, enfin un système qui s'installe en moins de 30 mn et qui ne burine pas les disques.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Fabien LE LEZ
On Mon, 06 Jun 2011 22:42:18 +0200, NiKo :
(Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet d'optimiser les écritures. Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
On Mon, 06 Jun 2011 22:42:18 +0200, NiKo <NiKo@nomail.svp>:
(Il fait un sync() sur chaque fichier
qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet
d'optimiser les écritures. Mais comme ça présente un risque en cas de
panne de courant, les logiciels bloquent cette fonctionnalité (en
appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus
lent que ext3. C'est bien ça ?
(Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet d'optimiser les écritures. Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
Eric Jacoboni
Le 07/06/11 02:05, Fabien LE LEZ a écrit :
Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
Il y a une vie à côté de Debian et dpkg, hein :)
Le 07/06/11 02:05, Fabien LE LEZ a écrit :
Mais comme ça présente un risque en cas de
panne de courant, les logiciels bloquent cette fonctionnalité (en
appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus
lent que ext3. C'est bien ça ?
Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
Il y a une vie à côté de Debian et dpkg, hein :)
Dominique
Le 06/06/2011 19:00, Sergio a écrit :
Je ne comprends pas l'intérêt. Perdre 20 minutes chaque mois
Tu allumes ton PC, tu vas pisser.
20 minutes pour pisser ? Ça inspire le respect :-)
Bonne journée,
Dominique
Le 06/06/2011 19:00, Sergio a écrit :
Je ne comprends pas l'intérêt. Perdre 20 minutes chaque mois
Tu allumes ton PC, tu vas pisser.
20 minutes pour pisser ? Ça inspire le respect :-)
Je ne comprends pas l'intérêt. Perdre 20 minutes chaque mois
Tu allumes ton PC, tu vas pisser.
20 minutes pour pisser ? Ça inspire le respect :-)
C'est le deuxième effet Guinness !
-- Je cherche un nouveau travail... http://tboudet.free.fr/cv-thierry-boudet.pdf http://sigfood.dinorama.fr/
NiKo
Le 07/06/2011 02:05, Fabien LE LEZ a écrit :
On Mon, 06 Jun 2011 22:42:18 +0200, NiKo :
(Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet d'optimiser les écritures. Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
A moitié. sync() à été implémenté dans les outils de gestion de packages car il y à (de mémoire) un problème en cas de coupure de courant lors d'une opération CopyOnRename qui laissait des fichiers de taille nulle. Pour le reste des opérations, hors gestion des packages et peut-être quelque cas bien spécifiques, il n'y à pas de sync() forcé.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Le 07/06/2011 02:05, Fabien LE LEZ a écrit :
On Mon, 06 Jun 2011 22:42:18 +0200, NiKo <NiKo@nomail.svp>:
(Il fait un sync() sur chaque fichier
qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet
d'optimiser les écritures. Mais comme ça présente un risque en cas de
panne de courant, les logiciels bloquent cette fonctionnalité (en
appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus
lent que ext3. C'est bien ça ?
A moitié. sync() à été implémenté dans les outils de gestion de packages
car il y à (de mémoire) un problème en cas de coupure de courant lors
d'une opération CopyOnRename qui laissait des fichiers de taille nulle.
Pour le reste des opérations, hors gestion des packages et peut-être
quelque cas bien spécifiques, il n'y à pas de sync() forcé.
(Il fait un sync() sur chaque fichier qu'il écrit sur un disque ext4)
Si j'ai tout bien compris : ext4 a une fonctionnalité qui permet d'optimiser les écritures. Mais comme ça présente un risque en cas de panne de courant, les logiciels bloquent cette fonctionnalité (en appelant sync()), ce qui fait qu'au finale, ext4 est nettement plus lent que ext3. C'est bien ça ?
A moitié. sync() à été implémenté dans les outils de gestion de packages car il y à (de mémoire) un problème en cas de coupure de courant lors d'une opération CopyOnRename qui laissait des fichiers de taille nulle. Pour le reste des opérations, hors gestion des packages et peut-être quelque cas bien spécifiques, il n'y à pas de sync() forcé.
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Damien Wyart
* Fabien LE LEZ in fr.comp.os.linux.configuration:
Quand on formate une partition ext2 (ou ext3), les paramètres par défaut (modifiables avec tune2fs) sont de lancer e2fsck, au démarrage de la machine, après N montages ou une certaine durée.
Ça signifie que, régulièrement, le démarrage du système prendra une heure ou deux. Ben oui, aujourd'hui les disques font 2 To, et vérifier 2 To, ça prend du temps.
J'ai donc l'intention de supprimer la vérification automatique, dès que le PC en question aura démarré (aujourd'hui j'espère).
Ca ne me semble pas une mauvaise solution ; en général les vrais problèmes se produisent lorsque le système de fichier est mal démonté, et dans ce cas, le fsck sera forcé, donc le fsck régulier, sur un serveur "en bonne santé" ne me semble pas très utile. Si la machine redémarre souvent, on peut aussi diminuer la fréquence.
Ceci dit, si on veut le garder par précaution, les autres suggestions sur ext4 sont bonnes ; migrer un ext3 vers ext4 donnera de moins bons résultats que de partir d'un ext4 "neuf".
Pour un peu plus de détails : http://www.linuxfoundation.org/news-media/blogs/browse/2009/02/fast-ext4-fsck-times-revisited http://www.linuxfoundation.org/news-media/browse/blogs/2008/08/fast-ext4-fsck-times http://serverfault.com/questions/21424/slow-ext4-fsck
Sinon, à moins que tu aies des contraintes pour rester en ext, xfs pourrait également convenir car il n'y a pas de fsck à intervalles réguliers. La commande fsck appelée par les scripts de démarrage ne fait rien. En cas de problème, le log du système de fichier est analysé au niveau noyau lors du montage. Et en cas d'impossibilité de montage, il faut alors appeler manuellement l'outil de réparation (xfs_repair) qui est distinct de la commande fsck.
De plus, sur les noyaux récents, les performances de xfs sont vraiment excellentes sans tuning pour pas mal de cas d'utilisation courants.
-- DW
* Fabien LE LEZ <gramster@gramster.com> in fr.comp.os.linux.configuration:
Quand on formate une partition ext2 (ou ext3), les paramètres par
défaut (modifiables avec tune2fs) sont de lancer e2fsck, au démarrage
de la machine, après N montages ou une certaine durée.
Ça signifie que, régulièrement, le démarrage du système prendra une
heure ou deux. Ben oui, aujourd'hui les disques font 2 To, et vérifier
2 To, ça prend du temps.
J'ai donc l'intention de supprimer la vérification automatique, dès
que le PC en question aura démarré (aujourd'hui j'espère).
Ca ne me semble pas une mauvaise solution ; en général les vrais
problèmes se produisent lorsque le système de fichier est mal démonté,
et dans ce cas, le fsck sera forcé, donc le fsck régulier, sur un
serveur "en bonne santé" ne me semble pas très utile. Si la machine
redémarre souvent, on peut aussi diminuer la fréquence.
Ceci dit, si on veut le garder par précaution, les autres suggestions
sur ext4 sont bonnes ; migrer un ext3 vers ext4 donnera de moins bons
résultats que de partir d'un ext4 "neuf".
Pour un peu plus de détails :
http://www.linuxfoundation.org/news-media/blogs/browse/2009/02/fast-ext4-fsck-times-revisited
http://www.linuxfoundation.org/news-media/browse/blogs/2008/08/fast-ext4-fsck-times
http://serverfault.com/questions/21424/slow-ext4-fsck
Sinon, à moins que tu aies des contraintes pour rester en ext, xfs
pourrait également convenir car il n'y a pas de fsck à intervalles
réguliers. La commande fsck appelée par les scripts de démarrage ne fait
rien. En cas de problème, le log du système de fichier est analysé au
niveau noyau lors du montage. Et en cas d'impossibilité de montage, il
faut alors appeler manuellement l'outil de réparation (xfs_repair) qui
est distinct de la commande fsck.
De plus, sur les noyaux récents, les performances de xfs sont vraiment
excellentes sans tuning pour pas mal de cas d'utilisation courants.
* Fabien LE LEZ in fr.comp.os.linux.configuration:
Quand on formate une partition ext2 (ou ext3), les paramètres par défaut (modifiables avec tune2fs) sont de lancer e2fsck, au démarrage de la machine, après N montages ou une certaine durée.
Ça signifie que, régulièrement, le démarrage du système prendra une heure ou deux. Ben oui, aujourd'hui les disques font 2 To, et vérifier 2 To, ça prend du temps.
J'ai donc l'intention de supprimer la vérification automatique, dès que le PC en question aura démarré (aujourd'hui j'espère).
Ca ne me semble pas une mauvaise solution ; en général les vrais problèmes se produisent lorsque le système de fichier est mal démonté, et dans ce cas, le fsck sera forcé, donc le fsck régulier, sur un serveur "en bonne santé" ne me semble pas très utile. Si la machine redémarre souvent, on peut aussi diminuer la fréquence.
Ceci dit, si on veut le garder par précaution, les autres suggestions sur ext4 sont bonnes ; migrer un ext3 vers ext4 donnera de moins bons résultats que de partir d'un ext4 "neuf".
Pour un peu plus de détails : http://www.linuxfoundation.org/news-media/blogs/browse/2009/02/fast-ext4-fsck-times-revisited http://www.linuxfoundation.org/news-media/browse/blogs/2008/08/fast-ext4-fsck-times http://serverfault.com/questions/21424/slow-ext4-fsck
Sinon, à moins que tu aies des contraintes pour rester en ext, xfs pourrait également convenir car il n'y a pas de fsck à intervalles réguliers. La commande fsck appelée par les scripts de démarrage ne fait rien. En cas de problème, le log du système de fichier est analysé au niveau noyau lors du montage. Et en cas d'impossibilité de montage, il faut alors appeler manuellement l'outil de réparation (xfs_repair) qui est distinct de la commande fsck.
De plus, sur les noyaux récents, les performances de xfs sont vraiment excellentes sans tuning pour pas mal de cas d'utilisation courants.
