Here are some messages about it.
Date: Wed, 21 May 1997 15:00:23 +0000 ( )
From: Benjamin C R LaHaise <blah@dot.superaje.com>
To: Mario Mikocevic <mozgy@maja.zesoi.fer.hr>
Cc: "Andrew E. Mileski" <aem@netcom.ca>, linux-kernel@vger.rutgers.edu
Subject: loopback filesystem (was Re: dynamic partitions)
Hello,
...
> 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
ftp://dot.superaje.com/pub/linux/lofs-2.0.30.diff). 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
/somewhere/else'
-benjamin
Date: Mon, 25 Aug 1997 16:29:01 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Benjamin C R LaHaise <blah@dot.superaje.com>
Cc: linux-kernel@vger.rutgers.edu
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 ftp.kernel.org. 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..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu