Translucent File Service

2007-12-25 7:16:00

        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

manual.

        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

ever published.

        Greg Earle provided me with the e-mail address of

the author, but I didn't get any answer back.

        Things to know:

> From: dws@sun.com (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

dest: empty

orig: full_tree

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

top one.

        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

> it.

   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?

   Yes.

> 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:

   /mnt/sasun1_X11

> 7- Is there a "simple" way to compress/remove one or more intermediate

> levels?

    No!

> 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[3]/work

> and I decide that it is time to have a /foo/bar[4].

   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: cae780!muir@apple.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

* levels?

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

brossard@sasun1.epfl.ch

Comments

Got something to say?

You must be logged in to post a comment.