Re: mmaping on plan9? (was Re: [9fans] venti /plan9port mmapped

[hiro <23hiro@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3614 bytes --]

Alyssa, Thanks for restoring some order after everybody got so confused.
Like ron i suggest setting the scope more clearly: what are the hardware
layers and driver interface abstractions involved, is this below your
kernel, part of the kernel, or part of the abi?

Remember we also do userlevel filesystems on plan9. And our kernel fs arent
so insanely different from such.

On Tuesday, February 17, 2026, ron minnich <rminnich@gmail.com> wrote:

> I suggest we start over, and, as Dan says, let's stop using the word mmap.
>
> Can we look at this from the point of view of a problem you are trying to
> solve? What is it you want to do?
>
> On Tue, Feb 17, 2026 at 5:36 AM Dan Cross <crossd@gmail.com> wrote:
>
>> On Tue, Feb 17, 2026 at 3:54 AM Alyssa M via 9fans <9fans@9fans.net>
>> wrote:
>> > Guys, I'm really sorry for the confusion.
>> > A week ago I posted this, as a loose analogy, trying to relate what Ron
>> said to my earlier idea:
>> > [snip]
>> > > It would be convenient for this if servers for disk file systems had
>> the ability to create a snapshot of a range of bytes from a file. But they
>> generally don't. So I'm building a file system wrapper layer (a file server
>> that talks to another file server) that provides snapshot files to the
>> kernel via an extension of the file server protocol, in addition to what
>> the underlying file system already provides. My current implementation does
>> this with temporary files. When a file is written, the temporary file gets
>> any original data that's about to be overwritten. The snapshot provided to
>> the kernel is a synthetic blend of the original file and any bytes that
>> were rescued and put in the temporary file. In most uses the original file
>> will never be touched by another process and the temporary file won't even
>> be created.
>> > >
>> > > The wrapper requires exclusive access to the file server underneath,
>> and also requires the contents to be stable. It is the wrapper that is
>> mounted in the namespace. So the wrapper sees all attempts to alter any
>> file, and can ensure that that any snapshot maintains the illusion of being
>> a full prior copy when writes later happen to the file it came from.
>>
>> This doesn't seem workable.
>>
>> Consider a network with three machines: one serves a filesystem, two
>> mount it as clients. If I understand your description above, there is
>> one of these "wrappers" on each client. How, then, do they arrange for
>> exclusive access to the filesystem, which is on a completely separate
>> machine?
>>
>> > [snip]
>> > I'm dismayed by the responses so far, because I think this is
>> potentially a lot better than mmap.
>> 
>> No, this is nothing like mmap.  mmap is an operation initiated by a
>> programmer; this is some totally separate thing.
>> 
>> My humble suggestion is that if you don't want people to conflate this
>> with the `mmap` call, you should stop referring to it as `mmap`.
>> 
>> - Dan C.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-Med980740c04af0912ebaf0f0>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-Mafe57a1fd798d48194107130
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5624 bytes --]