Here is finally my summary on the information I
received on the Translucent File Service. For those who
don't know it is a file system which allows to stack
directories on top of each other. Regretfully, Sun forgot
to include the description of TFS in the System Administration
A few people asked me where I got the
paper: "The Translucent File Service" by David Hendricks.
I am pretty sure that I got it through the local Sun office
here in Switzerland and I think the new Software person got
it when he took his formation courses. Regretfully, there
are no references on that paper so I don't know if it was
Greg Earle provided me with the e-mail address of
the author, but I didn't get any answer back.
Things to know:
> From: firstname.lastname@example.org (Dennis Sexton)
> The following is the procedure for setting up TFS:
> 1.) modify the kernal configuration file; the generic kernal
> already has the correct entry:
> cd /usr/kvm/sys/sun4c/conf
> options TFS # translucent filesystem - needed by NSE
> 2.) modify the /etc/inetd.conf
> tfsd/1-2 dgram rpc/udp wait root /usr/etc/tfsd tfsd
> 3.) re-start inetd kill -HUP
> 4.) create mount point and mount the file system
> Many have suggested putting the mount_tfs entry in
> /etc/rc instead of rc.local becuase mount_tfs depends on tfsd, which in
> term depends on on inetd being up and running.
I found out that you have to be root to do those mounts :-(
and that the tree that is created when you mount a new
tfs directory on top of an existing tree is created as root, it looks
like that the permission depends on
the mounter (root) and not on the permissions and ownerships
of the underlying file system. But see below.
> 1- Does TFS only work on leaf nodes? For example if I mount a
> TFS tree above X11, do I have to create "manually" all the
> directories below it or will TFS create them automatically
> when they are needed?
The answer is that the whole tree is recreated at mount time
but with the ownership/permissions of the mounter. On the other
hand, I just added a new "level" to a directory which had already
2 levels of tfs mount and the full directory tree wasn't created
at mount time. In fact, doing a touch toto creates the directory tree
under which I did the toto with the correct ownership this time.
It looks like there are still some inconsistencies.
mount_tfs v1 orig dest
v1: 1st level: the whole directory tree of orig is recreated with the
same permissions (?), but the sgid bit of the directories is
gone and the ownership of v1 is now root through out.
mount_tfs v2 dest
v2: 2nd level: the file .tfs_info is created at the top level of v2
and that's it.
umount_tfs doesn't seem to work for more than one level:
umount_tfs v2 -> (tfs) failed - Invalid argument
umount_tfs dest -> ok (v2 is umounted)
umount_tfs dest -> device busy (I don't think it
is supposed to be)
At this stage, I still have v1 on top of orig on top of dest.
Nothing short of reboot seems to be able to undo this.
> 2- A "backfile" is a "cache" of what files are available on all the
> levels below this one. Are the "backfiles" created at
> mount time? If not then when and how do we deal
> with a "back" file system which
> has been modified?
Here I noticed that the version of tfs that comes with
4.1 is an older version than the one that is described by
the paper I read! In particular, the notion of a cache is missing
(the paper mentionned that this was essential to increase
performance when the number of tfs trees is high (>100)).
In fact if I go under "orig" and create a new file,
it is immediatly visible to a process under "dest" (the
tfs mount point). So we don't have to worry about missing
new files/directories that are created at a lower level than the
From Greg Earle:
> Yes, they are created at mount time. If a new directory gets added to the
> `real' filesystem below the TFS mount tree, the next time the TFS mount is
> done the new directory is noted, created, and a .tfs_info file is created for
Two things, I find that I don't need to remount to make a
new directory visible and the .tfs_info isn't a cache, it
is used to point to the next level below this one and to
hold the name of files which are white-outs: they have been
removed on this level but still exists on lower levels.
> 3- How do we create variants? Can variant be based on something
> other than machine architecture?
> Does "tfs_push" exist? It is supposed to push a file from
> a variant sub-level to the "main" sub-level of that level.
> (Is that clear?)
A variant is a level which depends on something to decide
which directory tree represents the level, for example:
the architecture of the machine. Depending on which type of
machine you are, you see two different things.
> 4- Can a level be a nfs mount from a different machine?
> 5- How can we do a diff between levels? What about other
> "necessary" tools?
There doesn't seem to be any tools available at this time.
> 6- Can we mount a full TFS tree by nfs on another machine?
> (So that we can use it "on" machines which don't know what TFS is).
No! Which seriously impairs my work at this stage :-(
mount: sasun1:/sic/install_X11/X.V11R4-sun4-4.1: Too many levels of remote in path
mount: giving up on:
> 7- Is there a "simple" way to compress/remove one or more intermediate
> I understand the use of chroot and loopback to enable
> a per process view of a TFS tree.
> 8- But how do we "alternate" between views within the
> same account? (eg: the installation
> viewpoint with test levels and the distribution viewpoint which
> stops at a lower level: the "production" level).
Here I seem to be way beyond what anybody else has
ever conceived! (outside of Sun that is). I'll have to
get back to the list when I've tried it.
> 9- How do we create a new view automatically? eg: I'm in /foo/bar/work
> and I decide that it is time to have a /foo/bar.
This is almost impossible to do automatically
since the mount has to be done by root!
> 10- As long as we don't logout, once we have done a chroot I
> figure we don't have to worry about the world changing even if
> we do a few xterms. But how do we make sure that we always
> have the same view between login's (and between accounts)
> and still allow us to easily create new levels and
> give us the possibility to go to the production level?'
Since root has to do the mount this may be an impossibility
anyway, more in a following posting.
> Sorry about the length :-), Alain Brossard
Warning you cannot mount a tfs level on more than one
tfs tree. For example:
mount_tfs v2 v1 orig dest ; mount_tfs v1 orig dest_2
mount_tfs /sic/.tfs_X11/X.V11R4-sun4-4.1-v.01 /sic/users /mnt/toto
mount_tfs: TFS mount of "/mnt/toto" failed - Device busy
Noticed that the error message is wrong, /mnt/toto is in fact
not busy. Rather I assume it is "/sic/.tfs_X11/X.V11R4-sun4-4.1-v.01"
which is busy since it is already mounted elsewhere. Anyway since there
is only one .tfs_info file per directory I assume that it couldn't
point to two different lower levels.
What I haven't tested is what happens when you remount
a level in a different hierarchy than it was mounted previously.
My guess would be that the .tfs_info would be updated at mount time,
but I would worry about whiteouts entries being inconsistent.
From: email@example.com (David Muir Sharnoff)
* 4- Can a level be a nfs mount from a different machine?
NFS mounted directories can be included in the TFS "stack", but you
can't do a "mount_tfs /xxx foo:/bar /x1"
* 5- How can we do a diff between levels? What abouth other
* "necessary" tools?
Have each of the levels mounted separately...
mount_tfs /a /b /c /d /x1
mount_tfs /b /c /d /x2
mount_tfs /c /d x3
======> From what I tried, this would be impossible (device busy)
* 6- Can we mount a full TFS tree by nfs on another machine?
* (So that we can use it "on" machines which don't know what TFS is).
Not with the software distributed by Sun. There is no reason a
tfsd couldn't be written that replaced nfsd...
* 7- Is there a "simple" way to compress/remove one or more intermediate
It would be a pretty easy perl program.
From a previous posting by Greg Earle; in his fstab:
/fjowe/v1 /few/dest tfs rw,bg 0 0
and in his /etc/rc:
mount -vat tfs
And more from Greg Earl (I should convince him to move to Switzerland :-):
From: earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
>5- How can we do a diff between levels? What about other
> "necessary" tools?
To use a simple case, an NFS mount with a local TFS mount over it:
You can prepend `/tmp_mnt/Tfs_native' to get at the lower level. Thus, if I
change, say, `/usr/src/local/X11/contrib/clients/xloadimage/g3.c' and
therefore have the changed version in my TFS tree, I can do a diff of the
`virgin' bottom-level version with the current one via
diff -rc2 /tmp_mnt/Tfs_native/usr/src/local/X11/contrib/clients/xloadimage/g3.c /usr/src/local/X11/contrib/clients/xloadimage/g3.c
and it works.
Indeed typing mount, shows a lot of mounts on /tmp_mnt/Tfs_native, but
I don't think this works in the general case:
1- It doesn't work for more than one level:
/tmp_mnt/Tfs_native/tmp_mnt/Tfs_native is empty
2- You would only pick up the last loop of tfs and if you mounted
more than one tfs files systems, then I would assume
that only the state before the last mount would be visible.
My feeling is that the concept of TFS is very good and
will be very usefull in the future but that this first
release by Sun is very immature and incomplete. As
illustrated by the missing documentation.
So in the absence of more documentation, I hope that
anybody who has made it this far and has some information
to contribute will send it to me so that I can make
another more complete summary.
I would really appreciate some feedback from Sun on
this subject. If I may use this forum for personnal
use (:-), I'll be at the Sun User's Group and latter on
will be taking the course Advanced System Administration in
Milpitas, what are the chance of picking up more information
there? Or at Sun in Mountain View?
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT