I still think an external pager interface would be both easier and more useful than the unix mmap api.
On Mon, Feb 9, 2026 at 11:57 AM Bakul Shah via 9fans <[email protected]> wrote: > Exactly. And the same failure modes exist (if your swap device or exec > file access suddenly fails). In general Unix-type OSes only handle the > "happy path" well and do not expend heroic efforts to deal with errors. > > Here by mmap Ron and I mean memory mapping and not linux/BSD specific > mmap *API*. If any mmap API is added to plan9, it need not follow the > example of linux/BSD but it should be well integrated. > > On Feb 9, 2026, at 7:23 AM, ron minnich <[email protected]> wrote: > > as for mmap, there's already a defacto mmap happening for executables. > They are not read into memory. In fact, the first instruction you run in a > binary results in a page fault. > > Consider a binary larger than your physical memory (this can happen). > Without the defacto mmap, you could not run it. > > Similarly, in HPC, there are data sets far larger than physical memory. > mmap makes use of these data sets manageable. Nothing else has been > proposed which comes close. > > ron > > On Sun, Feb 8, 2026 at 5:35 PM ron minnich <[email protected]> wrote: > >> suns would survive server outages. At least in the 90s. Linux NFS had its >> own ideas for failure. >> >> Statelessness, like everything, has its good and bad points. Note that >> NFS was never truly stateless for v2 and later; servers had to have a dup >> cache, for practical reasons. >> >> Stateless is not cheap. NFS does not even have a mount rpc, for example, >> so every packet carries with it authentication information and user >> identity. Every. Single. One. >> >> But you could reboot a server, and you'd see the infamous "nfs server not >> responding still trying" on the client for hard mounts. For soft mounts, >> you'd see data loss. For spongy mounts, well, some combination of the two >> :-) >> >> When all is said and done, like it or not, NFS has had greater success >> than 9p, for all kinds of reasons, some of which make sense, others which >> don't. >> >> >> >> On Sun, Feb 8, 2026 at 1:01 PM Ethan Azariah <[email protected]> wrote: >> >>> On Sun, Feb 8, 2026, at 3:10 PM, Alyssa M wrote: >>> > I seem to recall NFS will even >>> > survive a server reboot by being stateless (not that I've actually >>> > tried that...) >>> >>> I forget exactly which NFS version I was using back in 2004, but >>> programs with open files didn't survive me tripping over an ethernet cable >>> despite the disconnect not lasting 10 seconds. Server & client were Linux. >>> I remember wondering what NFS's statelessness was for, exactly, though I >>> guess the failure to 'come back' might have been an implementation issue. >>> Newer NFS versions aren't stateless. >>> >>> Surviving a server reboot would be nice though. :) > *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-Ma355f77548e1bce9f0f6683d> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-M39dbdc7846dddfc837d17de5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
