* [9fans] 9P vs. FUSE @ 2007-08-10 11:42 Enrico Weigelt 2007-08-10 11:57 ` Skip Tavakkolian ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Enrico Weigelt @ 2007-08-10 11:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi folks, did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? There're a lot of interesting FUSE-based filesystems out there, and programming w/ FUSE seems to be quite easy. Maybe we could try to get things together ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 11:42 [9fans] 9P vs. FUSE Enrico Weigelt @ 2007-08-10 11:57 ` Skip Tavakkolian 2007-08-10 12:19 ` Iruata Souza [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com> 2 siblings, 0 replies; 27+ messages in thread From: Skip Tavakkolian @ 2007-08-10 11:57 UTC (permalink / raw) To: weigelt, 9fans > did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? fuse is a clever hack for doing user space fs in unix. look at russ' 9pfuse in p9p. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 11:42 [9fans] 9P vs. FUSE Enrico Weigelt 2007-08-10 11:57 ` Skip Tavakkolian @ 2007-08-10 12:19 ` Iruata Souza [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com> 2 siblings, 0 replies; 27+ messages in thread From: Iruata Souza @ 2007-08-10 12:19 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs On 8/10/07, Enrico Weigelt <weigelt@metux.de> wrote: > > Hi folks, > > > did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? > > There're a lot of interesting FUSE-based filesystems out there, > and programming w/ FUSE seems to be quite easy. > > Maybe we could try to get things together ? > > > cu > -- 9p is way simpler. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <2d66a95ea087868174cfdc519a48a2d7@9netics.com>]
* Re: [9fans] 9P vs. FUSE [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com> @ 2007-08-10 12:33 ` Enrico Weigelt 2007-08-10 12:36 ` erik quanstrom ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Enrico Weigelt @ 2007-08-10 12:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * Skip Tavakkolian <9nut@9netics.com> wrote: > > did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? > > fuse is a clever hack for doing user space fs in unix. > look at russ' 9pfuse in p9p. Okay, that's an FUSE-based 9p client. What about FUSE-based 9p servers ? BTW: I'm still interested in functional differences between FUSE and 9P. For example, does 9P support all *nix style inode types (ie. symlinks, devices, pipes, etc) ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 12:33 ` Enrico Weigelt @ 2007-08-10 12:36 ` erik quanstrom 2007-08-10 12:42 ` Lucio De Re [not found] ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net> ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: erik quanstrom @ 2007-08-10 12:36 UTC (permalink / raw) To: weigelt, 9fans > BTW: I'm still interested in functional differences between > FUSE and 9P. For example, does 9P support all *nix style > inode types (ie. symlinks, devices, pipes, etc) ? there are no inodes in 9p. so no. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 12:36 ` erik quanstrom @ 2007-08-10 12:42 ` Lucio De Re 0 siblings, 0 replies; 27+ messages in thread From: Lucio De Re @ 2007-08-10 12:42 UTC (permalink / raw) To: 9fans > there are no inodes in 9p. so no. I'll have private namespaces in preference over inodes any day. ++L ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net>]
* Re: [9fans] 9P vs. FUSE [not found] ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net> @ 2007-08-10 12:48 ` Enrico Weigelt 2007-08-10 13:18 ` erik quanstrom [not found] ` <f17c25af999bb93211e069e6109bb154@quanstro.net> 0 siblings, 2 replies; 27+ messages in thread From: Enrico Weigelt @ 2007-08-10 12:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * erik quanstrom <quanstro@quanstro.net> wrote: > > BTW: I'm still interested in functional differences between > > FUSE and 9P. For example, does 9P support all *nix style > > inode types (ie. symlinks, devices, pipes, etc) ? > > there are no inodes in 9p. so no. Some file attributes, which can tell an special file type ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 12:48 ` Enrico Weigelt @ 2007-08-10 13:18 ` erik quanstrom [not found] ` <f17c25af999bb93211e069e6109bb154@quanstro.net> 1 sibling, 0 replies; 27+ messages in thread From: erik quanstrom @ 2007-08-10 13:18 UTC (permalink / raw) To: weigelt, 9fans i think that you want to read http://www.cs.bell-labs.com/magic/man2html/5/stat also look at the /sys/include/libc.h for the following comments /* bits in Qid.type */ /* bits in Dir.mode */ - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <f17c25af999bb93211e069e6109bb154@quanstro.net>]
* Re: [9fans] 9P vs. FUSE [not found] ` <f17c25af999bb93211e069e6109bb154@quanstro.net> @ 2007-08-10 13:36 ` Enrico Weigelt 2007-08-10 13:42 ` andrey mirtchovski 2007-08-10 13:44 ` erik quanstrom 0 siblings, 2 replies; 27+ messages in thread From: Enrico Weigelt @ 2007-08-10 13:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs * erik quanstrom <quanstro@quanstro.net> wrote: > i think that you want to read > > http://www.cs.bell-labs.com/magic/man2html/5/stat Thx. But I don't see any not whether things like symlinks are represented by file modes. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 13:36 ` Enrico Weigelt @ 2007-08-10 13:42 ` andrey mirtchovski 2007-08-10 13:44 ` erik quanstrom 1 sibling, 0 replies; 27+ messages in thread From: andrey mirtchovski @ 2007-08-10 13:42 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs > Thx. > But I don't see any not whether things like symlinks are > represented by file modes. when you figure that bit out, you'll be enlightened :) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 13:36 ` Enrico Weigelt 2007-08-10 13:42 ` andrey mirtchovski @ 2007-08-10 13:44 ` erik quanstrom 1 sibling, 0 replies; 27+ messages in thread From: erik quanstrom @ 2007-08-10 13:44 UTC (permalink / raw) To: weigelt, 9fans you might check out 9p2000.u. plan 9 doesn't do symlinks. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 12:33 ` Enrico Weigelt 2007-08-10 12:36 ` erik quanstrom [not found] ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net> @ 2007-08-10 13:45 ` Eric Van Hensbergen 2007-08-10 15:51 ` ron minnich 2007-08-10 19:16 ` Uriel 2007-08-10 19:02 ` Uriel 3 siblings, 2 replies; 27+ messages in thread From: Eric Van Hensbergen @ 2007-08-10 13:45 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs On 8/10/07, Enrico Weigelt <weigelt@metux.de> wrote: > * Skip Tavakkolian <9nut@9netics.com> wrote: > > > did anyone do any comparisons on 9P vs. FUSE for (mostly-)local uses ? > > > > fuse is a clever hack for doing user space fs in unix. > > look at russ' 9pfuse in p9p. > > Okay, that's an FUSE-based 9p client. > What about FUSE-based 9p servers ? > I don't think FUSE-based 9p servers makes any sense. Over simplifying, FUSE provides a user space API into the UNIX VFS layer -- 9p provides an API and Protocol into Plan 9's file server interface (which may be local kernel, local user, or across the network). Plan 9's file server interface is an elegant (and small) approach, UNIX VFS is a much larger, more complicated (and many would argue more complicated and larger than necessary) interface. Plan 9's interface is well suited to Plan 9. UNIX's interface is well suited to UNIX. Now, that being said, we have 9p under UNIX (both in p9p and v9fs, and many other incantations), and it seems to work just fine for many things. We took a stab at extending 9p to match some of the UNIX semantics (links, special files, etc.) and it was called 9p2000.u and is implemented in the v9fs client and the spfs server code (there is an RFC if you google for it). However, it was decided at the last IWP9 that we had probably taken the wrong approach with 9p2000.u and it would probably have been better to extend 9p with new operations that had different syntax/semantics from standard 9p as these would be easier to filter out. I'm currently playing with a new design in my copious spare time. It was further suggested by some that a better approach on Linux/UNIX would have been to take what we know from 9p and design a protocol specific to the VFS (similar to FUSE but capable of transparent network, etc.) Some of the recent v9fs effort has been looking at 9p for paravirtualized file system access between hosts using shared memory transports. Much initial work has been done using 9p and 9p2000.u, but requests for more comprehensive solutions have been requested by customers/interested-parties with full support for Linux capabilities. As such, there may be a foray into providing something along the lines of a new set of extensions supporting all Linux VFS operations (perhaps I'll call it 9p2000.l) However, such support is mainly necessary for folks looking to remote access feature rich on-disk file-systems. I believe straight 9p is more than adequate for 99% of synthetic file systems with something as simple as 9p2000.u giving you extra bits necessary for basic UNIX compatibility. -eric ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 13:45 ` Eric Van Hensbergen @ 2007-08-10 15:51 ` ron minnich 2007-08-10 16:32 ` Latchesar Ionkov 2007-08-10 19:16 ` Uriel 1 sibling, 1 reply; 27+ messages in thread From: ron minnich @ 2007-08-10 15:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > However, it was decided at the last IWP9 that we had probably taken > the wrong approach with 9p2000.u and it would probably have been > better to extend 9p with new operations that had different > syntax/semantics from standard 9p as these would be easier to filter > out. And, before anyone jumps on this idea too hard, this approach works; it's how I solved this messy problem in 1998. It was well worth trying the .u variant, however, as you can't know some things until you try them :-) > It was further suggested by some that a better approach on Linux/UNIX > would have been to take what we know from 9p and design a protocol > specific to the VFS (similar to FUSE but capable of transparent > network, etc.) That's probably true. What's weird is the first one I did (for 2.0.3x) fit into Linux VFS layer just fine. That's because the Linux VFS was not as "mature" as it is now, and it was actually far easier in 1998 than it is now to fit a "non-standard" VFS into Linux. Back in 1998 I had - plan 9 style union mounts - private name spaces that worked for all programs - 9p mounts and it was all pretty easy. The newer VFS layer has frozen more design assumptions into practice, with the result that it is harder, not easier, to put interesting file systems into Linux. It was a bit harder for 2.2, even harder for 2.4 and, as you know, a pain in the neck in 2.6. It's easier, I suppose, to put boring file systems in, that act like all the other ones. There's a paper in that reality somewhere ... > However, such support is mainly necessary for folks looking to remote > access feature rich on-disk file-systems. I believe straight 9p is > more than adequate for 99% of synthetic file systems with something as > simple as 9p2000.u giving you extra bits necessary for basic UNIX > compatibility. I think that you are absolutely right. My experience certainly supports this statement ... It's an interesting idea to rethink v9fs with the current Linux VFS in mind. I had not heard that one. It makes a lot of sense, however. At the Google meeting, one discussion about putting private name spaces in-kernel (as opposed to the current 9p-fuse which several at Google are using) was to just have a per-user name space, mounted at some well known place, and work with that. This was also very similar to what I did on the original: codify the mount point to be at /private: all users had to do a private mount (which was not a privileged operation, hence easy) at /private; no user could see anothers private mount; and I never had to deal with the issue of multi-user access to single file, which has caused some work (see the code). On the old stuff, for each private namespace file, there was only one user, and you figured out who it was by looking in the "inode". Going to one user per mount might also make life simpler. That would, however, go against another idea, which was to use 9p to serve root partitions. I'm not a big believer in network-mounted root file systems, so am less concerned with this :-) ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 15:51 ` ron minnich @ 2007-08-10 16:32 ` Latchesar Ionkov 2007-08-10 16:39 ` Eric Van Hensbergen 2007-08-10 18:16 ` ron minnich 0 siblings, 2 replies; 27+ messages in thread From: Latchesar Ionkov @ 2007-08-10 16:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It is not that hard to create few setuid helper programs that make Linux support Plan9-like private namespaces. The union mount would be tricky, is unionfs accepted in the standard kernel yet? Thanks, Lucho On 8/10/07, ron minnich <rminnich@gmail.com> wrote: > On 8/10/07, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > > > > However, it was decided at the last IWP9 that we had probably taken > > the wrong approach with 9p2000.u and it would probably have been > > better to extend 9p with new operations that had different > > syntax/semantics from standard 9p as these would be easier to filter > > out. > > And, before anyone jumps on this idea too hard, this approach works; > it's how I solved this messy problem in 1998. It was well worth trying > the .u variant, however, as you can't know some things until you try > them :-) > > > It was further suggested by some that a better approach on Linux/UNIX > > would have been to take what we know from 9p and design a protocol > > specific to the VFS (similar to FUSE but capable of transparent > > network, etc.) > > That's probably true. What's weird is the first one I did (for 2.0.3x) > fit into Linux VFS layer just fine. That's because the Linux VFS was > not as "mature" as it is now, and it was actually far easier in 1998 > than it is now to fit a "non-standard" VFS into Linux. Back in 1998 I > had > - plan 9 style union mounts > - private name spaces that worked for all programs > - 9p mounts > > and it was all pretty easy. The newer VFS layer has frozen more design > assumptions into practice, with the result that it is harder, not > easier, to put interesting file systems into Linux. It was a bit > harder for 2.2, even harder for 2.4 and, as you know, a pain in the > neck in 2.6. It's easier, I suppose, to put boring file systems in, > that act like all the other ones. There's a paper in that reality > somewhere ... > > > However, such support is mainly necessary for folks looking to remote > > access feature rich on-disk file-systems. I believe straight 9p is > > more than adequate for 99% of synthetic file systems with something as > > simple as 9p2000.u giving you extra bits necessary for basic UNIX > > compatibility. > > I think that you are absolutely right. My experience certainly > supports this statement ... > > It's an interesting idea to rethink v9fs with the current Linux VFS in > mind. I had not heard that one. It makes a lot of sense, however. > > At the Google meeting, one discussion about putting private name > spaces in-kernel (as opposed to the current 9p-fuse which several at > Google are using) was to just have a per-user name space, mounted at > some well known place, and work with that. This was also very similar > to what I did on the original: codify the mount point to be at > /private: all users had to do a private mount (which was not a > privileged operation, hence easy) at /private; no user could see > anothers private mount; and I never had to deal with the issue of > multi-user access to single file, which has caused some work (see the > code). On the old stuff, for each private namespace file, there was > only one user, and you figured out who it was by looking in the > "inode". Going to one user per mount might also make life simpler. > That would, however, go against another idea, which was to use 9p to > serve root partitions. I'm not a big believer in network-mounted root > file systems, so am less concerned with this :-) > > ron > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 16:32 ` Latchesar Ionkov @ 2007-08-10 16:39 ` Eric Van Hensbergen 2007-08-10 18:16 ` ron minnich 1 sibling, 0 replies; 27+ messages in thread From: Eric Van Hensbergen @ 2007-08-10 16:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Latchesar Ionkov <lucho@gmx.net> wrote: > It is not that hard to create few setuid helper programs that make > Linux support Plan9-like private namespaces. The union mount would be > tricky, is unionfs accepted in the standard kernel yet? > Its in -mm, and now there is the secondary union directory (more like Plan 9 mounts) that is going in as well. -eric ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 16:32 ` Latchesar Ionkov 2007-08-10 16:39 ` Eric Van Hensbergen @ 2007-08-10 18:16 ` ron minnich 2007-08-10 18:25 ` Latchesar Ionkov 1 sibling, 1 reply; 27+ messages in thread From: ron minnich @ 2007-08-10 18:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Latchesar Ionkov <lucho@gmx.net> wrote: > It is not that hard to create few setuid helper programs that make > Linux support Plan9-like private namespaces. The union mount would be > tricky, is unionfs accepted in the standard kernel yet? > IIRC the unionfs that is out there is nothing like plan 9 union mounts. Mine did the simpler Plan 9 thing. I wonder if we could just get that in. I would have to forward-port 9 year old code. Hmm. Deep unions with whiteouts give me the creeps. ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 18:16 ` ron minnich @ 2007-08-10 18:25 ` Latchesar Ionkov 2007-08-10 18:35 ` Eric Van Hensbergen 0 siblings, 1 reply; 27+ messages in thread From: Latchesar Ionkov @ 2007-08-10 18:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It is not only matter to forward-port it, but also get it accepted into the kernel. I have to check what is the other union mount that Eric mentioned. Deep unions are not that bad as long as you don't have to write and maintain the code :) On 8/10/07, ron minnich <rminnich@gmail.com> wrote: > On 8/10/07, Latchesar Ionkov <lucho@gmx.net> wrote: > > It is not that hard to create few setuid helper programs that make > > Linux support Plan9-like private namespaces. The union mount would be > > tricky, is unionfs accepted in the standard kernel yet? > > > > IIRC the unionfs that is out there is nothing like plan 9 union > mounts. Mine did the simpler Plan 9 thing. I wonder if we could just > get that in. I would have to forward-port 9 year old code. Hmm. > > Deep unions with whiteouts give me the creeps. > > ron > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 18:25 ` Latchesar Ionkov @ 2007-08-10 18:35 ` Eric Van Hensbergen 0 siblings, 0 replies; 27+ messages in thread From: Eric Van Hensbergen @ 2007-08-10 18:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: V9FS Developers On 8/10/07, Latchesar Ionkov <lucho@gmx.net> wrote: > It is not only matter to forward-port it, but also get it accepted > into the kernel. I have to check what is the other union mount that > Eric mentioned. http://lkml.org/lkml/2007/7/30/193 On a somewhat related topic, we'll probably want to enable some sort of simple copy-on-write mode for paravirtualized file-system 9p servers -- it strikes me that it might be better done in a single server (cow semantics+whiteout along with UNIX file gateway service). -eric ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 13:45 ` Eric Van Hensbergen 2007-08-10 15:51 ` ron minnich @ 2007-08-10 19:16 ` Uriel 2007-08-10 19:21 ` ron minnich ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Uriel @ 2007-08-10 19:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > However, it was decided at the last IWP9 that we had probably taken > the wrong approach with 9p2000.u and it would probably have been > better to extend 9p with new operations that had different > syntax/semantics from standard 9p as these would be easier to filter > out. I'm currently playing with a new design in my copious spare > time. > > It was further suggested by some that a better approach on Linux/UNIX > would have been to take what we know from 9p and design a protocol > specific to the VFS (similar to FUSE but capable of transparent > network, etc.) > > Some of the recent v9fs effort has been looking at 9p for > paravirtualized file system access between hosts using shared memory > transports. Much initial work has been done using 9p and 9p2000.u, > but requests for more comprehensive solutions have been requested by > customers/interested-parties with full support for Linux capabilities. > As such, there may be a foray into providing something along the > lines of a new set of extensions supporting all Linux VFS operations > (perhaps I'll call it 9p2000.l) Strange, this is not what I remember from IWP9 at all. What I remember is that pretty much all requirements people had could be accommodated *without* changing the existing 9p2000 protocol by using conventions on special attach names to provide access to extra required functionality or other such tricks (the exception was the idea of how to group messages, which unfortunately nemo seems to have discarded but I still think is so far the only real improvement 9p might need, and it could be largely backwards compatible) Of course, my memory could be wrong, but it would be really sad to see yet another 9p variant pop up after the .u debacle when I think the consensus was clear that 9p could handle just fine pretty much everything everyone wanted (again with the exception of the message grouping for high latency links). In any case, it would be nice if people considering changes to the protocol could be a bit more open about it so we could have some discussion about how much sense it makes, and we could avoid a repeat of the waste of time and effort with .u. Best wishes uriel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:16 ` Uriel @ 2007-08-10 19:21 ` ron minnich 2007-08-10 19:29 ` Charles Forsyth 2007-08-10 19:29 ` Eric Van Hensbergen 2007-08-10 19:32 ` Latchesar Ionkov 2 siblings, 1 reply; 27+ messages in thread From: ron minnich @ 2007-08-10 19:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Uriel <uriel99@gmail.com> wrote: > In any case, it would be nice if people considering changes to the > protocol could be a bit more open about it so we could have some > discussion about how much sense it makes, and we could avoid a repeat > of the waste of time and effort with .u. A negative result is still useful. It makes no sense to characterize .u this way (and I'm one of the guys who never liked it). We learned something of value. We have the code base and experience. That's what research is. Openness? We were very open to people who actually contributed code. ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:21 ` ron minnich @ 2007-08-10 19:29 ` Charles Forsyth 2007-08-10 21:57 ` ron minnich 0 siblings, 1 reply; 27+ messages in thread From: Charles Forsyth @ 2007-08-10 19:29 UTC (permalink / raw) To: 9fans >> In any case, it would be nice if people considering changes to the >> protocol could be a bit more open about it so we could have some >> discussion about how much sense it makes, and we could avoid a repeat >> of the waste of time and effort with .u. actually, i'm fairly sure i saw discussions go past on some (relevant) list ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:29 ` Charles Forsyth @ 2007-08-10 21:57 ` ron minnich 0 siblings, 0 replies; 27+ messages in thread From: ron minnich @ 2007-08-10 21:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Charles Forsyth <forsyth@terzarima.net> wrote: > actually, i'm fairly sure i saw discussions go past on some (relevant) list > > yep, it was very active discussion, actually, on the v9fs list. ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:16 ` Uriel 2007-08-10 19:21 ` ron minnich @ 2007-08-10 19:29 ` Eric Van Hensbergen 2007-08-10 19:32 ` Latchesar Ionkov 2 siblings, 0 replies; 27+ messages in thread From: Eric Van Hensbergen @ 2007-08-10 19:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Uriel <uriel99@gmail.com> wrote: > > Strange, this is not what I remember from IWP9 at all. What I remember > is that pretty much all requirements people had could be accommodated > *without* changing the existing 9p2000 protocol by using conventions > on special attach names to provide access to extra required > functionality or other such tricks (the exception was the idea of how > to group messages, which unfortunately nemo seems to have discarded > but I still think is so far the only real improvement 9p might need, > and it could be largely backwards compatible) > (Sigh) IIRC there were several proposed extensions such as caching, security, (and perhaps extended attributes) that could be done under alternate aname semantics. However, for more complicated experiments (such as the message groupings) would use new operations which could be easily filtered out by servers which didn't support them instead of the mess we have with .u and different operands for existing operations. > > Of course, my memory could be wrong, but it would be really sad to see > yet another 9p variant pop up after the .u debacle when I think the > consensus was clear that 9p could handle just fine pretty much > everything everyone wanted (again with the exception of the message > grouping for high latency links). > > In any case, it would be nice if people considering changes to the > protocol could be a bit more open about it so we could have some > discussion about how much sense it makes, and we could avoid a repeat > of the waste of time and effort with .u. > Yes - you are right, its much better to work things out in committee versus actually write some code to figure out how things work out in practice. That's just the way its always been done in Plan 9. And so many people had so much time wasted in the .u effort -- all those hundreds of programmers working thousands of hours on adding .u support, all for nothing. Oh, wait -- there was only one other programmer working on this stuff besides me, sorry lucho. Vote with your code, otherwise please keep to your elite "development" lists. -eric ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:16 ` Uriel 2007-08-10 19:21 ` ron minnich 2007-08-10 19:29 ` Eric Van Hensbergen @ 2007-08-10 19:32 ` Latchesar Ionkov 2 siblings, 0 replies; 27+ messages in thread From: Latchesar Ionkov @ 2007-08-10 19:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 8/10/07, Uriel <uriel99@gmail.com> wrote: > after the .u debacle when I think the May be the .u debacle happened only in your head? > In any case, it would be nice if people considering changes to the > protocol could be a bit more open about it so we could have some > discussion about how much sense it makes, and we could avoid a repeat > of the waste of time and effort with .u. I don't recall you wasting any time or effort on it. Thanks, Lucho Why? So you can hear your opin > > Best wishes > > uriel > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 12:33 ` Enrico Weigelt ` (2 preceding siblings ...) 2007-08-10 13:45 ` Eric Van Hensbergen @ 2007-08-10 19:02 ` Uriel 2007-08-10 19:21 ` Charles Forsyth 3 siblings, 1 reply; 27+ messages in thread From: Uriel @ 2007-08-10 19:02 UTC (permalink / raw) To: weigelt, Fans of the OS Plan 9 from Bell Labs > BTW: I'm still interested in functional differences between > FUSE and 9P. For example, does 9P support all *nix style > inode types (ie. symlinks, devices, pipes, etc) ? As others have noted, no. And that is a feature, the whole point of 9P is that all files are equal, and doing away with abominations like symlinks, device nodes and ioctls. The only good thing about FUSE is that it confirms that the lunix people have not learned anything in the last thirty years. uriel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:02 ` Uriel @ 2007-08-10 19:21 ` Charles Forsyth 2007-08-10 19:26 ` erik quanstrom 0 siblings, 1 reply; 27+ messages in thread From: Charles Forsyth @ 2007-08-10 19:21 UTC (permalink / raw) To: 9fans > is that all files are equal, and doing away with abominations like > symlinks, device nodes and ioctls. the 9P semantics for those things would be `wrong' (for the suggested use) anyway. a remote 9P's device node would access the remote device, not the local one, which is useful, but not for remotely-mounting roots. the basic problem, which i expect will never be addressed by the linux people, is that mknod and major and minor device numbers were of their time and now past their prime. (that's just one of the things that ``smells really bad''.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] 9P vs. FUSE 2007-08-10 19:21 ` Charles Forsyth @ 2007-08-10 19:26 ` erik quanstrom 0 siblings, 0 replies; 27+ messages in thread From: erik quanstrom @ 2007-08-10 19:26 UTC (permalink / raw) To: 9fans > > is that all files are equal, and doing away with abominations like > > symlinks, device nodes and ioctls. > > the 9P semantics for those things would be `wrong' (for the suggested use) anyway. > a remote 9P's device node would access the remote device, not the local one, which > is useful, but not for remotely-mounting roots. ioctl allows one to pass a pointer into the kernel, doesn't it? it's kind of hard to pass a pointer via 9p. ;-) i believe that research unix also suffered from this problem, but hacked around it by including 64 bytes starting with the ptr in question. > the basic problem, which i expect will never be addressed by the linux people, > is that mknod and major and minor device numbers were of their time and now > past their prime. (that's just one of the things that ``smells really bad''.) one of the things about plan 9 that looks better and better as you use it is the fact that devices are fileservers, not special inodes. this allows one device to present many files easily, reducing the need for the things in unix that didn't work so well. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-08-10 21:57 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-08-10 11:42 [9fans] 9P vs. FUSE Enrico Weigelt 2007-08-10 11:57 ` Skip Tavakkolian 2007-08-10 12:19 ` Iruata Souza [not found] ` <2d66a95ea087868174cfdc519a48a2d7@9netics.com> 2007-08-10 12:33 ` Enrico Weigelt 2007-08-10 12:36 ` erik quanstrom 2007-08-10 12:42 ` Lucio De Re [not found] ` <22bce9d3afa44ed70b739ea77d5d8046@quanstro.net> 2007-08-10 12:48 ` Enrico Weigelt 2007-08-10 13:18 ` erik quanstrom [not found] ` <f17c25af999bb93211e069e6109bb154@quanstro.net> 2007-08-10 13:36 ` Enrico Weigelt 2007-08-10 13:42 ` andrey mirtchovski 2007-08-10 13:44 ` erik quanstrom 2007-08-10 13:45 ` Eric Van Hensbergen 2007-08-10 15:51 ` ron minnich 2007-08-10 16:32 ` Latchesar Ionkov 2007-08-10 16:39 ` Eric Van Hensbergen 2007-08-10 18:16 ` ron minnich 2007-08-10 18:25 ` Latchesar Ionkov 2007-08-10 18:35 ` Eric Van Hensbergen 2007-08-10 19:16 ` Uriel 2007-08-10 19:21 ` ron minnich 2007-08-10 19:29 ` Charles Forsyth 2007-08-10 21:57 ` ron minnich 2007-08-10 19:29 ` Eric Van Hensbergen 2007-08-10 19:32 ` Latchesar Ionkov 2007-08-10 19:02 ` Uriel 2007-08-10 19:21 ` Charles Forsyth 2007-08-10 19:26 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).