[Digression] Comment partitionner ses DDs (Disques Durs)

Pause Café
#21

[quote=“L0u!$”]moi j’ai fait la bêtise de ne pas faire de /var séparé sur mon serveur, et un jour les logs ont explosé, 20Go de logs … donc, en solution de récup, j’ai mis /var en lien symbolique à la racine, le vrai se trouve dans /home .
ça fonctionne sans problème mais ce n’est pas très propre…
Par contre pour ma machine principale, je conseille de prévoir 20Go ou + pour / car avec des grosses applis et des jeux ça grimpe vite.

Et pour augmenter la taille de 8 Go à 20, ça m’a pris au moins une demi-journée car ma partition racine était la première, toutes les données de /home ont dû être décalées vers la droite.[/quote]

Vous y viendrez à LVM ! C’est après des mésaventures de ce genre que j’ai fini par admettre :slightly_smiling:

Et je te parles pas d’une machine qui change d’attribution (serveur <==> bureau) sans réinstallation :041

#22

[quote=“lol”]Re,

[quote]root@nas:~# tune2fs -m 0 /dev/sdc1
tune2fs 1.41.12 (17-May-2010)
Initialisation du pourcentage de blocs réservés à 0% (0 blocs)
root@nas:~# nano /etc/fstab
root@nas:~# mount -a
root@nas:~# df -H
Sys. de fichiers Taille Util. Disp. Uti% Monté sur
…
/dev/sdc1 985G 320G 666G 33% /mnt/sdc1
[/quote]

Bon… Je suppose qu’il faut formater maintenant…[/quote]

Fais donc un e2fsck avant !

#23

Salut,
Fait!

[quote]root@nas:~# tune2fs -m 0 /dev/sdc1
tune2fs 1.41.12 (17-May-2010)
Initialisation du pourcentage de blocs réservés à 0% (0 blocs)
root@nas:~# e2fsck /dev/sdc1
e2fsck 1.41.12 (17-May-2010)
/dev/sdc1 : propre, 11/61054976 fichiers, 3883091/244190000 blocs[/quote]

Mais là ou j’ai “les boules”… C’est qu’en fat32 j’ai 1To… :017

[quote]root@nas:~# mkfs -t msdos /dev/sdc1
mkfs.msdos 3.0.9 (31 Jan 2010)
root@nas:~# nano /etc/fstab
root@nas:~# mount -a
root@nas:~# df -H
Sys. de fichiers Taille Util. Disp. Uti% Monté sur
…
/dev/sdc1 1,0T 17k 1,0T 1% /mnt/sdc1[/quote]

extfs me vole 15Go. C’est beaucoup, non ?

#24

Bon,
Je me suis collé les 15Go derrière l’oreille, tant pis. Je préfère quand même ext4 à fat32… 10 ans d’écarts de technologie environ… :mrgreen:

Je suppose que c’est à cause de la journalisation ?

#25

Je ne pense pas que ce soit bon de virer cette fonctionnalité sur /. Mais il est possible de le diminuer (2% par exemple).
Pour ce qui est de la capacité de ton disque lol, faut pas trop te référer à ça. La fragmentation de fat va de toute manière t’empêcher de t’en servir correctement.
Il est de toute manière illusoire d’imaginer pour voir organiser des données sans occuper d’espace.

#26

Salut,

[quote=“MisterFreez”]Je ne pense pas que ce soit bon de virer cette fonctionnalité sur /. Mais il est possible de le diminuer (2% par exemple).
Pour ce qui est de la capacité de ton disque lol, faut pas trop te référer à ça. La fragmentation de fat va de toute manière t’empêcher de t’en servir correctement.
Il est de toute manière illusoire d’imaginer pour voir organiser des données sans occuper d’espace.[/quote]

Non, c’est juste un disque de données, je ne ferais pas ça sur des partitions systèmes.
Je voulais juste comprendre.
Tu sais si c’est la journalisation les 15Go “perdus” ?

#27

Je ne suis pas sur mais je pense que c’est plutôt la taille des secteurs ou inodes par défaut…

Ext4 utilise des secteurs plus larges que son prédécesseur ext3, mais ça bouffe plus d’espace pour les petits fichiers.

#28

Le journal bouffe de la place:
EXT3[quote]/dev/loop0 495844 10543 459701 3% /mnt
[/quote]EXT2

[quote]/dev/loop0 495844 2318 467926 1% /mnt
[/quote]
VFAT:

[quote]/dev/loop0 511728 0 511728 0% /mnt
[/quote]
Comme tu vois VFAT ne consomme rien ou presque, ext2 consomme 0,45% du disque et EXT3 2,1% soit en gros 20G sur un disque de 1T (ça n’est donc pas linéaire en fait mais tu as l’ordrte de grandeur).

(Même nombre de blocs mis à part les 5% réservés par ext2 et ext3 que je n’ai pas enlevé, la taille des blocs est identique, par contre il y a une histoire de taille de cluster qui n’a rien à voir ici, un cluster prend un ou plusieurs blocs et les fichiers se voient attribuer des clusters. Mis à part VFAT, je crois que les système de fichiers ont tous adoptés le cluster réduit à un bloc).

#29

Salut,
Merci pour l’explication. C’est donc bien le journal, tant pis!

#30

