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.
