Translation Filesystem

Translation Filesystem

[Amit S. Kale]

Hi,

I have started a new virtual filesystem project, Translation Filesystem
at
http://trfs.sourceforge.net/  Description of the project is given below.

It's still at a concept stage. If someone has any ideas about any useful
translators that fit in this framework please write to me.
Any feedback is most welcome.

Regards.
-- 
Amit Kale
Veritas Software ( http://www.veritas.com )

Translation Filesystem 
The translation filesystem provides views for files. A view offered by
the translation filesystem is different from the view offered by a
filesystem which contains a file. For example a filesystem presents a
tar file as a flat
byte stream and the translation filesystem presents it as a directory
containing files contained in the tar file.  The translation filesystem
is based on translators each of which is responsible for creating views
for
filesystem objects of some type. 

Root of a translation filesystem contains translator directories. A
translator creates views in its directory. A view for a file (or a
directory) is generated by creating a symbolic link in a translator
directory. The link points
to the file for which the view is created. A view is destroyed by
removing the symbolic link presenting the view. 

Properties of a view presented by a symbolic link are determined by the
translator which owns the directory in which the link is present. When
the symbolic is accessed using stat or open, it presents properties
determined by the view. When destination of the symbolic link is read
using readlink, it points to the file for which the symbolic link
presents a view. 

The translation filesystem provides views to files contained in a
filesytem without the need for modifying the filesystem itself. It does
not need extensions to existing filesystems. Since it does not use mount
operation for
creating a view, users don't need special permissions to create views. 
It does not use ioctls. So special programs are not needed for
configuring a translation filesystem. The file for which a view has been
created can be
readily identified by reading destination a symbolic link. 

.At present only one translator, raw, is provided. It provides zero copy
read for a block device. 

Example of Usage 
[root@localhost /root]# insmod ./trfs 
[root@localhost /root]# mount none /mnt0 -t trfs 
[root@localhost /root]# ls /mnt0 
[root@localhost /root]# ls /mnt0/raw 
[root@localhost /root]# ls /mnt0 
raw 
[root@localhost /root]# ln -s /dev/hda1 /mnt0/raw/food 
[root@localhost /root]# ls /mnt0/raw/food 
/mnt0/raw/food 
[root@localhost /root]# dd if=mnt0/raw/food bs=1024 count=1 | hexdump -n
128 
0000000 3ceb 4d90 5753 4e49 2e34 0031 1002 0001 
....................... 
[root@localhost /root]# rm /mnt0/raw/food 
rm: remove `/mnt0/raw/food'? y 
[root@localhost /root]# ls /mnt0/raw 
[root@localhost /root]# umount /mnt0 
[root@localhost /root]# rmmod trfs 
[root@localhost /root]#
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Translation Filesystem

[Pavel Machek]

Hi!

> I have started a new virtual filesystem project, Translation Filesystem
> at
> http://trfs.sourceforge.net/  Description of the project is given below.
> 
> It's still at a concept stage. If someone has any ideas about any useful
> translators that fit in this framework please write to me.
> Any feedback is most welcome.

Well, take a look at uservfs.sourceforge.net (used to be called
podfuk) and probably avfs.

We are doing things like tarfs using CODA and userspace servers --
that has big advantages on not crashing machines, plus being portable
(currently Linux and Solaris). [Do not try podfuk on latest kernels:
something went wrong. 2.4.0-test5 should be okay].

Here's example session:

pavel@Elf:/$ cd "/tmp/unarj241a.tar.gz#utar/unarj241a"/
pavel@Elf:/tmp/unarj241a.tar.gz#utar/unarj241a$ ls
Makefile       os2unarj.mak   tccunarj.mak   unarj.doc
Makefile.orig  patch241a      technote.doc   unarj.exe
decode.c       qclunarj.mak   unarj.c        unarj.h
environ.c      readme.doc     unarj.def      unarj.h.orig
pavel@Elf:/tmp/unarj241a.tar.gz#utar/unarj241a$ cd /tmp
pavel@Elf:/tmp$ head mc.diff.gz#ugz
--- /dev/null   Sun Jun  2 15:30:20 1996
+++ mmc/vfs/shared.c    Mon Mar 30 23:41:55 1998
@@ -0,0 +1,267 @@
+/*
...

								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Translation Filesystem

[Pavel Machek]

Hi!

> I have started a new virtual filesystem project, Translation Filesystem
> at
> http://trfs.sourceforge.net/  Description of the project is given below.
> 
> It's still at a concept stage. If someone has any ideas about any useful
> translators that fit in this framework please write to me.
> Any feedback is most welcome.


Well - I can certainly not do zero-copy block device access.

What are expected usages of your translation filesystem?
Hi-performance things like zero-copy block device access, or
low-performance things like transparently ungzipping? If it is the
second case, uservfs.sourceforge.net is perfectly applicable, if not,
you really need to modify kernel..
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Translation Filesystem

[Amit S. Kale]

Pavel Machek wrote:
> 
> Hi!
> 
> > I have started a new virtual filesystem project, Translation Filesystem
> > at
> > http://trfs.sourceforge.net/  Description of the project is given below.
> >
> > It's still at a concept stage. If someone has any ideas about any useful
> > translators that fit in this framework please write to me.
> > Any feedback is most welcome.
> 
> Well - I can certainly not do zero-copy block device access.
> 
> What are expected usages of your translation filesystem?
> Hi-performance things like zero-copy block device access, or
> low-performance things like transparently ungzipping? If it is the
> second case, uservfs.sourceforge.net is perfectly applicable, if not,
> you really need to modify kernel..

Thanks for your comments.

trfs is just a framework for creating views. Translators are independent
entities, so the use of trfs will be more dependent on what translators
are present. Since translators are independent of each other, 
they can be used for hi-performance as well as low-performance things.

Translators need not be inside the trfs module (right now raw translator
is because the interface for translators isn't fixed yet). The raw
translator is dependent on block devices. A translator for some other
thing say a tar-directory translation could be dependent on a userfs.

e.g.
/trfs/tar/foo->/home/username/foo.tar

tar translator uses uservfs to create a view
It will use /uservfs/<something>/foo.tar#<bar>
-- 
Amit Kale
Veritas Software ( http://www.veritas.com )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/