mobifs eifs fmfs

I wrote to the fuse mailing list, about the eifs/fmfs/mobifs. I am still not sure which name fits better, for simplicity I will refer to it as mobifs. Based on the feedback from the mailing list, it became clear for me, that mobifs can be implemented with help of fuse. However implementing it in kernel will avoid double context switch, copying buffers, etc. One of the powerful features of fuse is that you may develop proof of concepts for any kind of filesystem, and the if performance is an issue, recode a part to fit into the kernel. The user space solution for mobifs will be straightforward to implement, at a later stage a kernel module may come into being.

As summary, the goal of mobifs (everything is filesystem) is to allow transparent (read/write) access to the tree structure of files that have such a tree structure under the form of traditional directory tree structure and to present the leaves in form of text, that can be edited without compromising the format expected by the original tools that handle these files.

The driving motivation behind is also to avoid to learn hundreds of command line parameters of hundreds of tools that access such files and to be able to access the data that hides behind with traditional viewers, editors or other tools.

For example an sqllite database file has such a directory structure. instead of issuing sql statements, one would be able to acces such a file like:

#>vi blogs.sqllite@sqllite/tables/blogs/rows/by/uniqueid/mobifs-eifs-story/content

in this example “blogs” is the table containing the blog entries, “by” means that I want to access data by column name, “mobifs-eifs-story” is the unique id of the blog entry, and “content” is the field containing the content.

if your blog database would be on a mysql database on a remote server, you would do sthg. similar:

#>vi blogs.db.id@mysql/tables/blogs/wors/by/uniqueid/mobifs-eifs-story/content

in this case blogs.db.id would contain necessary info how to access the database (server ip, db name, username, password)

eifs/fmfs (everything is filesystem/file mapping filesystem)

I am doing some proof of concept for a virtual filesystem extension. I wrote the following

email to the linux filesystem mailing list.

Hello mailing list members,

I am not sure about the best name, but I am sure it is sthg. very usefull. So I will call it mobifs, hope you do not mind :) I am also not sure if there is sthg. like that out there, but based on my 15 years of linux experience I never met sthg. like what I would like to talk about.
What I would like to have on my linux boxes is to access data the following way:

#>cat /dev/sda1@/partition1/etc/inittab@/defaultranlevel #usecase 0

#>cat /data/xmlfiles/apsettings.xml@xml/main/entry1/subentry/value #usecase 1

#>cat /data/xmlfiles/apsettings.xml@/main/entry1/subentry/value #note @ instead of @xml #usecase 2
#>cat /data/images/linux.img/@/partition1/etc/dhcpd/dhcpd.conf@group/next-server#note twice the @  #usecase 3

I think you got the point. It is actually not a real filesystem, but an extension to the virtual filesystem.How would it work? If the virtual filesystem subsystem of the kernel finds an @ it would redirect the call to the mobifs main module. The mobifs will check if there is any string after @ till the next /. If yes, it will look if there is any driver installed with that name. In usecase 1, it will look if there is a
driver to read xml files. If yes, it will call the driver and pass the rest of the string to it. The xml driver
will interpret the path request and output the necessary entry. If there is nothing specified like in usecase0 (note annoying tmp. mount not needed!!!)mobifs will try to guess, and if he finds a matching filetype (like the file command or mount does) it would pass the path to the driver if there is any driver registered for that. Drivers can be partition readers (do not know oficial technical name
:)), existing filesystem drivers etc. It should be possible to have kerenel drivers and userspace drivers.
It seems rather logical that for reading filesystems one would use kernelspace drivers, and
for trivial file mapping operations userspace program would fit better.

Usecas0 has twice @. This should mean double “redirection” or piping. Mobifs should help to feed the output of one driver with the input of next one, etc. In case of usecase 0, the one driver would read the filesystem on sda1, and feed the read of the driver that is able to read inittab files.

If sthg. like that would become to being, I would see its evolution as 2 main steps: first create
read only support, and then add write support. The same would happen with the drivers…

I was thinking about this the last few days, started to hack around the kernel, but before going
to the wrong direction, I wanted to ask more experienced people about what and what not to do!

for some more imagined usecases, see the PS.

rgrds,
mobi phil

P.S.

#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/2345/rowname
#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/rowname/1232
#>cat /databases/mysqldatabase/db.sql@mysql/tables/table1/rowname

#>cat /xxx/xx/xx/xx/elfimage@elf/symbols

#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/methodist
#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/includelist
#>cat /sourcecode/cpp/thismodule/thatfile.cpp@cpp/methods/thatmethod

#>cat /sourcecode/cpp/thismodule/thatfile.h@cpp/methodist

#>tail -f /var/log/messages@grep/error #maybe this is less usefull

wikipediafs works for me

However it is stated on the homepage of wikipediafs that the project is not maintained, it works! The only one change one has to make is:

user.py:56:        self.login_page = “%s?title=Special:Userlogin” % self.basename

into

user.py:56:        self.login_page = “%s?title=Special:UserLogin” % self.basename

(note the change from Userlogin to UserLogin)…

and now it is straightforward and easy to edit the wiki with vim… I will write probably a plugin to jump to links automatically. I wish one day there will be fuse fore wince :) and I will be able to edit wikis with vim on mobile :)

Please note that wikipediafs is a userspace filesystem and is mounted with help of http://fuse.sourceforge.net.

versioning filesystem

I was thinking that there should be something that imitates clearcase on linux, some sort of versioning filesystem. It turned out that there are few projects in this direction. I found mainly 2 of them:

The filesystem implementations have similarities and differences. Wayback and copyfs are implemented in userspace and they use the services of any kernelspaced filesystem to implement the versioning. Ext3cow is a kernel space implementation and it relies on ext3.

Whatever the others do, I am thinking maybe to write a very trivial versioning filesystem, that could use the services of any other filesystem (ext3, jfs, xfs etc).  Basic ideas:

  • versions (or diffs) would be stored in the same directory as the normal file, but when mounted as versioned filesystem, the version files would not be visible
  • to be continued
nfs4 is slow, but nfs3 behaves well!

here: http://www.mobiphil.com/?p=33 I was writing about my bad experience with nfs4. Switched back to 3, and things work just NICE…