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

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
depending on the implementation (i.e., age)
This is one of those situations where the physical realm overrules the
virtual realm.