[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