Messages in this thread | | | Subject | Re: VFS 64-bit clean | Date | Tue, 24 Feb 1998 19:14:06 +0200 (EET) | From | Matti Aarnio <> |
| |
Jim Nance writes: > Hi All, > On Tue, Feb 24, 1998 at 10:08:55AM +0100, Pavel Machek wrote: ..... > > > * support for large files that can be mmap'ed, or just read? > > > > Reading is enough. Usually, noone tries to mmap such files. (I know, > > it gets a bit messy...) > > I mmap() large files all the time under Digital Unix, so people do do > such things.
A thing that Linux seems to do a bit differently from BSD world is that the mmap() will apparently start memory area mapping from file-position of: filepos(fd) + offset It has been quite surprising detail of portability issues of one of my major application packages.
The mmap() offset parameter is of course 32-bit signed value on 32-bit systems.
> One thing I want to add to this discussion is that I think it is important > for Linux to support as much 64 bit capability on 64 bit hardware as > possible. Providing 64 bit capability on 32 bit hardware is a more > difficult, and can be expected to take longer. However, it makes > Linux look bad when Linux/Alpha or Linux/Ultrasparc can't deal with > files larger than 2G.
At 64-bit systems the VFS layer is 64-bit clean. Will the user-space API be 64-bit clean is another matter. (Here I mean especially 32-bit user API on UltraSPARC machines.)
At 64-bit architectures EXT2 can now handle up to 4 GB -1 bytes in the file. Extending file-size encoding in the i-nodes is one matter, other things are user controllable, and don't need kernel changes.
Triply indirected block addressing uses N entries per block (N = sizeof(block)/4), can can address 12+N+N^2+N^3 blocks. Major term in N^3, which means that 32-bit unsigned block addresses can be covered with N>=1625, of which next higher multiple of two is 2048 -- or blocksize of 8 kB.
With that, we can address up to 32 TB with one "small" modification of the system. Namely i-node file-size encoding. With 64kB blocksizes the maximum file size could be around 280 TB. (It would need around 14 000 units of 20 GB disk drives in a truly huge RAID array..)
> Just my $0.02, > > Jim > > -- > ---------------------------------------------------------------------------- > Jim Nance Avant! Corporation > (919) 941-6655 Do you have sweet iced tea? jim_nance@avanticorp.com > No, but theres sugar on the table. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |