From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 15 Aug 2012 23:27:34 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20120815212734.GA1190@polynum.com> References: <20120803171847.GA2720@polynum.com> <501D12A1.1060906@yahoo.fr> <20120804152016.GB433@polynum.com> <20120805173639.GA395@polynum.com> <20120815173327.GA424@polynum.com> <20120815200949.4628BB85B@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20120815200949.4628BB85B@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: a9cda382-ead7-11e9-9d60-3106f5b1d025 On Wed, Aug 15, 2012 at 01:09:49PM -0700, Bakul Shah wrote: >=20 > Sounds like you want to represent a node with a directory, > that has a "content" file that stores content associated with > this node and a bunch of links to other nodes. You are most > interested in parent/child relationships so for instance you > can store links to all parents in a "parent" file and links to > all children in "children" file. Not suggesting this is how > you implement it; I am just trying to understand. A concrete > example from you would help. >=20 I will give two (DeLuxe(R) version!) examples. First one, related to what I was wandering about, is mathematical definitions and relationships. Take the picture of the first volume of van der Waerden's Albebra (I have the german edition and will keep the german words). We speak about links between notions presented in a linear order: the order of the chapters: Galois theory chapter is the descendant of concepts from Vektorr=E4ume, Fortsetzung der Gruppentheorie and K=F6rpertheorie chapter= s; Vektorr=E4ume and Gruppentheory being siblings ("children" of Ringe und K=F6rper) while K=F6rpertheorie is a grand-child of Vektorr=E4ume. Example of multiple parents, and not at the same level. Second example: field parcel (surveyor work). One can divide a parcel, leading to several children. But one can also reunite several adjacent parcels leading to one uniq new, all the inner borders being suppressed. This new parcel has several parents. And the "child" is bigger than every "parent" taken alone... > >=20 > > 4) And the problem was also thought through 9P: is there something in= 9P > > that would prevent, at least theoritically, such a view of data to be > > presented? With the convention of ".+" and ".-", my answer is no: 9P = has > > no hardcoded knowledge of ".." if I'm not mistaken. >=20 > Note that in Unix ".." came for free since each dir stored the > inode number (a "link" to an anonymous inode) along with a > name. The scheme could represent any graph but the kernel > restricted it to a tree by disallowing links to directories. > Expanding this back to multiple parents in effect makes a > poset (partially ordered set) but the unix trick or storing > (parent-inode, "..") fails. Treating ".." as an /operator/ > that cancels the previous component in a path also fails. Yes. >=20 > You can perhaps extend a symlink object to store multiple > links as I described above. The other difficulty is that > something like 9p will only yield zero or one object as you > traverse a path. How do you handle multiple parents? >=20 > A more general idea is to consider a path component a "graph > expression" component that is interpreted by the current node > and may yield *any number of* new nodes. >=20 > In other words >=20 > x =3D open("a/b/c", mode) >=20 > can yield a vector of file descriptors! Leaving component > interpretation to the current node makes this a very dynamic > and powerful system (for example, one can think of a node that > maps to a list of network nodes -- so something like >=20 > echo "date" > /net/my-nodes/foo > chmod +x /net/my-nodes/foo > /net/my-nodes/foo >=20 > can run date on all my nodes! This would be a very compact > expression of how to distribute data or work. >=20 > Your original query is vague enough (& confusing, at least to > me) that one can take it in a number of directions :-) I don't claim that my question was "definite" and it was open. So every idea "wandering" around this fuzzy concept is OK :-) But in my idea, there would be several distinct things (and I think plan9 has already split the things making alternative view possible): 1) There is the storage of the "things". This is mostly orthogonal---the trick being, as always, to be able to retrieve efficiently the stuff but really starting from the coordinates (i, j, k, ...). 2) In 9P, the ".." if I'm not mistaken is not here. One can request a file, or go back to the previous one. The ".." including "path removing" is not implemented in 9P if I read correctly the manpage. So a client can speak 9P, but the way the stuff are presented will be mainly in the server, the trick to allow existing clients to browse being this ".+" and ".-": ".+" leads to children; ".-" leads to parents and a DESC file being perhaps a text description, and some fake parenting allowing a request of ".." to trigger a special action from the server---but all=20 these are artefacts of the server. 3) This is the server that offers a "view" of the data. And in this case, indeed, a request for "something" can trigger "bizarre" actions. >>From a very cursory look, it seems to me that it could be simpler to implement this with Plan9, because it is relatively agnostic about what is a filesystem, than with an Unix if I take into account the difficulties Unix kernels have with userland filesystems---probably=20 because a lot of semantics are assumed in the vnode subsystem. By conception, Plan9 makes a distinction between viewing the data (terminal), processing the data (CPU) and serving the data (fileserver). This is the case here, and this is not a surprise since these distinctions are quite natural---the terminal/CPU/fileserver being simply the special case where the three happen to be the very same machine. But this is a coincidence, not an obligation. --=20 Thierry Laronde http://www.kergis.com/ Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C