Re: [9fans] Multi-dimensional filesystem
Hello, On Fri, Aug 03, 2012 at 05:08:52PM -0400, Burton Samograd wrote: Has someone ever played with the notion of a multidimensional filesystem David Korn did some research on a 3d file system called 3d: David G. Korn, Eduardo Krell, The 3-D File System, pp147-156, USENIX Conference Proceedings, Summer 1989, Baltimore, MD And also at behind a paywall: http://onlinelibrary.wiley.com/doi/10.1002/spe.4380201304/abstract I seem to remember it being available through ast: http://www2.research.att.com/sw/download/ Thank you for the reference! Best, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Multi-dimensional filesystem
I'm pretty sure there's an isomorphism between your multidimensional filesystem and the set of potential namespaces. A dimension in your multidimensional fileysystem is just an arbitrary set of filesystems bounded in a particular namespace... -- Aram Hăvărneanu
Re: [9fans] Multi-dimensional filesystem
On 03/08/2012 19:18, tlaro...@polynum.com wrote:
Hello,
This is mainly a theoretical question.
While playing with the representation of mathematical definitions as
a file hierarchy (at dot you find a DESC or whatever named file with
the description, and the subdirs are simply more restrictive
instances of the thing; say : collection - magma - monoïde -
group etc.), it is soon obvious that a filesystem is a one dimension
thing: you only follow one string. Multiple parents at the same
level are not there.
One could trick partly using hard or soft links. But with always the
same problem: who is dot-dot, in a case where multiple parents are
here? And multiple parents are not, to my knowledge, supported by
kernel filesystem code. Manipulating the namespace is not the same.
Has someone ever played with the notion of a multidimensional
filesystem, where '/' is the origin, the nodes would be some
representation of (a, b, c,...) (even negatives perhaps), each node
having a name (user defined one by the way), and if a node is, say
(3, 0, 1,...) this means that it is to be found as the third subdir
of the (1, 0, 0,...) path etc., (In this scheme, if there is no link
(no path) from another notion, it is another dimension).
Just for intellectual curiosity.
Best,
Hi,
As far as I understand, it seems you are interested in the idea of views
over your files. Something that has been approached as non-hierarchical
file systems. But the complexity of handling such graphs often seems to
be the reason why these projects failed. Not to mention how the pain to
adapt them to the existing systems that are strictly hierarchical.
In a project we presented in iwp9 6e (2011), we introduced the design of
a filesystem that stores files (stream or hierarchy of files) in
/records/ on a WORM file system (Venti). Records are stored in sequence,
as they arrive (in respect to their recording order). Each record is
identified by your username 'u', the repository name 'h' (for host) and
an index related to time 't' (that is not time, but a self incremented
interger linked to the date in the current calendar). Each triplet
{u,h,t} is uniquely linked to a Venti SHA-1 score. That is the ground level.
On top of that, you are free to point files to build any view on them
and store these views again in new records, using any naming convention
you like at this moment. A non intrusive hypertext language can be
used to write a log book from were you point the files you stored in
records. From this log book, you can do literate programming, run
scripts on files, etc. (For the moment, Emacs org-mode seems to be a
good hyper-text language to start from.)
A third component, a triplet indexer, helps you to find which records
points to other records, an vice versa. A plain text search engine
helps you to retrieve text from the past. All is centered on traceability.
We spent a lot of time studying reference bibliography from the 60s to
today and already have plans for implementation of the ground level
file system on top of Venti.
Hope this will interest you, at least just for intellectual curiosity!
;-)
Nicolas
Re: [9fans] bind /net
Problem was that factotum seemed busy in some auth protocol. (this really sucks. factotum is mounted directly on /mnt instead of /mnt/factotum and is single threaded so when its doing some auth business, noone can walk /mnt... this can even cause deadlock with authsrv which tries to access /mnt/keys on the same machine... but thats a different thing...) the rsc factotum from 9atom is multithreaded. - erik
Re: [9fans] Multi-dimensional filesystem
On Sat, Aug 04, 2012 at 01:56:07PM +0300, Aram H?v?rneanu wrote: I'm pretty sure there's an isomorphism between your multidimensional filesystem and the set of potential namespaces. A dimension in your multidimensional fileysystem is just an arbitrary set of filesystems bounded in a particular namespace... I'm not quite sure about the bijective property but at least, since mathematics has recognized that the linear relationship is fundamental, and since base and dimensions are easily approached by linear Algebra, it seems probable enough that as long as the dot-dot thing is implemented by a fileserver---no semantics enforced at the kernel level---once you have the primitive for an oriented linearity (children/parent), multidimension is achievable. As sketched in a previous mail, a fileserver could present a classical file hierarchy, but with ., .., and, say .+ for the hierarchical children, and .- for the reverse hierarchical parents (these being only a _view_; storage is another story...). So this could be achieved but by not attempting to provide an ubicuitous view, but only a local view from the file considered. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Multi-dimensional filesystem
On Sat, Aug 04, 2012 at 02:16:33PM +0200, Nicolas Bercher wrote:
As far as I understand, it seems you are interested in the idea of views
over your files. Something that has been approached as non-hierarchical
file systems. But the complexity of handling such graphs often seems to
be the reason why these projects failed. Not to mention how the pain to
adapt them to the existing systems that are strictly hierarchical.
It seems clearer (and this is in accordance with notions expressed
further in your message), that the file hierarchy is a view of the data.
The way the data is stored can be totally different from the classical
one dimension tree structure.
The multidimension can (seen from far) be tricked with (as explained in
another message), from the current file, a ., .., .+ for children
and .- for parents; keeping in mind that the paths are only the next
neighbours (so this is a limited local view), as if say in a 2D grid
(discrete coordinates) you will only consider the next objects with
coordinates differing only by +/- 1.
In a project we presented in iwp9 6e (2011), we introduced the design of
a filesystem that stores files (stream or hierarchy of files) in
/records/ on a WORM file system (Venti). Records are stored in sequence,
as they arrive (in respect to their recording order). Each record is
identified by your username 'u', the repository name 'h' (for host) and
an index related to time 't' (that is not time, but a self incremented
interger linked to the date in the current calendar). Each triplet
{u,h,t} is uniquely linked to a Venti SHA-1 score. That is the ground level.
On top of that, you are free to point files to build any view on them
and store these views again in new records, using any naming convention
you like at this moment. A non intrusive hypertext language can be
used to write a log book from were you point the files you stored in
records. From this log book, you can do literate programming, run
scripts on files, etc. (For the moment, Emacs org-mode seems to be a
good hyper-text language to start from.)
A third component, a triplet indexer, helps you to find which records
points to other records, an vice versa. A plain text search engine
helps you to retrieve text from the past. All is centered on traceability.
We spent a lot of time studying reference bibliography from the 60s to
today and already have plans for implementation of the ground level
file system on top of Venti.
My application case was a little different. This was to present a
database of mathematical definitions with a file hierarchy, the
relationship between the notions being represented by the file hierarchy
(but this obviously needs multidimension since not everything is on the
same deducing string of notions).
In this case, there will be some lookup function, taking a name or a
more complex criteria, and returning a file with the definition
represented by a n-uple (a, b, c, ...). The advantage is that the
identifier can be of fixed length or by convention, if one more dimension is
added, it is added last, and shorter uples have all zeroes
coordinates for non expressed dimensions. But this encodes not only the
definition search, but all the relationships since parent notions or
descendant notions are immediately deduced from this.
So there could be a WORM but with a typical copy-on-write block strategy
for backup and history (but this is orthogonal to the multidimension).
The implementation of the multidimension per se (as soon as there is
a matrix representation, there is an obvious way to do). And the
representation (view) of the data as a normal file structure with
the .+ and .-.
(This explanation does not hide the vagueness of the thing---but I'm
just wandering intellectually at the moment).
Hope this will interest you, at least just for intellectual curiosity!
;-)
Yes ;-)
--
Thierry Laronde tlaronde +AT+ polynum +dot+ com
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] bind /net
very good. i'll look into this. thanks :) -- cinap
