Re: [OFF-TOPIC] lofs & tfs

Trevor Johnson (
Wed, 18 Feb 1998 13:03:04 -0800 (PST)

> Does anyone know what happened to the lofs support which was mentioned a
> while ago (May 97(ish) I think??).

Here are some messages about it.

Date: Wed, 21 May 1997 15:00:23 +0000 ( )
From: Benjamin C R LaHaise <>
To: Mario Mikocevic <>
Cc: "Andrew E. Mileski" <>,
Subject: loopback filesystem (was Re: dynamic partitions)

> How about mounting subdirs through loop driver ?!
> Like
> /somewhere/in/hd/space on /somewhere/else
> Or am I talking offtopic here !?

Offtopic - no, but you are confusing things a bit - the loopback device
creates a block device from a file. A filesystems is needed to mount a
directory elsewhere on the machine. Luckily, I've written one (get Just remember that
most of the time this is an ugly hack that can be avoided w/symlinks &
such, but it has valid uses (chroot is *very* useful w/lofs). So just do
a 'mount -t lofs -o dir=/somewhere/in/hd/space /somewhere/in/hd/space


Date: Mon, 25 Aug 1997 16:29:01 -0700 (PDT)
From: Linus Torvalds <>
To: Benjamin C R LaHaise <>
Subject: Re: dentry_operations vs inode_operations

On Mon, 25 Aug 1997, Benjamin C R LaHaise wrote:
> I've begun to look at rewriting my loopback filesystem to take advantage
> of dentries, but they haven't help at all yet, and here is my idea/plan
> for making them useful (smbfs, ncpfs and such should benefit too). I'd
> like to move most of the inode operations that operate on directory
> entries into the dentry_operations. This will give lofs the advantage of
> not having to duplicate any inodes of the underlying filesystem, but
> still be able to provide say read only functionality on top of a rw fs.

I already sent email to some other people stating that this is what I want
to do anyway..

> A quick glance suggests that all operations except for
> (read|writ|updatee)page, bmap, truncate, smap and revalidate will have to
> move. If there's no great objection to this, I'll put together a patch
> that does this.

Wait for my pre-patch to show up on I've changed
"lock_parent()" to move us into this direction (ie the "parent" is no
longer the inode, it's really the parent dentry). That should make your
patches smaller too.

> Sorry if it seems an enourmous change, but it's the only way I can see
> for us to get the usefulness of a dentry-centric system that allows us to
> implement filesystems without underlying indoes. Hey, ideally
> directories wouldn't *need* an inode resident in memory for networks
> filesystems.

It's not an enormous change - the naming code conceptually is a "dentry"
issue, not an inode issue.

Obviously for historical reasons all the operations were inode operations
simply because we didn't _have_ any dentries..


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to