[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux limitations



On Sun, May 23, 1999 at 02:08:33AM +0300, Liran Zvibel wrote:
> > File size, not partition size. File size is limited by the size of the
> > "file size" field in the kernel structures. If it's "integer", than on
> > 32bit machine it's 2G.

> It is not set to integer. It is set in BITS:
> /*
>  * Structure of an inode on the disk
>  */
>   struct ext2_inode {
>           __u16   i_mode;         /* File mode */
> 	  __u16   i_uid;          /* Owner Uid 
> 	  __u32   i_size;         /* Size in bytes */
> 	^^^^^^^^^^^^^^^^^

Actually, if you look carefully in the code, you would see that there are
special cases handling larger files (i_high_size). Look for preprocessor
checks for 'BITS_PER_LONG < 64'.
That __u32 above is, indeed, 32-bits - regardless of your later post 
(otherwise, the filesystem wouldn't be compatible across platforms -
which it certainly is).
When the kernel uses __u32, the kernel means 'unsigned 32-bits wide',
otherwise those names would mean nothing...

> So the "32 bitness" of the processor is not the factor. A very easy solution
> would be to use unsigned instead of signed ( and then we would get 4GB).

It really *isn't* a factor. I believe that if you really want, it shouldn't
be terribly complicated to use the same enhancements as done on Alpha to
support files larger than 2^31 on i386 too, quite possibly paying in CPU
cycles (as the i386 can't natively do 64-bit arithmetic). I don't know how
fundamental such a change might be - it might require changing internal
kernel structures that keep file positions, which would mean you pay for
this change everywhere, not only when accessing ext2.
(Note that, as far as I could gather from the sources, you can *read*
files larger than 2^31 even on i386 (as long as you don't write to them),
which looks promising in that respect).

                                                   Nimrod