Cependant, les équipements modernes tels que les unités de stockage en masse commencent à en atteindre les limites: la gestion des données par blocs n'est plus adaptée à la taille des fichiers qui sont utilisés maintenant.
En effet, les volumes de données à traiter augmentent en permanence et dans ce contexte, le vieillissant système de fichiers ext3 commence à montrer ses limites:
taille maximum du système de fichiers de 16 To fixée par un nombre de blocs codé sur 32 bits et des blocs de données de 4KB.
Le développement de ext4 a donc débuté en novembre 2006. Deux changements fondamentaux ont été apportés par rapport à ext3:
- Le nombre de blocs a été augmenté, passant de 32 à 48 bits ;
- L'adressage indirect de bloc (i.e: les blocs représentant un fichier sont enregistrés comme une liste de blocs uniques) a été remplacé par des "extents" (i.e: des plages de blocs).
Un système de fichiers plus grand (↑)
ext4 fonctionne avec un nombre de blocs codé sur 48 bits. La taille par défaut d'un bloc reste inchangée (4 KB). Cela permet donc d'atteindre une taille maximale pour le système de fichiers de 1 024 Po (1 024 000 To).
La valeur des i_blocks dans les inodes (qui contient le nombre de blocs utilisé par un fichier) a été adapté d'ext3 (longueur de 32 bits) de deux manières:
- Il ne compte plus en unité de secteurs de 512 octets du disque dur (comme c'est le cas d'ext3) mais en unité égale à la taille de bloc du système de fichiers (4 KB par défaut) ;
- Deux octets de l'inode qui étaient inutilisés jusqu'à présent sont maintenant utilisés pour enregistrer les 16 bits les plus hauts du numéro de bloc codé sur 48 bits.
Concernant les autres systèmes de fichiers présents dans le noyau, le principal rival d'ext4 est XFS, dans la mesure où JFs a du mal percer et que Reiser4 n'est toujours pas intégré au noyau.
Petit comparatif :
| Système de fichier | Taille maximum d'un fichier | Taille maximum du système de fichier |
|---|---|---|
| Ext4 | 16 To | 1024 Po |
| Ext3 | 2 To | 16 To |
| ReiserFS 3 | 8 To | 16 To |
| XFS | 8192 Po | 8192 Po |
| ZFS (Solaris) | 16384 Po | 16384 Po |
De gros fichiers...place aux "extents" (↑)
L'amélioration la plus importante d'ext4 porte sur l'utilisation d'extents en lieu et place de l'adressage de blocs indirect (ext3).
Une inode ext3 contient les numéros d'un maximum de 12 blocs de 4 KB. Si un fichier est plus grand que 48 KB il est alors adressé en utilisant un adressage indirect simple (jusqu'à 4 MB), puis double (jusqu'à 4 GB) et enfin triple : dans ce dernier cas, un numéro de bloc dans une inode pointe vers un bloc contenant des numéros de blocs qui eux-même pointent vers des blocs contenant des numéros de blocs qui contiennent les données.
Les "extents"
Au lieu d'adresser des blocs uniques, les "extents" représentent une portion de fichier (la plus grande possible) qui correspondent à des blocs consécutifs sur le disque dur. Ainsi, au lieu de stocker une longue liste de blocs, il suffit d'enregistrer seulement trois données : le début et la taille de la portion de fichier, et le numéro du premier bloc de données sur le disque dur.
ext4 utilise 32 bits pour stocker le nombre de blocs dans un fichier, ce qui limite la taille maximum d'un fichier à 16 To. Il est envisageable de dépasser cette limite avec une évolution du format des extents.
Un "extent" (12 octets) est structuré ainsi:
- 48 bits sont utilisés pour enregistrer le numéro du premier bloc physique ;
- 15 bits sont utilisés pour stocker la taille de l'extent : un extent ne peut donc dépasser 128 Mo. La raison pour cela est simple : tout comme ext3, ext4 découpe le disque dur en groupes de blocs de 128 Mo ;
- 32 bits utilisés pour stocker le numéro de bloc logique.
Les extents offrent le maximum de performance pour les fichiers très volumineux, en particulier lorsque l'on touche principalement aux méta données : lors de la suppression de fichier par exemple. La différence avec ext3 est frappante : sous ext4, la suppression est rapide comme l'éclair.
Avantages et limites (↑)
Avantages
- Augmentation de la taille maximum du système de fichiers ;
- Augmentation de la taille maximum d'un fichier ;
- Meilleure performance pour les fichiers volumineux ;
- Meilleure fiabilité :
- Une somme de contrôle (checksum) a été ajoutée à chaque transaction dans le journal. Cela permet à la fois de détecter les données mal écrites dans le journal et simplifie également l'écriture des commits pour les transactions dans le journal ;
- Les extents permettent un contrôle de cohérence plus poussé qu'avec les listes de blocs de ext3. En effet, il est possible, par exemple, de vérifier si l'extent d'un fichier dépasse sur un autre ;
- La durée d'un fsck est réduite de manière significative. Lorsque l'on créé un système de fichiers ext4, tous les groupes de blocs ne sont pas initialisés. Ainsi, au moment de vérifier la cohérence du système de fichier, seuls les inodes initialisés ont besoins d'être parcourus.
- Une somme de contrôle (checksum) a été ajoutée à chaque transaction dans le journal. Cela permet à la fois de détecter les données mal écrites dans le journal et simplifie également l'écriture des commits pour les transactions dans le journal ;
- ext4 permet un nombre de sous dossiers illimité ;
- Compatibilité descendante avec ext3
Limites
- Double adressage : la compatibilité avec ext3 permet donc de monter une partition ext3 en tant que ext4. Cependant, cela ne changera absolument rien au système. Il est possible d'activer les extents sur ce type de partitions (tune2fs -O extents). Attention, seuls les nouveaux fichiers utiliseront les nouvelles possibilité d'ext4. Un drapeau dans l'inode indique au système s'il s'agit d'un système d'adressage par liste de blocs (ext3) ou bien par extents (ext4). Migrer complètement de ext3 vers ext4 à 100% implique donc de déplacer tous les fichiers sur le disque dur ;
- Une fois les extents activés, il n'y a pas de méthode facile pour revenir à ext3 ;
- En cas de problème sur le système, il faut prendre la précaution d'utiliser un système de sauvetage qui supporte l'ext4
Aller plus loin
- ext4 - Wikipedia (1154 clics)
- ext4 Wiki - kernel.org (162 clics)
# Super !
Posté par Martin Peres (site web personnel) . Évalué à 7.
Petit problème cependant à la ligne :
ReiserFS 3 8 Tbyte 6 Tbyte
Vous vouliez dire 16 à la place de 6 ?
Voilà, encore merci
[^] # Re: Super !
Posté par BAud (site web personnel) . Évalué à 6.
bien vu, j'ai corrigé. J'avais aussi failli mettre des Tio, Pio à la place de Tbyte, Pbyte mais bon...
Pour les extents (et le reste), la conf' ext4 au FOSDEM cette année de Theodore_Ts%27o était particulièrement intéressante.
[^] # Re: Super !
Posté par Boa Treize (site web personnel) . Évalué à 4.
Et une curiosité : dans l'article tu parles de JFS, et juste dans le tableau qui suit, tu ne le compares pas aux autres (mais tu présentes ZFS, dont tu n'avais pas parlé).
[^] # Re: Super !
Posté par guppy . Évalué à 1.
Si les blocs de données sont à 4ko et qu'on peut en utiliser 4 milliards et des pouièmes (2^32), la valeur exacte serait donc 16TB nan ?
[^] # Re: Super !
Posté par BAud (site web personnel) . Évalué à 2.
Si quelqu'un a le courage de vérifier la page
http://en.wikipedia.org/wiki/Comparison_of_file_systems
cela alimentera sympathiquement la version française
http://fr.wikipedia.org/wiki/Comparaison_des_syst%C3%A8mes_d(...)
et j'aurais dû mettre effectivement des mébioctet d'un peu partout pour respecter le Prefixe_du_systeme_international /o\
[^] # Re: Super !
Posté par floriang . Évalué à 1.
# Et pour les nombreux petits fichiers
Posté par Tutur . Évalué à 10.
Mais, il manque une information, quel est l'impact sur les nombreux petit fichier?
[^] # Re: Et pour les nombreux petits fichiers
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
[^] # Re: Et pour les nombreux petits fichiers
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
De plus, son système d'arbre est peu résistant aux erreurs sur les meta donnés.
Si le but c'est la sécurité des données, reserfs est le dernier choix à faire.
"La première sécurité est la liberté"
# Le futur: btrfs
Posté par François . Évalué à 2.
Toutefois, il me semble important de préciser qu'ext4 n'est qu'un FS de transition en attendant la disponibilité de btrfs.
[^] # Re: Le futur: btrfs
Posté par gallenza . Évalué à 10.
# XFS et grosse partition
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Qui a déjà utilisé Ext4 sur des partitions de plus de 10To et quel est l'avantage par rapport a XFS qui domine ce segment depuis plusieurs années maintenant ?
[^] # Re: XFS et grosse partition
Posté par claudex . Évalué à 8.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: XFS et grosse partition
Posté par Psychofox (Mastodon) . Évalué à 6.
[^] # Re: XFS et grosse partition
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: XFS et grosse partition
Posté par rdg . Évalué à 1.
[^] # Re: XFS et grosse partition
Posté par Psychofox (Mastodon) . Évalué à 2.
http://www.sun.com/servers/x64/x4540/
[^] # Re: XFS et grosse partition
Posté par gpe . Évalué à 1.
Je croyais que les FS comme ext4 ne gérait que des partitions physique (donc limité à la taille d'un disque), non?
[^] # Re: XFS et grosse partition
Posté par Naha (site web personnel) . Évalué à 3.
[^] # Re: XFS et grosse partition
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: XFS et grosse partition
Posté par liberforce (site web personnel) . Évalué à 6.
http://linuxfr.org/~liberf0rce/20108.html
Pourtant personne n'est censé écrire dans xorg.conf pendant le fonctionnement... Je dis ça à cause des polémiques fsync/ext4:
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-tak(...)
Depuis je suis passé à ext3, je préfère quelque chose qui au moins m'assure que mes données ne vont pas finir au caniveau au moindre pépin. Je n'ai plus jamais perdu de données de cette manière (c'était il y a 3 ans 1/2).
[^] # Re: XFS et grosse partition
Posté par Gniarf . Évalué à -1.
# Linux magazine?
Posté par octane . Évalué à 4.
[^] # Re: Linux magazine?
Posté par Ork . Évalué à 1.
[^] # Re: Linux magazine?
Posté par LeMarsu . Évalué à 1.
[^] # Re: Linux magazine?
Posté par octane . Évalué à 3.
Page 10, il y a bien eu un article sur ext4, après celui sur ZFS.
# Juste une question
Posté par Amand Tihon (site web personnel) . Évalué à 6.
Est-ce utilisable en production aujourd'hui ? Quelle version du noyau au minimum ?
Avant de l'utiliser sur un FS de quelques To, j'aimerais autant avoir l'un ou l'autre retour :-)
[^] # Re: Juste une question
Posté par windu.2b . Évalué à 3.
[^] # Re: Juste une question
Posté par ondex2 . Évalué à 3.
[^] # Re: Juste une question
Posté par claudex . Évalué à 1.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Juste une question
Posté par liberforce (site web personnel) . Évalué à 5.
http://www.placenet.org/benoit/index.php/post/2009/04/03/I-w(...)
Donc la question se pose réellement.
[^] # Re: Juste une question
Posté par Fabimaru (site web personnel) . Évalué à 2.
J'ai commencé à monter mes volumes ext3 en ext4 (donc sans les options qui permettent d'utiliser les extents, dans un premier temps). Et puis après un moment, paf, crash. Je redémarre, j'utilise un peu ma machine, et crash. Pas d'info intéressante dans syslog.
En remontant tous mes volumes en ext3, plus de crash aléatoire. Donc finalement j'attends un peu.
[^] # Re: Juste une question
Posté par guillaje (site web personnel) . Évalué à 5.
# Quid du resize à chaud ?
Posté par LeMarsu . Évalué à 4.
Pas de problème, je lance
lvextend -L+100G /dev/vg0/mon_gros_devicepuisresize2fs /dev/vg0/mon_gros_device.Et là, c'est le drame. OOPS en pagaille. Obligé de démonter la partition, lancer plusieurs fsck avant de pouvoir remonter. Et la partition inchangé. Pour la resize, je suis obligé de faire le
resize2fsavec la partition démonté. Avec ext3 ou reiserfs, j'ai aucun problème.Était-ce une version des ext-tools qui était obsolète, ou mon support noyau pas assez à jour? Quoi qu'il en soit, j'ai lâché l'affaire avec ext4. J'attendrai btrfs pour le gros changement à mon avis.
Est-ce que d'autres ont eu le même problème que moi ? Pour des grosse partitions contenant principalement des fichiers de 700 Mo environ, vous conseillez quoi ? J'ai cru voir XFS dans un commentaire, certains ont des retours d'expérience ?
[^] # Re: Quid du resize à chaud ?
Posté par shbrol . Évalué à 10.
Rhooo... hadopi_fs, bien sur !
[^] # Re: Quid du resize à chaud ?
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Par contre évite de mettre ton /home dessus, car xfs en cas de crash hard ou violent perd le contenu des fichiers en cours d'écriture.
Donc par exemple tu risques de perdre les fichiers qui contiennent tes onglets kde/firefox/etc...
Pour les gros fichiers ça pose pas de soucis, tu perds juste le contenu touché depuis de début de l'écriture.
Typiquement durant le téléchargement d'une iso mandriva tu vas perdre le bloc en cours d'écriture.
J'utilise ça depuis 2004, ça marche très bien, mes seuls soucis ont été avec un kernel 2.6.17 qui pliait le XFS sous forte charge et dans la rc7 du 2.6.30 qui faisait du segfault, mais la rc8 et + ont corrigé tout ça.
L'autre avantage est le fsck à chaud, tu montes la partition, quand il a fini de la monté c'est prêt ;)
Et un xfs_fsr -v /pt_de_montage pour défragmenter si tu a beaucoup téléchargé d'iso de distribution en torrent en parallèle sur un disque plein à 80%.
[^] # Re: Quid du resize à chaud ?
Posté par Antoine . Évalué à 1.
C'est dommage de perdre de si bons onglets alors qu'on pourrait les manger.
(mais peut-être que c'est XFS qui les mange, du coup ?)
# Et sinon, pour les utilisateurs normaux ?
Posté par Aldoo . Évalué à 6.
Pour tout le reste, comme les mots Tera et Peta ne font pas partie de mon vocabulaire, j'ai du mal à voir comment ça va améliorer le fonctionnement de ma machine.
Pourquoi tous les efforts d'amélioration du FS par défaut de Linux ont été dirigés quasi-uniquement vers la gestion des "gros" volumes (c'est un euphémisme!), alors qu'une orientation performance pour des volumes moyens, voire petits (avec la généralisation des SSD) seraient bien plus utile pour l'immense majorité des utilisateurs ?
(Je ne dis pas qu'Ext4 est inutile... mais il répond à des besoins bien particuliers, je trouve !)
[^] # Après les Giga, les Tera
Posté par Zenitram (site web personnel) . Évalué à 6.
Pour information, un disque dur d'un Tera se trouve à 70€, 2 Tera à 270€.
Ca existe, ce n'est pas cher, il va falloir mettre ce mot dans ton vocabulaire...
[^] # Re: Après les Giga, les Tera
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Après les Giga, les Tera
Posté par Aldoo . Évalué à 1.
Même si le Téra est à portée du grand public, je reporte Zenitram au texte de l'article, où il est bien mentionné que Ext3 gère déjà des volumes de 16 Po !
[^] # Re: Après les Giga, les Tera
Posté par Troy McClure (site web personnel) . Évalué à 10.
t'as un disque de 40Go ? au bout d'un an il est plein
t'as un disque de 1To ? au bout d'un an il sera plein
[^] # Re: Après les Giga, les Tera
Posté par sirrus . Évalué à -5.
[^] # Re: Après les Giga, les Tera
Posté par fearan . Évalué à 4.
au hasard des photos (de plus en plus grosses, de plus en plus nombreuses)
Des films de vacances.
Des enregistrement de films (bah oui le dongle DVB-T USB compatible linux c'est pas pour rien non plus) sans oublier l'enregistrement de la télé par free.
Ça peut aussi être du téléchargement sur jamendo, nos propres enregistrement de musique (ou de massacre de musique)
Enfin bref, un disque ça se remplit toujours on ne sais pas pourquoi...
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par Adrien . Évalué à 5.
Sur le wiki de ext4 ¹ ils parlent aussi de préallocation au niveau du système de fichier et d'allocation différée qui doivent normalement améliorer la vie de tous les jours.
[1] http://ext4.wiki.kernel.org/index.php/Ext4_Howto
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Les extends sont très bénéfiques en vitesse de lectures de gros fichiers (un avi de 650 Mo ? non, une ISO Debian de 5 Go bien sûr !). Je pense qu'ils sont également bénéfiques en vitesse d'écriture (pour les disques utilisant des têtes de lecture, car ext4 en limite le déplacement).
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par scls19fr (site web personnel) . Évalué à 8.
Désolé je -------->[]
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par syntaxerror . Évalué à 4.
[^] # Re: Et sinon, pour les utilisateurs normaux ?
Posté par Yakulu . Évalué à 1.
1) pour la copie de fichiers volumineux
2) pour le démarrage : le système aurait en effet tendance à charger plus rapidement
Par contre, il semblerait qu'en utilisation classique - 3 - , les gains face à ext3 restent faibles voire inexistants. Bref, il ne s'agit vraisemblablement pas d'une révolution mais d'une sympathique évolution.
Sources :
1. http://www.phoronix.com/scan.php?page=article&item=ext4_(...) & http://www.phoronix.com/scan.php?page=article&item=btrfs(...)
2. http://izanbardprince.wordpress.com/2009/03/28/comparing-boo(...)
3. http://www.phoronix.com/scan.php?page=article&item=ext4_(...) et suivantes ou plus récemment, http://www.phoronix.com/scan.php?page=article&item=btrfs(...)
# linux v2.0
Posté par nomorsad . Évalué à 3.
Je suis bien content de voir un vieux système réécrit depuis zéro... J'ai toujours l'impression qu'un bon logiciel doit bien être réécrit 2 fois pour combler les imperfections des version 1.0.
Et je remarque que la tendance actuelle est la Grande Réécriture. Pour l'exemple et le désordre : KDE4, EXT4, IPV6... (toi aussi chez toi, cherche un gros logiciel/protocole/format réécrit!). On pourra aussi penser à Gougel Wave qui voudrait réinventer le courriel.
Je trouve que ça fait du bien d'avoir un bon nettoyage de printemps! car j'avais un ressenti de stagnation depuis quelques années (bon ya eut compiz et ca roxe des ours!).
Mais ce n'est qu'un ressenti, je n'ai aucun chiffre à l'appui...
A quand une grande réécriture d'un kernel?
[^] # Re: linux v2.0
Posté par windu.2b . Évalué à 5.
Parce qu'il faudrait pas se lancer dans une réécriture, juste pour dire qu'on fait une réécriture, mais parce que cela a un intérêt (tout remettre à plat et repartir sur des bases saines)...
[^] # Re: linux v2.0
Posté par Boa Treize (site web personnel) . Évalué à 2.
Les grandes réécritures c'est dangereux, y'a qu'à voir le temps qu'IPv6 et KDE 4 mettent pour sortir quelque chose capable de remplacer leurs prédécesseurs.
[^] # Re: linux v2.0
Posté par Antoine . Évalué à 4.
Oui, mais Perl 6 rendra les réécritures plus efficaces.
# Shake it, baby !
Posté par e001754 . Évalué à 7.
Mais là où réside l'astuce, c'est que le programme se contente de simplement bouger les fichiers du disque, profitant ainsi des algorithmes de dé-fragmentation déjà présents dans la gestion du système de fichier en cours. Il ne s'agit donc pas d'un programme de dé-fragmentation en tant que tel, mais plutôt d'un programme de copie de fichier récursive.
Avantage : c'est compatible avec n'importe quel système de fichier, car, en gros, ce programme se contente de déplacer les fichiers du disque.
Il convient cependant d'utiliser avec prudence, car je me rappelle d'avoir lu des rapports de premiers tests où des malheureux s'étaient essayé à «shaker» l'ensemble de leur disque et avaient rencontré des problèmes sérieux au moment ou la glibc était secouée. C'est qu'elle n'aime pas être secouée, la glibc (on la comprend).
Pour passer massivement un système de fichier d'ext3 en ext4, vu qu'il s'agit de ré-écrire le fichier pour qu'il migre tout seul d'ext3 en ext4 si on avait auparavant une partition ext3, voici une nouvelle application inattendue pour ce programme, non ?
Voici le lien freshmeat
[http://freshmeat.net/projects/shake]
[^] # Re: Shake it, baby !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
apt-get --reinstall install glibc
Je ne vois pas ou est le problème...
[^] # Re: Shake it, baby !
Posté par Raphaël G. (site web personnel) . Évalué à 3.
Eh hop le disque est défragmenté (en xfs bien sur)
# ext4FS vs btrFS
Posté par Anonyme . Évalué à 1.
Je ne comprends pas cette optique de développer un système en se disant à priori qu'il ne durera qu'un temps ?
Pourquoi ne pas avoir choisi d'essayer d'implémenter un FS pérenne tel que ZFS (si tant est qu'il existe un système pérenne car ce qui semble largement suffisant aujourd'hui se révèle souvent être limité qlqs années après...) ?
[^] # Re: ext4FS vs btrFS
Posté par gpe . Évalué à 4.
Si tu attends d'avoir le truc ultime tu ne sortiras jamais rien.
[^] # Re: ext4FS vs btrFS
Posté par Anonyme . Évalué à 1.
je sais bien que tt ne dure qu'un temps mais certains FS sont designés dès le début pr durer le plus lgtemps possble c'est le cas de ZFS
Alors que la avec ext4fs on sait déjà que ce FS a des limitations par rapport aux autres FS existants.
[^] # Re: ext4FS vs btrFS
Posté par Boa Treize (site web personnel) . Évalué à 4.
# Unités…
Posté par scand1sk (site web personnel) . Évalué à 2.
Récemment il y a eu une renormalisation de l'écriture des multiples, elle a le mérite de lever pas mal d'ambigüités… Cf http://fr.wikipedia.org/wiki/Préfixe_binaire
Ainsi, 1 To (téraoctet) = 10¹² octets, mais 1 Tio (tébioctet) = 2⁴⁰ octets…
Donc 1 Pio (pébioctet) = 1 024 Tio, et 1 Po (péraoctet) = 1 000 To.
[^] # Re: Unités…
Posté par Boa Treize (site web personnel) . Évalué à 3.
Non, car c'est complètement faux. 1 Po = 1024 To. (Et c'est petaoctet, pas peraoctet.)
Quand à la normalisation des multiples puissances de 2, elle aurait mieux fait de ne pas utiliser des noms aux sonorités ridicules. Je limite son usage aux contextes où l'ambiguïté n'est pas de mise.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.