4 ms·

> What does it mean to mmap a file on an NFS server? It means you have issues around synchronization and performance, if you use it as anything other than a pr

by ori_b 7y ago

> What does it mean to mmap a file on an NFS server? It means you have issues around synchronization and performance, if you use it as anything other than a private read only mapping. And some things are just impossible, like a shared memory ringbuffer. Which is exactly what you do with the memory you mmap from a video card: submit commands to the command ringbuffer. > So it's a better idea to not implement many of these things and instead simply return an error. And now you need to start writing multiple code paths in user code, testing which calls work and which don't, one of which will be broken due to lack of testing. And when you guess wrong at the needed operations, software often goes off the rails instead of failing gracefully. Failure modes like blindly retrying forever, or assuming the wrong state of the system and destroying data. Too many complicated abstractions break the ability to do interesting things with a system. It's death by a thousand edge cases. On plan 9, you have 9p. https://9p.io/magic/man2html/5/0intro https://9p.io/magic/man2html/5/0intro That, and process creation/control/namespace management, are the only ways to do anything with the system. There are few edge cases. Implementing a complete, correct server is a matter of hours, not weeks.

jstimpfle 7y ago
> like a [remote] shared memory ringbuffer. Technically just as possible, only very slow... Performance is abstracted out by the VFS. You need to stay sane through other measures, like having your software configured right, etc. > And now you need to start writing multiple code paths in user code I don't think the number of paths is increased. Any software should handle calls that fail - if only by bailing out. That's acceptable for any operation that just can't complete due to failed assumptions - whether it's about file permissions or that the resource must be "performant" / not on an NFS share, etc. > 9p. Now what is the point? How's that different or better? They actually are much more into sharing resources over the network... which means less possible assumptions about availability/reliability/performance. I doubt they can make the shared ringbuffer work better.
- ori_b 7y ago
  > Technically just as possible, only very slow... Performance is abstracted out by the VFS. How would you go about implementing the CPU cache coherency that allows you to do the cross machine compare and swap? > I don't think the number of paths is increased. Any software should handle calls that fail - if only by bailing out. If the software works fine without making a call, then you can just skip the extra work in the first place. Delete the call, and the checks around if the call fails. And if the call is important somehow, you need to find some workaround, or some alternative implementation, which is by definition never going to be very well tested. > Now what is the point? How's that different or better? They actually are much more into sharing resources over the network... which means less possible assumptions about availability/reliability/performance. I doubt they can make the shared ringbuffer work better. The tools to make a shared ringbuffer that depends on cache coherent operations simply aren't there -- it's not something you can write with those tools. And that's the point: The tools needed simply don't work across the network. Instead of trying to patch broken abstractions, adding millions of lines of complexity to support things that aren't going to work anyways (and if they do work, they'd work poorly) pick a set of abstractions that work well everywhere, and skip the feature tests and guesswork. Primitives that work everywhere, implement them uniformly, and stop special casing broken or inappropriate tools. And then, it's a day of work to implement a 9p server, and everything works with it. So I can serve git as a file based API, DNS as a file API, fonts as a file based API, doom resources as a file API, or even json hierarchies as a file API, and not worry about whether my tools will run into an edge case. I can export any resource this way, and not need special handling anywhere. Plan 9 doesn't have VNC; it has 'mount' and 'bind', which shuffles around which `/dev/draw` your programs write to, and which `/dev/mouse` and `/dev/kbd` your programs write to. Plan 9 doesn't have NAT; it has 'mount' and 'bind', which shuffles around which machine's network stack your programs write to. Plan 9 doesn't have SSH proxying that applications need to know about: It has sshnet, which is a file server that provides a network stack that looks just like any other network stack. From parsimony comes flexibility. You're not dragging around a manacle of complexity.
  - deleted 7y ago
    [deleted]
  - jstimpfle 7y ago
- deleted 7y ago
  [deleted]

by ori_b 7y ago

jstimpfle 7y ago

> like a [remote] shared memory ringbuffer. Technically just as possible, only very slow... Performance is abstracted out by the VFS. You need to stay sane through other measures, like having your software configured right, etc. > And now you need to start writing multiple code paths in user code I don't think the number of paths is increased. Any software should handle calls that fail - if only by bailing out. That's acceptable for any operation that just can't complete due to failed assumptions - whether it's about file permissions or that the resource must be "performant" / not on an NFS share, etc. > 9p. Now what is the point? How's that different or better? They actually are much more into sharing resources over the network... which means less possible assumptions about availability/reliability/performance. I doubt they can make the shared ringbuffer work better.

ori_b 7y ago
> Technically just as possible, only very slow... Performance is abstracted out by the VFS. How would you go about implementing the CPU cache coherency that allows you to do the cross machine compare and swap? > I don't think the number of paths is increased. Any software should handle calls that fail - if only by bailing out. If the software works fine without making a call, then you can just skip the extra work in the first place. Delete the call, and the checks around if the call fails. And if the call is important somehow, you need to find some workaround, or some alternative implementation, which is by definition never going to be very well tested. > Now what is the point? How's that different or better? They actually are much more into sharing resources over the network... which means less possible assumptions about availability/reliability/performance. I doubt they can make the shared ringbuffer work better. The tools to make a shared ringbuffer that depends on cache coherent operations simply aren't there -- it's not something you can write with those tools. And that's the point: The tools needed simply don't work across the network. Instead of trying to patch broken abstractions, adding millions of lines of complexity to support things that aren't going to work anyways (and if they do work, they'd work poorly) pick a set of abstractions that work well everywhere, and skip the feature tests and guesswork. Primitives that work everywhere, implement them uniformly, and stop special casing broken or inappropriate tools. And then, it's a day of work to implement a 9p server, and everything works with it. So I can serve git as a file based API, DNS as a file API, fonts as a file based API, doom resources as a file API, or even json hierarchies as a file API, and not worry about whether my tools will run into an edge case. I can export any resource this way, and not need special handling anywhere. Plan 9 doesn't have VNC; it has 'mount' and 'bind', which shuffles around which `/dev/draw` your programs write to, and which `/dev/mouse` and `/dev/kbd` your programs write to. Plan 9 doesn't have NAT; it has 'mount' and 'bind', which shuffles around which machine's network stack your programs write to. Plan 9 doesn't have SSH proxying that applications need to know about: It has sshnet, which is a file server that provides a network stack that looks just like any other network stack. From parsimony comes flexibility. You're not dragging around a manacle of complexity.
- deleted 7y ago
  [deleted]
- jstimpfle 7y ago
deleted 7y ago
[deleted]