Le système de fichiers ext4 est le meilleur « par défaut » avec GNU/Linux : il est le choix par omission de l’immense majorité des distributions. Cependant, il a quelques limitations dues à ses choix techniques, qui font que l’on a vraiment avantage à affiner nos formatages de disques et clefs USB.
Journal des écritures
Par défaut depuis ext3, nous avons une sécurité pour prévenir les coupures de courant et autres interruptions brutales d’écriture : le journal. Il permet de retrouver un système de fichiers utilisable après un de ces problèmes. Bien sûr, le fichier en cours d’écriture lors de l’interruption est corrompu et devra probablement être jeté, mais le système de fichiers restera sain.
Pour gagner un peu d’espace disque, ou éviter trop d’écritures sur un média fragile comme les clefs USB, on peut désactiver cette sécurité. Bien sûr, on met en danger tout le contenu de la partition en cas d’accident, c’est donc déconseillé à ceux qui arrachent toujours les clés sans les démonter !
Comment qu’on fait ? Il faut formater en désactivant le journal :
mke2fs -t ext4 -O ^has_journal /dev/sdXN
Nombre de nœuds d’index fixe
Une limitation moins connue est le nombre de nœuds d’index (inodes) fixe. Cela veut dire qu’il faut choisir lors du formatage du disque quel est le nombre maximal de fichiers qu’il pourra contenir à la fois à l’avenir. Pour être sûr, le formatage par défaut prévoit le maximum, et cela occupe beaucoup d’espace pour les nœuds d’index. Si vous savez que votre disque n’aura que des fichiers particuliers (par exemple, des photos numériques, des films ou des MP3) vous pouvez demander beaucoup moins de nœuds d’index.
On peut voir combien de nœuds d’index sont prévus et occupés dans nos partitions montées avec la commande df -i
. J’ai ainsi vu ce que mon /home
gaspillait avec 95 % de nœuds d’index libres alors que l’espace disque est occupé à 85 % !
Comment qu’on fait ? Il faut formater en indiquant un nombre d’inodes, ou la taille moyenne des fichiers :
mke2fs -t ext4 -N [nombre d’inodes] /dev/sdXN
Espace réservé au super‐utilisateur
C’est un point bien plus connu, 5 % de la partition est réservée au compte super‐utilisateur root par défaut. Heureusement, ce quota est modifiable sans reformater la partition, on va donc seulement le mentionner pour être exhaustif.
Comment qu’on fait ? Il faut mettre ce quota à 0 % :
tune2fs -m 0 /dev/sdXN
Cas d’une clef USB de 1 Gio
Voici un cas pratique pour évaluer le pourcentage d’espace disque que l’on peut espérer gagner avec tous ces affinages. C’est une simple vieille clef USB de un « giga » avec un système Mageia Cauldron. Cela permet de remplacer les valeurs en Mio par Gio pour un disque d’un téraoctet, bien plus courant aujourd’hui :
- espace physique : 962 Mio ;
- formatage normal : 865 Mio.
Diantre ! 39 Mio soit 4 % du disque est perdu en formatant en ext4 !
Améliorons en gardant 0 % pour le super‐utilisateur et diminuant le maximum de fichiers :
- formatage normal avec 0% pour le super‐utilisateur : 913 Mio ;
- formatage pour des MP3 (3 Mio par nœud d’index) : 928 Mio, soit 1,5 % de gain ;
- formatage pour au maximum (67 Mio par nœud d’index) : 928 Mio, soit pas de gain supplémentaire.
Améliorons tout ça, en supprimant le journal :
- formatage sans journal pour des MP3 (3 Mio par nœud d’index) : 944 Mio, soit encore 1,5 % de gain supplémentaire.
Voilà, vous avez appris comment gagner de 16 Mio à 31 Mio dans un disque de 1 Gio.
Autant la suppression du journal n’est envisageable que pour les disques externes, autant la limitation des nœuds d’index ne mange pas de pain : vérifiez comme vos partitions prévoient dix fois plus de nœuds d’index que vous n’utilisez réellement…
Autres systèmes de fichiers ?
J’ai été tenté par d’autres systèmes de fichiers, pour voir. XFS utilise une technique de variation dynamique du nombre de nœuds d’index ; c’est plus souple, donc théoriquement mieux. Cependant, on gagne moins d’espace qu’avec les conseils ci‐dessus, même en gardant le journal :
- formatage par défaut avec XFS : 926 Mio.
Btrfs n’est clairement pas fait pour gagner de l’espace :
- formatage par défaut avec Btrfs : 849 Mio.
Aller plus loin
- e2fsprogs : ext2/3/4 filesystem utilities (673 clics)
# Il y a un gros pb de markdown au milieu de l'article
Posté par Stefane Fermigier (site web personnel) . Évalué à 3.
C'est tout.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Il y a un gros pb de markdown au milieu de l'article
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Merci, c'est corrigé.
# sauf que btrfs est malin
Posté par feth . Évalué à 10.
btrfs permet de stocker une fois des données identiques, et ce de façon transparente - il ne s'agit pas de hardlinks, mais d'une optimisation du stockage de données lorsqu'elles sont identiques. J'adorerais pouvoir faire cela avec ext4 (et j'avoue que c'est même l'espoir que ça arrive qui m'a fait cliquer sur ton journal, plein d'espoir !).
Comment utiliser la déduplication btrfs
[^] # Re: sauf que btrfs est malin
Posté par voxdemonix . Évalué à 2.
sur Ubuntu 16.04.03
[^] # Re: sauf que btrfs est malin
Posté par feth . Évalué à 10.
bah, c'est pas pour rien que je continue de tourner ext4 en prod : c'est considéré comme stable.
[^] # Re: sauf que btrfs est malin
Posté par voxdemonix . Évalué à -3. Dernière modification le 24 mai 2018 à 16:42.
Sauf erreur de ma part, ext4 ne gère hélas pas les JBOD/RAID nativement. :(
[^] # Re: sauf que btrfs est malin
Posté par feth . Évalué à 4.
Tu n'as pas idée de la taille du mille feuilles qu'on a ici (raid constructeur, drbd…)
[^] # Re: sauf que btrfs est malin
Posté par syntaxerror . Évalué à 2.
En attendant que dedupe soit mature et intégré au noyo:
https://btrfs.wiki.kernel.org/index.php/Deduplication
Utiliser duperemove, peut être précédé de jdupes
[^] # Re: sauf que btrfs est malin
Posté par MTux . Évalué à 4.
Quid des performances?
La dedup est connue pour avoir un coût très élevé, au point que c'est plutôt utilisé pour du stockage lent/froid.
[^] # Re: sauf que btrfs est malin
Posté par laurentb (site web personnel) . Évalué à 1.
J'utilise la déduplication offline avec duperemove, c'est plutôt rapide. C'est sûrement moins puissant que celle de ZFS, mais au moins, c'est accessible avec du matériel normal.
[^] # Re: sauf que btrfs est malin
Posté par dcp . Évalué à 2.
Ce n'est pas/plus tellement vrai. Dans les stockages industriels type NetApp (pas libre du tout) la dedup est activée par défaut sur les stockages SSD.
Sur nos anciennes baies (SAS et SATA) la dedup tournait uniquement le week-end. On gagnait ~20-25% d'espace de stockage sans perdre de performance pendant les heures de bureau.
Dans les deux cas on note un léger gain de performance, dans la mesure ou l'espace de cache des baies se trouve maximiser (plus de blocs en double, triple … dans le cache)
[^] # Re: sauf que btrfs est malin
Posté par laurentb (site web personnel) . Évalué à 1. Dernière modification le 09 juin 2018 à 14:17.
Dans btrfs, il y a aussi la compression. Suivant le type de fichiers, ça peut être utile.
Il faut aussi noter que btrfs peut décider de stocker deux fois les métadonnées (le profil "DUP") mais on peut le forcer à ne les stocker qu'une fois.
# taille des inodes
Posté par magnetik (site web personnel) . Évalué à 8.
On a une idée de l'espace utilisé par les inodes justement ?
[^] # Re: taille des inodes
Posté par ʭ ☯ . Évalué à 3.
Ben il suffit de calculer : si on gagne 40Go en passant de 29M inodes à 4M, cela fait 625k inodes par Go, donc 625 inodes occupent un mégaoctet.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: taille des inodes
Posté par Olivier Jeannet . Évalué à 2.
Il me semble que la taille d'un inode est indiquée quand on utilise par exemple "dumpe2fs /dev/sdX1", et c'est pour mon disque système en ext4 :
Inode size: 256
# journalisation inutile pour les file systems en read only
Posté par Pascal Greliche (site web personnel) . Évalué à 8.
Dans certaines installations, un file system peut être quasiment en permanence en read only. Si on a un mécanisme pour se prémunir de panes de courant lorsqu'il passe en écriture (pour une mise à jour par ex), la journalisation ne sert à rien et on peut gagner de la place dans ce cas là.
Dans le même genre, toujours pour des file systems en read only, de la compression asymétrique peut être très intéressante. C'est consommateur en cpu/ram/temps pour la compression et presque rien pour la décompression.
[^] # Re: journalisation inutile pour les file systems en read only
Posté par feth . Évalué à 7.
Ça m'intéresse, je suis preneur d'un pointeur vers une documentation permettant de synchroniser des données en utilisant de la compression asymétrique (avec rsync ou autre).
# Espace réservé au super‐utilisateur
Posté par gpe . Évalué à 7.
Salut,
C'est peut-être bien plus connu mais pourrais-tu quand même expliquer un peu plus à quoi ça sert et pourquoi on peut le mettre à 0 ?
Merci.
[^] # Re: Espace réservé au super‐utilisateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 24 mai 2018 à 15:24.
(tiré de man mke2efs)
Étrangement ma question en lisant l'article était de trouver des applications au fait de réserver 100% à root…
[^] # Re: Espace réservé au super‐utilisateur
Posté par gpe . Évalué à 3.
Donc dans le cadre d'une machine ayant plusieurs disques il n'est nécessaire d'avoir cette espace que sur un disque, non?
[^] # Re: Espace réservé au super‐utilisateur
Posté par Sufflope (site web personnel) . Évalué à 7.
Non c'est utile sur toute partition où il est important, pour quelque raison que ce soit, que root puisse toujours écrire un peu quand le disque est presque plein. C'est-à-dire quasiment dans tous les cas (pour pouvoir écrire un message de log (ne serait-ce que pour prévenir que la partoche est remplie), ou un quelconque autre fichier requis pour faire le boulot de sauver les meubles après le remplissage de la partition).
Ca doit pouvoir se désactiver en toute sécurité uniquement sur une partition dont on est sûr qu'elle ne sert qu'à du stockage de fichiers d'utilisateurs finaux et ne contient aucun répertoire "système".
[^] # Re: Espace réservé au super‐utilisateur
Posté par gpe . Évalué à 5.
Donc sur un disque où il n'y a que /home on peut le virer ou au moins fortement réduire sa taille ?
[^] # Re: Espace réservé au super‐utilisateur
Posté par gUI (Mastodon) . Évalué à 5.
Oui, de ce que j'avais compris c'est que cette réserve ne sert que sur des partitions style '/', '/var' et '/tmp'.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Espace réservé au super‐utilisateur
Posté par patrick_g (site web personnel) . Évalué à 8. Dernière modification le 29 mai 2018 à 07:57.
C'est très utile pour les disques USB externes qui sont utilisés pour de la sauvegarde à froid de fichiers. Par exemple ma musique, mes films, mes photos.
Tout ça prend de la place donc je fais systématiquement un
tune2fs -m 0
sur ces disques.Même Ted Ts'o indique que dans ce cas de sauvegarde à froid cette manip n'a aucun inconvénient : https://www.redhat.com/archives/ext3-users/2009-January/msg00026.html
[^] # Re: Espace réservé au super‐utilisateur
Posté par Olivier Jeannet . Évalué à 7.
Pour ma part sur le disque système (sur mes machines) j'utilise toujours le paramètre "-m 1" parce que j'estime que 1 % de 6 Go c'est déjà pas mal pour dépanner, si jamais le "/" est plein pour l'utilisateur.
[^] # Re: Espace réservé au super‐utilisateur
Posté par gUI (Mastodon) . Évalué à 7.
Oui c'est presque à se demander si un pourcentage est encore pertinent. Quelle que soit la taille de la partition, un espace comme 100Mo est très confortable je pense.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Espace réservé au super‐utilisateur
Posté par Sufflope (site web personnel) . Évalué à 4. Dernière modification le 25 mai 2018 à 00:04.
J'imagine qu'avec les droits / SUID qu'il faut on doit pouvoir mettre à disposition des fichiers à des utilisateurs, qui pourront les supprimer, mais pas les remplacer en écrivant, un truc comme ça ?
Quant à savoir si c'est un cas intéressant : https://xkcd.com/1172/
[^] # Re: Espace réservé au super‐utilisateur
Posté par dj_ (site web personnel) . Évalué à 2.
Un des avantages c'est que si le home est complet, normalement la pc ne démarre pas.
Alors que là on peut se connecter en root, vu qu'il lui reste de la place ça fonctionne, et don peut supprimer quelques données dans le /home de l'utilisateur
[^] # Re: Espace réservé au super‐utilisateur
Posté par barmic . Évalué à 6.
Tu t'en fout pour ça. Si ton /home est pleins, le $HOME de root étant /root (en tout cas par défaut), il pourra toujours se connecter.
[^] # Re: Espace réservé au super‐utilisateur
Posté par dj_ (site web personnel) . Évalué à 2.
Ah oui, merci de m'avoir corrigé
# Pourquoi pas ext2 ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).
[^] # Re: Pourquoi pas ext2 ?
Posté par xcomcmdr . Évalué à 5.
Et ce sera illisible sur beaucoup de systèmes, à moins d'utiliser FAT32.
Qui n'a justement pas de journal, pas de sécurité, et pas d'espace réservè.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi pas ext2 ?
Posté par ʭ ☯ . Évalué à 8.
En fait ext4 sans journal fait quand même mieux que ext2. Il faut notamment réaliser que ext4 est un ext2 plus récent, avec plein d'améliorations en vitesse d'écriture, gestion des gros fichiers, etc autres que le journal.
Donc non c'est pas une bonne idée ext2.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Pourquoi pas ext2 ?
Posté par Sufflope (site web personnel) . Évalué à 3.
La vitesse d'écriture, sur une clé USB, elle sera pas forcément limitée par l'implem noyau du FS hein. Pour mettre 10 fichiers max dessus il doit y avoir pas mal de cas où ext2 fera le taff. Bon évidemment personne (statistiquement) ne pourra la lire, mais bon, en ext4 encore moins.
[^] # Re: Pourquoi pas ext2 ?
Posté par laurentb (site web personnel) . Évalué à 1. Dernière modification le 09 juin 2018 à 14:21.
Il est possible d'utiliser le driver ext4 pour gérer les partitions ext2 et ext3 (CONFIG_EXT4_USE_FOR_EXT2).
# Quid des autres systèmes ?
Posté par AlexTérieur . Évalué à 2.
Désolé de casser l'ambiance, mais de mon côté, tôt ou tard j'ai été confronté à du Windows donc au moment de formater une clé USB, j'en ai tenu compte… Il faudrait peut-être aussi voir de ce côté, ext2/3/4 n'étant pas reconnu (hélas).
[^] # Re: Quid des autres systèmes ?
Posté par ʭ ☯ . Évalué à 4. Dernière modification le 24 mai 2018 à 22:23.
Cet article ne visait pas seulement les clés USB, et pas spécialement l'inter-opérabilité avec Microsoft.
Mais puisque tu lances la discussion, NTFS est tellement plus lent que ext4 sous Linux en USB que je l'ai exclus de tous mes disques. Je n'obtiens jamais plus de 2/3 de la vitesse Ext4 en NTFS, et avec le processeur nettement plus occupé.
FAT32 de son côté n'accepte pas de fichiers de plus de 4Go, c'est prohibitif pour mes films dès 720p…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quid des autres systèmes ?
Posté par gpe . Évalué à 2.
Pour les fichiers de plus de 4 Gio il y exFAT.
[^] # Re: Quid des autres systèmes ?
Posté par Yves (site web personnel) . Évalué à 2.
Ou UDF : https://github.com/JElchison/format-udf
[^] # Re: Quid des autres systèmes ?
Posté par Joël Thieffry (site web personnel) . Évalué à 6.
J'ai branché sur mon RaspberryPi un disque-dur USB de 2 To rempli, rempli de musiques copiées depuis un poste Windows, dans le but d'en faire un jukebox.
À l'origine formaté en NTFS, le driver ntfs-3g saturait le pauvre RaspberryPi en permanence, l'amenant en surchauffe et faisant baisser violemment sa réactivité (plus de 30 secondes pour se connecter dessus en SSH via le LAN).
J'ai donc fait l'inverse : formatage en ext4, re-remplissage sans problème depuis le poste Windows à l'aide du driver Ext2Fsd. Depuis, le RaspberryPi n'a plus de soucis.
[^] # Re: Quid des autres systèmes ?
Posté par Ambroise . Évalué à 3.
Par hasard, comment gères-tu les droits uid/gid quand tu partages la clé entre des linux différents ?
Ça m'intéresse pas mal…
[^] # Re: Quid des autres systèmes ?
Posté par ʭ ☯ . Évalué à 3.
Il n'y a pas de linux différents, mais une gestion des comptes utilisateurs. Il suffit de donner les droits lecture/écriture à tout le monde quand tu partages la clé, et cela permettra ce que tu veux.
Par défaut, tout nouveau dossier créé avec ntfs-3g a ces droits, rien ne t'empêche de faire le même choix avec Ext4. Mais par défaut, nos distributions préfèrent sécuriser, et les dossiers sont créés avec les droits pour l'utilisateur seulement, comme pour le dossier personnel dans /home.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quid des autres systèmes ?
Posté par Olivier Jeannet . Évalué à 7.
J'ai un disque externe de 2 To formaté en NTFS au cul de mon mini-PC de salon (xubuntu), j'y stocke mes enregistrements de la TNT et il est dans ce format pour que je puisse l'apporter chez des connaissances et le lire partout, même si c'est peu fréquent.
J'avais remarqué que l'occupation CPU n'était pas négligeable, alors qu'il est encore sur un port USB 2 donc limité à 35 M/s, et j'ai un peu creusé. J'ai donc ajouté une entrée dans la fstab, en m'inspirant des valeurs issues du montage automatique, et en rajoutant le mot-clé big_writes aux options.
Elle permet de passer les transferts de buffers de seulement 4 k (par défaut à cause de FUSE) à des buffers de 128 k, et ça joue clairement sur le CPU (un Celeron Ivy Bridge à 1,8 GHz) ; c'est indiqué dans le man de ntfs-3g. Le jour où je passe à l'USB 3 côté ordinateur je pourrai aussi voir si ça joue sur la vitesse absolue, le disque étant déjà USB 3.
En tous cas ça permet de constater qu'ext4 est assez performant côté CPU, je crois qu'il a toujours été meilleur que les autres FS.
[^] # Re: Quid des autres systèmes ?
Posté par xcomcmdr . Évalué à 2.
Sous Windows, je n'ai pas ces problèmes d'usage CPU.
J'ai pu constater moi aussi ces problèmes avec ntfs-3g, quand j'étais sous Linux.
Mais ce n'est pas une question de FS, mais d'implémentation.
Il faut se rappeler aussi que NTFS est vieux, la version actuelle n'a pas bougé depuis XP.
C'est un FS qui a connu les premiers Pentium, alors bon, sous Windows c'est optimisé depuis longtemps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quid des autres systèmes ?
Posté par Ambroise . Évalué à 1.
Le problème, c'est que ce n'est pas intuitif pour l'utilisateur occasionnel.
Perso, je préfèrerais un FS qui ne gère pas du tout les permissions.
Plutôt type UDF…
[^] # Re: Quid des autres systèmes ?
Posté par Epy . Évalué à 3.
Il y a quelques années je suis tombé sur ce journal : https://linuxfr.org/users/elessar/journaux/acl%C2%A0-la-solution-pour-les-media-de-transport-de-donn%C3%A9es-en-ext2
Depuis je répète cette manip dès que j'ai un média qui ne sera partagé qu'entre des Linux (même les NAS commerciaux des potes souvent)
Suite à cette lecture je testerais bien avec ext4 sans journal, s'il est meilleur qu'ext2 ..
[^] # Re: Quid des autres systèmes ?
Posté par xcomcmdr . Évalué à 4.
Il n'y a pas que Windows.
Quasi tout ce qui peut lire depuis un système de stockage de masse via une connexion USB ne lira rien du tout si ce n'est pas en FAT32 ou NTFS, plutôt que ext/btrfs/xfs/autre fs libre.
Liste non-exhaustive :
- La télé
- L'ordi du voisin
- Le MacBook
- Le lecteur DVD/Bluray
- La console de jeu
- …
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quid des autres systèmes ?
Posté par ʭ ☯ . Évalué à 5.
Au moins une exception : les Freebox.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quid des autres systèmes ?
Posté par raphj . Évalué à 7.
J'ai été surpris de tomber sur un enregistreur TV qui stockait les enregistrements dans un disque dur externe qu'il avait formaté en ext4. C'était peut-être même la télé elle-même.
Finalement, beaucoup d'appareils fonctionnent sous Linux. De là à ce que ext4 pour les périphériques externes soit pris en charge, il y a effectivement un pas. D'autant que la gestion des droits UNIX peut effectivement venir en travers du chemin sur périphériques externes.
Sous Android, on peut utiliser une carte SD formaté en ext4. Sous Nougat, il fallait que je la monte en ligne de commande, sous Oreo ça a l'air d'être reconnu comme n'importe quelle carte SD classique.
Et du coup, grâce à cette dépêche, j'ai pu constater qu'on peut lancer tune2fs -O has_journal depuis Android lui-même (en root).
Est-ce que quelqu'un a essayé de brancher un disque dur externe formaté en ZFS sur la Play Station 4 ? :-)
[^] # Re: Quid des autres systèmes ?
Posté par barmic . Évalué à 2.
Ils n'ont pas de support d'UDF ?
# Espace libre qui varie en fonction de la taille du blockdevice
Posté par yoyz . Évalué à 7. Dernière modification le 25 mai 2018 à 10:27.
La méthodologie pour vérifier l'espace libre est incomplète dans ce test sur "Cas d’une clef USB de 1 Gio".
Ou plutôt cette phrase est incorrect : "Cela permet de remplacer les valeurs en Mio par Gio pour un disque d’un téraoctet, bien plus courant aujourd’hui"
J'avais eu à faire le test il y a quelques mois pour cerner l'espace libre après formatage ext4.
Si on crée un ext4 sur espace de stockage de 100MB, 1 000MB, 100 000MB, on va constater que le pourcentage d'espace libre évolue dans le bon sens…
100MB : 7% d'espace occupé par la structure de ext4
1 000MB : 3% d'espace occupé par la structure de ext4
100 000MB : 1% d'espace occupé par la structure de ext4
[^] # Re: Espace libre qui varie en fonction de la taille du blockdevice
Posté par ʭ ☯ . Évalué à 4.
Ha oui, je viens d'avoir l'idée d'essayer sur un fichier pour aller vite, et confirme que le pourcentage s'améliore. Donc mon extrapolation pour un téraoctet est fausse.
Je viens d'essayer sur un fichier de 100Go, et j'obtiens :
C'est quand même plutôt 2% d'espace occupé par la structure de ext4, comment arrives-tu à 1%?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Espace libre qui varie en fonction de la taille du blockdevice
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Du coup, tu as déduit une formule du type consommation structurelle = taille fixe + pourcentage du volume * taille du volume ? (le tout en fonction de la taille des blocs ?).
[^] # Re: Espace libre qui varie en fonction de la taille du blockdevice
Posté par ʭ ☯ . Évalué à 4. Dernière modification le 25 mai 2018 à 16:19.
Non, je suis pas assez matheux pour ça. J'ai ce miniscript, ça ne fait pas le calcul tout seul, mais voici de quoi afficher ce que donnent les différentes options de formatage en Mo sans se fatiguer. ATTENTION, ça formate pour de vrai le périphérique/fichier indiqué en paramétre!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Espace libre qui varie en fonction de la taille du blockdevice
Posté par ʭ ☯ . Évalué à 3. Dernière modification le 25 mai 2018 à 15:51.
Je complète avec un disque USB de 2To :
Cela fait toujours 1,7% de gain…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# ext4, le meilleur "par défaut" ?
Posté par Denis Szalkowski . Évalué à 5.
Deux remarques.
Sur quoi te fondes-tu pour dire que ext4 est le meilleur, sachant que tu ne parles pas des autres ?
Xfs est le système par défaut sur CentOS/Red Hat/Fedora. L'immense majorité des distributions Linux ne se réduirait-elle pas, de ton point de vue, à Debian/Ubuntu ?
[^] # Re: ext4, le meilleur "par défaut" ?
Posté par Doug Le Tough (site web personnel) . Évalué à -10. Dernière modification le 09 juin 2018 à 18:40.
Pour ma part je considère qu'ext4 fait partie des pires FS disponibles (ext3 étant encore pire).
C'est souvent le problème avec les technos libres. Certaines sont décrétées "top moumoute" sans aucun argument par on ne sait qui et cet avis est répété à outrance jusqu'à ce qu'il soit partagé par un très large nombre de personne.
Il existe un véritable manque d'objectivité dans la communauté du libre.
Heureusement ce manque d'objectivité n'est pas systématique mais il n'empêche qu'il est inquiétant d'autant plus qu'on assiste parallèlement à des comportements qui s'approchent grandement du Théorème du singe.
[^] # Re: ext4, le meilleur "par défaut" ?
Posté par claudex . Évalué à 10.
J'aime bien le principe de critiquer le manque d'arguments sans en donner soi-même.
« 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: ext4, le meilleur "par défaut" ?
Posté par Doug Le Tough (site web personnel) . Évalué à -6.
Ça fait justement partie de la démonstration ;-)
[^] # Re: ext4, le meilleur "par défaut" ?
Posté par ʭ ☯ . Évalué à 3.
Xfs n'est le système par défaut que pour les serveurs. Les stations de travail CentOS/Red Hat/Fedora continuent avec ext4. Pour ma part, j'utilise Mageia, qui fait aussi du ext4 par défaut, c'est même pas du Debian ;-)
Mais effectivement, je postulais sans preuve. Il semblerait que xfs avance bien en ce moment, avec du online fsck en préparation pour le noyau 4.16!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.