Messages in this thread | | | Subject | Re: breaking the 2Gigabyte limit on 32 bit arch of inode->i_size (off_t vs loff_t) | Date | Sun, 21 Mar 1999 22:32:35 +0200 (EET) | From | Matti Aarnio <> |
| |
Andrea Arcangeli <andrea@e-mind.com> replied: > > Andrea, have a look at: ftp://mea.tmt.tele.fi/linux/LFS/ > >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 <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |