lkml.org 
[lkml]   [1998]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: VFS 64-bit clean
Date
From
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

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