Jan Kara <jack@xxxxxxx> wrote:
> On Tue 13-12-11 19:30:32, Joerg Schilling wrote:
> > Jan Kara <jack@xxxxxxx> wrote:
> >
> > > > AFAIK, Linux does getcwd() in kernel as Solaris does, so it should be possible
> > > > to get the path for a mount point, in case that path was not kept during the
> > > > mount(2) operation.
> > > Jorg, maybe I'm missing something but look:
> > > quack:/tmp/foo # l
> > > total 700
> > > drwxr-xr-x 2 root root 4096 2011-12-13 16:54 ./
> > > drwxrwxrwt 74 root root 712704 2011-12-13 16:54 ../
> > > quack:/tmp/foo # mkdir -p bar/baz
> > > quack:/tmp/foo # mkdir bar2
> > > quack:/tmp/foo # mount -t ext3 -o loop ~jack/fs-images/ext3-image bar/baz/
> > > quack:/tmp/foo # mkdir bar/baz/dir
> > > quack:/tmp/foo # touch bar/baz/dir/some_file
> > > quack:/tmp/foo # mount --bind bar/baz/dir/ bar2
> >
> > This looks loks a loopback mount.
> The first mount is the loopback one, right. But that's not really
No, the first mount is an fbk mount.
> interesting. What is interesting is the second mount --bind which allows
> you to mount arbitrary *directory* over some other directory in the system.
> So you have two (consistent) copies of one directory and it's subtree in the
> system.
As explained before, the second mount is what looks like a loopback mount....
> > If this is implemented the way it is implemented in Solaris, there is a
> > nearly empty vfs layer, specific to the loopback mount that indirectly
> > calls the vfs functions for the base FS. So on Solaris this is
> > possible and it would work as expected.
> Again, note that loopback mounts are not the hard part here. I could have
> mounted standard block devices and nothing interesting would have changed
> in my example. What is interesting is that I can create a directory tree
> where root of some filesystem is not accessible (there is not a valid path
> that would resolve to it) but it's subdirectory is accessible.
Please reread my previous mail. Your problem is that you use the wrong linux
nomenclature while reading my text.
The pointer to the related "lofs" sourcecode explains how it works and why it
works as expected on Solaris.
Note that a mount point relative absolute path needs to be evaluated against
the real original (first) mount and not against the second loopback mount.
As mentioned in the previous mail, Solaris would work as expected as the
loopback (lofs) VFS layer indirects to the original UDF VFS layer that
will do the real work for the readlink operation.
Jörg
--
EMail:joerg@xxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
