Quelle est la taille limite de partition en ext3 ?
Je trouve pas mal de données contradictoires
est ce 4 To, 16 To, autres choses ?
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
http://en.wikipedia.org/wiki/Ext3#Size_limits
Quelle alternative pour dépasser ~ 10To ?
système debian etch amd64 noyau 2.6.18
disques organisés en LVM
Augmenter la taille des blocs; donc refaire le système de fichiers. Toutefois, je te le déconseille fortement.
-- Nicolas S.
Fabien LE LEZ
On Sat, 23 Feb 2008 04:22:10 +0100, "Nicolas S." :
Augmenter la taille des blocs; donc refaire le système de fichiers. Toutefois, je te le déconseille fortement.
Que déconseilles-tu exactement ? De changer la taille des blocs d'un système de fichiers existant, en espérant garder les fichiers ? J'imagine que créer un nouveau système de fichiers (vide, donc) avec une grosse taille de blocs ne pose pas problème ?
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée aux processeurs Alpha. Est-ce (toujours) vrai ?]
On Sat, 23 Feb 2008 04:22:10 +0100, "Nicolas S." :
Augmenter la taille des blocs; donc refaire le système de fichiers.
Toutefois, je te le déconseille fortement.
Que déconseilles-tu exactement ? De changer la taille des blocs d'un
système de fichiers existant, en espérant garder les fichiers ?
J'imagine que créer un nouveau système de fichiers (vide, donc) avec
une grosse taille de blocs ne pose pas problème ?
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée
aux processeurs Alpha. Est-ce (toujours) vrai ?]
On Sat, 23 Feb 2008 04:22:10 +0100, "Nicolas S." :
Augmenter la taille des blocs; donc refaire le système de fichiers. Toutefois, je te le déconseille fortement.
Que déconseilles-tu exactement ? De changer la taille des blocs d'un système de fichiers existant, en espérant garder les fichiers ? J'imagine que créer un nouveau système de fichiers (vide, donc) avec une grosse taille de blocs ne pose pas problème ?
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée aux processeurs Alpha. Est-ce (toujours) vrai ?]
Nicolas S.
Fabien LE LEZ a écrit:
Que déconseilles-tu exactement ?
Oui, pardon. Je déconseille d'aller si loin dans les tailles des systèmes de fichiers.
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée aux processeurs Alpha. Est-ce (toujours) vrai ?]
Dans les sources que j'ai sous la main, je trouve (pour une version 2.6.23): #define EXT3_MAX_BLOCK_SIZE 4096
Après une recherche rapide sur linux.kernel j'ai trouvé un hack qui va même plus loin en proposant de modifier cette valeur à 64k. L'auteur travaillait apparemment sur du ppc64.
Oui, pardon. Je déconseille d'aller si loin dans les tailles des
systèmes de fichiers.
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée
aux processeurs Alpha. Est-ce (toujours) vrai ?]
Dans les sources que j'ai sous la main, je trouve (pour une version
2.6.23):
#define EXT3_MAX_BLOCK_SIZE 4096
Après une recherche rapide sur linux.kernel j'ai trouvé un hack qui va
même plus loin en proposant de modifier cette valeur à 64k. L'auteur
travaillait apparemment sur du ppc64.
Oui, pardon. Je déconseille d'aller si loin dans les tailles des systèmes de fichiers.
[Au fait, je crois avoir lu que la taille de bloc 8 Ko était réservée aux processeurs Alpha. Est-ce (toujours) vrai ?]
Dans les sources que j'ai sous la main, je trouve (pour une version 2.6.23): #define EXT3_MAX_BLOCK_SIZE 4096
Après une recherche rapide sur linux.kernel j'ai trouvé un hack qui va même plus loin en proposant de modifier cette valeur à 64k. L'auteur travaillait apparemment sur du ppc64.
On Sat, 23 Feb 2008 07:11:07 +0100, "Nicolas S." :
Je déconseille d'aller si loin dans les tailles des systèmes de fichiers.
Quel(s) problème(s) de telles tailles posent-elles ?
Nicolas S.
Fabien LE LEZ a écrit:
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Les systèmes de fichiers sont structurés en arbres. Cela implique par exemple des fsck plus longs, surtout en cas d'erreur (càd pour la phase de réparation). Si le système de fichiers est définitivement cassé, la quantité de données perdues est potentiellement plus importante et la restauration plus longue. C'est d'autant plus vrai si on ne sauvegarde pas les répertoires qui appartiennent au système.
-- Nicolas S.
Fabien LE LEZ <gramster@gramster.com> a écrit:
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Les systèmes de fichiers sont structurés en arbres. Cela implique par
exemple des fsck plus longs, surtout en cas d'erreur (càd pour la phase
de réparation). Si le système de fichiers est définitivement cassé, la
quantité de données perdues est potentiellement plus importante et la
restauration plus longue. C'est d'autant plus vrai si on ne sauvegarde
pas les répertoires qui appartiennent au système.
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Les systèmes de fichiers sont structurés en arbres. Cela implique par exemple des fsck plus longs, surtout en cas d'erreur (càd pour la phase de réparation). Si le système de fichiers est définitivement cassé, la quantité de données perdues est potentiellement plus importante et la restauration plus longue. C'est d'autant plus vrai si on ne sauvegarde pas les répertoires qui appartiennent au système.
-- Nicolas S.
Nicolas S.
"Nicolas S." a écrit:
Fabien LE LEZ a écrit:
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Je précise que ce n'est pas induit par la taille des blocks qui eux posent d'autres problèmes comme la fragmentation et la perte d'espace disque.
-- Nicolas S.
"Nicolas S." <ni.s-factice@laposte.net> a écrit:
Fabien LE LEZ <gramster@gramster.com> a écrit:
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Je précise que ce n'est pas induit par la taille des blocks qui eux
posent d'autres problèmes comme la fragmentation et la perte d'espace
disque.
Quel(s) problème(s) de telles tailles posent-elles ?
La maintenance et le recouvrement des données en cas de crash.
Je précise que ce n'est pas induit par la taille des blocks qui eux posent d'autres problèmes comme la fragmentation et la perte d'espace disque.
-- Nicolas S.
Emmanuel Florac
Le Fri, 22 Feb 2008 15:41:53 -0500, Droopy191 a écrit :
Quelle alternative pour dépasser ~ 10To ?
XFS fonctionne très bien au delà de 10 To. J'ai actuellement plusieurs systèmes en service avec des FS XFS de 12 à 39 To d'un seul tenant sans souci et pour certains depuis deux ans. Ext3, reiserfs ne sont absolument pas fiables et stables au-delà de 4 To. JFS est semble-t-il aussi utilisable, mais nettement plus lent.
-- Not only is there no god, but try getting a plumber on weekends. Woody Allen
Le Fri, 22 Feb 2008 15:41:53 -0500, Droopy191 a écrit :
Quelle alternative pour dépasser ~ 10To ?
XFS fonctionne très bien au delà de 10 To. J'ai actuellement plusieurs
systèmes en service avec des FS XFS de 12 à 39 To d'un seul tenant sans
souci et pour certains depuis deux ans.
Ext3, reiserfs ne sont absolument pas fiables et stables au-delà de 4 To.
JFS est semble-t-il aussi utilisable, mais nettement plus lent.
--
Not only is there no god, but try getting a plumber on weekends.
Woody Allen
Le Fri, 22 Feb 2008 15:41:53 -0500, Droopy191 a écrit :
Quelle alternative pour dépasser ~ 10To ?
XFS fonctionne très bien au delà de 10 To. J'ai actuellement plusieurs systèmes en service avec des FS XFS de 12 à 39 To d'un seul tenant sans souci et pour certains depuis deux ans. Ext3, reiserfs ne sont absolument pas fiables et stables au-delà de 4 To. JFS est semble-t-il aussi utilisable, mais nettement plus lent.
-- Not only is there no god, but try getting a plumber on weekends. Woody Allen