Moi je dirais non, je pense que ce sont les structures internes (extent par exemple).
Le journal n’a lieux d’avoir une taille importante quand tu viens juste de formater ton disque dur (à moi qu’il lui alloue une taille fixe au début qui ne bouge plus par la suite mais ce serais dommage).

#31

Misterfreez, c’est un essai sur un disque que j’ai formatté des 3 façons différentes. Par contre la différence entre les 495844 de ext2 et ext3 et les 511728 ne vient pas des 5% mais bien des blocs systèmes. Au final ça fait quand même pas mal de place perdue (en gros 3%)… par ext3 sur le disque. Sur un disque d’un Tera, ça finit par faire beaucoup…

#32

Oui mais ce qu’il faut voir c’est pourquoi est ce utilisé. Sur un disque d’1Tio, en usage “normal” (création de fichiers de tailles variables, suppression, redimensionnement des fichiers,…) tu te retrouve avec une fragmentation qui empêche d’utiliser l’ensemble de l’espace disque. Au passage la défragmentation demande à avoir un certains pourcentage d’espace libre, donc tu as une limitation implicite à peut être 95~98 % du disque.
Avec ext3 tu as une gestion des fichiers bien plus sophistiquée qui permet de limité la fragmentation. Ce qui permet d’utiliser plus d’espace disque.
Avec ext4 en plus d’avoir une fragmentation encore plus faible qu’avec ext3 on a une gestion intelligente des petits fichiers ce qui permet de ne pas perdre d’espace pour les petits fichiers.

#33

En quoi la fragmentation empêche-t-elle d’utiliser tout l’espace du disque ?

#34

Tu as raison c’est surtout un problème de performance.

Mais tu as aussi de l’espace perdu à cause de la fragmentation. Chaque bloc de données sur un disque dur possède une entête ou des métadonnées. Ces métadonnées utilise une taille généralement fixe. Avec une fragmentation importante tu te retrouve dans deux situations :
[ul]
[li]soit tu as des espaces libres inutilisables car ils sont trop petits pour mettre l’entête plus des données[/li]
[li]soit le système de fichier est capable de détecter ces cas lors des allocation précédentes et va allouer plus d’espace à un bloc qui a priori n’en a pas besoin parce que de toute manière ce seras de l’espace perdu.[/li][/ul]

Les extents d’ext4 permettent de limiter se phénomène en limitant au maximum la fragmentation.

Btrfs (et peut être ext4 je sais plus) stocke les petits fichiers directement dans la structure de gestion sans passer par les extents ce qui permet de gagner de la place.

#35

En tout cas, je sais que j’ai cassé des disques sous Windows car ils étaient trop remplis.
Je m’étais fixé comme seuil de remplissage 70/80%

J’avoue que je ne sais pas trop sous linux avec ext… ?

#36

Je ne crois pas, non. En tout cas pas en ext2/3. Chaque inode possède des méta-données, mais pas les blocs de données.

En ext2/3 les blocs sont de taille fixe et la taille d’un espace libre est un multiple de la taille d’un bloc, donc je ne vois pas comment ça pourrait arriver.

#37

[quote=“lol”]En tout cas, je sais que j’ai cassé des disques sous Windows car ils étaient trop remplis.
Je m’étais fixé comme seuil de remplissage 70/80%[/quote]
Sans rire ?
Sur mon poste Windows, les partitions en FAT32 et NTFS de 4 Go dont la partition système ont entre 10 et 30 Mo d’espace libre depuis des années, RAS.

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda1 2.0G 1.8G 43M 98% /
en ext2, avec tout dessus sauf le swap. Oui, c’est un petit disque, celui de ma passerelle internet.

#38

Salut,

[quote=“PascalHambourg”][quote=“lol”]En tout cas, je sais que j’ai cassé des disques sous Windows car ils étaient trop remplis.
Je m’étais fixé comme seuil de remplissage 70/80%[/quote]
Sans rire ?
Sur mon poste Windows, les partitions en FAT32 et NTFS de 4 Go dont la partition système ont entre 10 et 30 Mo d’espace libre depuis des années, RAS.

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda1 2.0G 1.8G 43M 98% /
en ext2, avec tout dessus sauf le swap. Oui, c’est un petit disque, celui de ma passerelle internet.[/quote]

Merci pour les infos, intéressant.

Oui, sans rire…

Il s’agissait la plupart du temps de disques avec de gros fichiers (plus de 500Mo) avec beaucoup d’écritures et effacements. Au bout d’un certain temps ça ramait de plus en plus, et pour finir, le bras se coinçait… Je parle de remplissages de l’ordre de 90-95% sur de disques de 250 à 500 Go. si je me souviens j’ai eu ce problème en fat32 et ntfs. Sur les disque ntfs, les fichiers étaient vraiment plus gros (beaucoup plus de 2 Go - je m’amusais à faire du montage de vidéos capturées avec une carte).

#39

Je ne crois pas, non. En tout cas pas en ext2/3. Chaque inode possède des méta-données, mais pas les blocs de données.

En ext2/3 les blocs sont de taille fixe et la taille d’un espace libre est un multiple de la taille d’un bloc, donc je ne vois pas comment ça pourrait arriver.[/quote]
Je parlais de FAT que je crois connaitre un peu mieux qu’ext2/3.

#40

FAT est encore plus simple qu’ext2/3, avec aussi des blocs de taille fixe sans en-tête ni méta-données.