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]#
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 [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
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 [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
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 )