Re: streams and file locks, ancient OS history, ARM is sort of channeling

On Tue, 02 Jul 2024 00:28:45 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

Michael S wrote:
 

On Mon, 1 Jul 2024 02:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:
 

According to MitchAlsup1 <mitchalsup@aol.com>: 

In fact, you can ftruncate arbitrarily large at the start -
backing sectors for the mapped pages will only be allocated
when a page is referenced for the first time. 

>
Can you ftruncate( 0x7FFFFFFFFFFFFFFFF ); ?? ½ of the address
space 

>
Every filesystem has a maximum file size. Exceed that and you'll
get an EFBIG error. 

>
Then it is not capable of ftruncate arbitrarily large in a
hardware's view of arbitrarily large which tends to be 1-bit
smaller than the largest container. 

>
The goal here is to map a file into the address space. What's
your use case for mapping a file-like thing that is bigger than
any real file and can't be written out to the disk?
 

>
Consider that configurations in which maximal file size is bigger
than half of address space are quite common. And not just on
32-bit HW.
>
Of course, what is considered "half of address space" is not a very
simple question by itself. Take x86-64. Is its address space 2**64
or 2*48? Take aarch64. Is its address space 2**64 or 2**49? Or,
may be, 2**56? 

>
To answer this one has to use the proper verbology::
>
Half the virtual address space of x86-64 is 63-bits
Half the physical address space is as low as 38-bits and as high as
47-bits 

 
And generally the address space usable by an application is
limited by the OS/user virtual address boundary (e.g. 2gb
or 3gb on 32-bit x86, and 2^55 for ARM64).

2**49 (IIRC) on ARMv8-A and 2**56 on ARMv9-A is a architectural hardware
limit rather than OS limit.