Merci pour ta réponse. Celà répond en partie à ma question.

Dans mon cas, cela signifie donc que le kernel est OK (puisque je suis en
2.4).

Reste donc

> le filesystem EXT2 : Comment savoir si une limitte est fixée ? je l'ai crée
de base sans modifier de paramètres.
> les librairies C peuvent elles être mises à jour ?
> Les application user-space ? une application de base de donnée par exemple ?



merci pour tes lumières :o)

Alexandre Dulaunoy a écrit :

>         Le problème n'est pas si  simple. Les limites sont à plusieurs
>         endroits dans le système :
>
>         - Le Kernel
>         - Le filesystem lui-même
>         - Les librairies C
>         - Les application user-space
>
>         Le Kernel depuis  le 2.4 supporte le LFS  (Large File Support)
>         car en  fait avant  les calls l_seek  & co retournait  sur une
>         machine 32bits. La valeur signée de 32 bits ne pouvait exprimé
>         pas plus de 32bits.
>
>         Donc  LFS  est disponible.  Maintenant  le  problème, il  faut
>         l'utiliser.
>
>         C'est à dire comme les libraries C incluent des nouveaux calls
>         pour  retourner  des  valeur  sur  64bits  (sur  des  machines
>         32bits), par ex. fopen64 ... (ce qui est le cas avec GLIBC2.2)
>
>         Bien entendu, il faut que les programmes en user-space utilise
>         cela genre compilé avec  des macros spécifiques. Mais qui font
>         plusieurs  trucs comme  le return  en  64 bits  ou co...  Bien
>         entendu, il faut utiliser aussi les bons calls.
>
>         Je  dirais que la  majorité des  applications bien  écrites ne
>         posent pas de problème.
>
>         Je n'ai pas encore parlé du  FileSystem ;-) En fait, tu as des
>         fs qui utilisent LFS (comme ext2 dans le 2.4 ou ext3). Mais tu
>         as aussi  des fs qui  sont limités à  2Gb pour des  raisons de
>         conception.
>
>         Je peux  entrer dans plus  de détails mais  je ne sais  pas si
>         cela répond à ta question.
>
>         adulau
>
> --
>                               Alexandre Dulaunoy -- http://www.foo.be/
>   3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD  ---   AD993-6BONE
> "People who fight may lose.People who do not fight have already lost."
>                                                         Bertolt Brecht
>
> On Mon, 14 Oct 2002 [EMAIL PROTECTED] wrote:
>
> > Bonjour la liste,
> >
> > Suse linux 7.2
> >
> >
> > Je suis confronté à un petit problème sur certaines machines de
> > production.
> >
> > J'ai besoin d'utiliser des fichiers de + de 2 Go. Or, il semble que 2 Go
> > soit justement la limitte acceptable par le système. Je peux créer les
> > fichiers, mais il est impossible de les manipuler. Je suis obligé de les
> > supprimer. S'agit il d'un particularité de la suse ?
> >
> > Lorsqu'on regarde la définition du système de fichier EXT2, il s'avère
> > que pour un processeur 32 bits, le plus gros fichier peut faire 4Go.
> > Comment expliquer cette différence ? On peut donc créer un fichier de +
> > de 2 Go, mais on ne pas l'utiliser ?
> >
> > J'ai du mal à éclaircir la situation.
> >
> > Merci d'avance pour vos réponse.
> >
> > --
> > Sincèrement,
> >
> > jm.aries
> >
> >
> > _______________________________________________________
> > Linux Mailing List - http://www.unixtech.be
> > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
> > Archives: http://www.mail-archive.com/linux@lists.unixtech.be
> > IRC: efnet.skynet.be:6667 - #unixtech
> >
> >
> >
>
> _______________________________________________________
> Linux Mailing List - http://www.unixtech.be
> Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
> Archives: http://www.mail-archive.com/linux@lists.unixtech.be
> IRC: efnet.skynet.be:6667 - #unixtech

--
Sincèrement,

jm.aries
Imprimeries IPS


_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: efnet.skynet.be:6667 - #unixtech

Répondre à