[lkml]   [1999]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: breaking the 2Gigabyte limit on 32 bit arch of inode->i_size (off_t vs loff_t)
Andrea Arcangeli <> replied:
> > Andrea, have a look at:
> >Essentially I just pushed ahead and used loff_t.
> I seen now. But I don't agree in some point with your code.
> As first I don't agree with the page->offset long long (and if I remeber
> well also Linus said the same), because in the page->offset we just have
> 12 wasted bits (ignoring the swap cache entries that can be changed). So
> instead of adding new 32bits we should start using the 12 bits we are
> currently wasting.

No, I am not doing *that*. Page-cache methods are using
32-bit 'page offsets' which are scaled from loff_t offsets
to internal values by means of '>> PAGE_SHIFT'.
That is what gives 4G*PAGE_SIZE maximum file size limit.
(Just because doing 64-bit integer processing is rather
painfull at i386 ...)

The 'struct file' things need loff_t in several locations,
where they weren't used (ia_size, i_size, read-ahead things,
and lock things.)

> And I don't think it worth to allow mmap on the high part of the file.

Well, our mileages do vary. That code has been part of
Large-File-Summit support, which does have mmap64().
In the mm/mmap.c the change is -2/+3, that is, nothing
at all mmap() specific, most of the machinery is needed
elsewere to support read() and write()... Just supplying
64-bit interface by means of mmap64() is peanuts.

> Your code also showed me that the changes to handle 2gigabyte are more
> invasive of what I thought, maybe we are too much near to an ia-64 to
> expect that the kernel will change this way to handle 2gigbyte files on
> ia-32. I really don't know...
> Comments?

Lets see ... there is stuff all over the filesystems related
to *pathconf(), and several tests so that the system does not
use the FS in ways which it can't do -- exceeding 2G limits in
systems unable to do it intrinsically, for example.

The support of Large-File-Summit things is major bulk of the
code, and frankly without it the compability with existing
application code is problematic.

> Andrea Arcangeli

/Matti Aarnio <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.040 / U:6.636 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site