On 10 Oct 2000, Francois Deppierraz wrote:
> Avec ce système n'y a-t-il plus de problèmes de taille de fichier ? Si
> oui, quelle partie du système impose la limite de 2 Go (kernel,
> filesystem, libc) ?
Le problème est que sous Linux la gestion de fichiers (au niveau du VFS)
est implémenté par memory mapping, et qu'une adresse, avec un ix86, x >=
3, occupe au maximum 32 bits. De plus, toutes les interfaces user-space
(comme p.ex. seek(2), cf le type off_t) sont 32 bits. gcc supporte le
type long long, qui est 64 bits. Mais en architecture ix86, surtout avec
le nombre ridiculement petit de registres disponibles, cela aurait imposé
une perte de performance et des complications: du moins c'est la raison
qui a poussé Linus Torvalds à refuser toute modification en ce sens.
Au niveau de la gestion des block-devices, on utilise un 32 bit, oui, mais
c'est un numéro de block (avec 512 ou 1024 bytes/block suivant à quel
niveau on regarde).
Sauf erreur la façon dont cela a été implémenté est de définir de
nouvelles interfaces `64 bit pour systèmes 32 bits' (le LFS, Large File
Summit), standard qui est multiplateforme (sauf erreur Solaris, IRIX, *BSD
et maintenant Linux). Une application est ensuite marquée comme 64-bit
clean ou non (par un #define _LFS_SOURCE, ou par un flag runtime, je ne
connais pas les détails). Par exemple, l'application `cat' est forcément
compatible car elle ne traite pas les offsets. Mais une application comme
PostgreSQL p.ex. doit être modifiée, et testée: tant qu'elle n'est pas
`64bit-clean', ou plutôt `LFS-clean', elle ne peut accéder au fichier que
via les anciennes interfaces, et donc tout accès écriture sur un fichier >
2 GB est interdit (car imagine ce qui pourrait se passer si il y a
wrap-around, p.ex.). Ces nouvelles interfaces sont celles qui seront
ensuite recommandées, et ce seront les mêmes pour tous les UNIX supportant
LFS, qu'ils soient 32 ou 64 bits.
Au niveau du kernel, désormais, toute page de VM pour le fs est composée
du couple (bloc, offset) à la place de l'adresse virtuelle, donc évite les
problèmes de long long. Enfin c'est comme ça que Andreas Archangeli avait
implémenté un de ses patches il y a fort longtemps.
Au niveau de la libc, les corrections ont été effectuées sauf erreur dans
la 2.1.
Les seules applications qui poseront problèmes sont celles qui demandent
ou fixent la position dans un fichier (llseek()), qui lisent ou écrivent
séquentiellement et maintiennent leurs propres compteurs mal dimensionnés,
et celles qui utilisent l'ancien appel stat() pour la taille du fichier.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question.
