On Mon, 12 Nov 2001, Pierre Maitre wrote:
> Question: pourquoi les filesystems linux (ext2) n'ont-ils jamais besoin
> d'�tre "d�fragment�s"?
D�finitions:
fragmentation, sens BSD (FFS)
Le fait de prendre des blocs d'allocation minimale du syst�me de
fichier concern� (p.ex. 8192 octets en FFS usuel), et de les
allouer � _plusieurs_ fichiers diff�rents (ce qui permet de ne
pas gaspiller des blocs, tout en ayant une grande taille de bloc
qui rend les I/Os performantes). Les fragments sont p.ex. de
taille 1024 bytes. En g�n�ral, la granularit� d'allocation est
de 8192 bytes. Pour le dernier bloc d'un fichier on peut allouer
moins (en multiple de 1024) et le reste peut �tre allou� pour un
petit fichier.
ext2 ne supporte pas les fragments au sens BSD: une allocation de
4096 bytes (maximum sur ix86 32 bits) peut gaspiller au plus 4095
bytes.
-> sub-allocation
fragmentation, sens MS-DOS
le fait que l'allocation de tous les blocs d'un fichier n'est pas
contigu� (v�rifi� dans le dictionnaire :)), d'o� perte de
performance � cause des seek()s (positionnement des t�tes) du
disque.
-> non-contiguous
Dans ce qui suit on parlera de fragmentation au sens MS-DOS. Notons que
les versions pas trop anciennes de e2fsck parlent de `non contiguous'; les
plus anciennes de `fragmentation'.
Reprenons la question: ce n'est pas tout � fait vrai. Disons qu'un syst�me
de fichier ext2 a moins de chance de se fragmenter car:
- 5 � 10% de la capacit� est r�serv�e � root (papier FFS)
un syst�me de fichiers qui n'est pas plein � plus de 90%
a de bonnes caract�ristiques qui permettent pour les fichiers
de taille usuelle de trouver des s�quences de blocs contigu�s
cf tune2fs
- l'administrateur surveille son syst�me et �vite les conditions
de disque plein
- ext2 travaille avec un principe de pr�allocation: si un fichier
fait 4 KB, ext2 pr�alloue quelques blocs du filesystem � la suite.
Si finalement ces blocs ne sont pas n�cessaires, ils sont tout de
m�me utilis�s (en derni�re priorit�) si le fs devient rempli.
L'extension d'un fichier avec quelques blocs se produit donc
de fa�on s�quentielle.
- Linux poss�de un syst�me de caching tr�s agressif qui peut
bien souvent camoufler de tels probl�mes.
- ext2, comme FFS et descendants, ne remplit pas le disque � la suite,
mais r�partit sur les diff�rents data groups.
Par exemple, mon serveur de news principal, syst�me de fichier ext2 � 1024
bytes/block, fs cr�� en 1996, consistant principalement en de petits
fichiers de 4k � 16k pour la plupart, a une non-contiguit� d'environ 5%
apr�s 5 ans. Est-ce un probl�me ? Pas � mon avis: dans mon cas c'est
plut�t la relative inefficacit� du stockage de 10'000 fichiers ou plus par
r�pertoire -> probl�me � corriger au niveau de INN (utilisation du nouveau
syst�me de stockage), voire �ventuellement au niveau du syst�me de fichier
(FIST avec pseudo-r�pertoires de h�chage, ext2 avec patch de performance,
voire reiserfs).
Autre exemple: machine de travail personnel, syst�me de fichier cr��
cet �t�, parfois rempli � 100%, 4KB de block size:
defian:/home/schaefer# umount /scratch/ && e2fsck -f /dev/hda12 && mount /scratch
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda12: 8839/563360 files (4.4% non-contiguous), 702764/1124542 blocks
Comment conna�tre la fragmentation (sens MS-DOS) ? La commande fsck
(e2fsck) l'indique (option -f, sur un syst�me de fichier d�mont�).
Quand est-ce un probl�me ? Tr�s subjectif.
Comment le corriger ?
- achat d'un nouveau disque, copie des donn�es
(assez raisonnable apr�s quelques ann�es)
- backup/restore du fs
- e2fsdefrag (cette commande existe. Vaut-il la peine de tenter
une commande que personne ou presque n'utilise ?)
> pour stocker toute ma correspondance StarOffice. Lorsque Linux �crit sur
> une partition FAT32, cette partition est-elle sujette � la m�me maladie
> de la fragmentation que si c'est Windows qui �crit sur cette partition
> FAT32?
Oui (si le buffer-cache de Linux travaillait comme IRIX, on pourrait dire
non. Malheureusement Linux alloue au fur-et-�-mesure: il cache les
donn�es, mais n'attend pas le dernier moment pour d�cider o� les mettre,
et sauf erreur avec FAT32 il n'y a pas de pr�allocation possible de
blocs).
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
