Prev: mount(8) followed by umount(8) fails
Next: how to automatically run a script as long as an input file is available
From: Casper H.S. Dik on 13 Mar 2010 06:18
Seebs <usenet-nospam(a)seebs.net> writes:

>On 2010-03-12, Barry Margolin <barmar(a)alum.mit.edu> wrote:
>> In article
>><930abafa-010e-41cf-8cf5-eb8d0ed0a43d(a)g10g2000yqh.googlegroups.com>,
>> Francis Moreau <francis.moro(a)gmail.com> wrote:
>>> So are there any ways to stats the underlying mount point ?

>> Not that I know of. Once you mount something, the original mount point
>> is totally hidden.

>Almost.

>If you NFS export a filesystem, and that filesystem contains a mount
>point, you can't see the mount point (only the filesystem mounted over
>it) on the server, but a client mounting the filesystem can see the mount
>point, but not the thing mounted on it.

>Er, that's hard to follow.

>/a filesystem
>/a/b another filesystem

>If I export /a to a client machine, it can see the underlying directory
>/a/b which is the mount point, because it can't follow my NFS mount.

In recent versions of Solaris, there's a "nosub" mount for "lofs".


E.g., if you have a directory '/export' and you mount a filesystem,
you can access the mountpoint under the filesystem using:

mount -F lofs -o nosub / /mnt
ls -ld /mnt/export


Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Jon LaBadie on 13 Mar 2010 23:28
Francis Moreau wrote:
> On Mar 12, 3:10 am, Barry Margolin <bar...(a)alum.mit.edu> wrote:
>> In article
>> <74384b7d-fac6-48bf-9da3-86894ecc5...(a)z11g2000yqz.googlegroups.com>,
>> Francis Moreau <francis.m...(a)gmail.com> wrote:
>>
>>> But I'm not trying to access the content of the directory (hence not
>>> trying to access to the remote data), I'm just try to stat the
>>> directory .gvfs on which something is mounted (that's why I pass '-ld'
>>> switches to ls(1))
>> Stat accesses the mounted directory, not the underlying mount point.
>>
>
> So are there any ways to stats the underlying mount point ?

UNIX systems used to have a File System DeBugger, fsdb, that could
be used to examine the underlying mount point. Might be using a
cannon to squash a beetle though. Are programs like fsdb still around?
From: Seebs on 14 Mar 2010 05:07
On 2010-03-14, Jon LaBadie <jlabadie(a)aXcXm.org> wrote:
> UNIX systems used to have a File System DeBugger, fsdb, that could
> be used to examine the underlying mount point. Might be using a
> cannon to squash a beetle though. Are programs like fsdb still around?

I haven't seen much like that in a while -- I think BSD/OS or NetBSD had
a working one a few years back, but I have no idea whether they still do.
(BSD/OS being a sort of hypothetical case anyway, now.)

I have a filesystem layer thing for which I intend to write an fsdb-like
implementation In My Copious Free Time.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Allodoxaphobia on 14 Mar 2010 13:42
On 14 Mar 2010 09:07:40 GMT, Seebs wrote:
> On 2010-03-14, Jon LaBadie <jlabadie(a)aXcXm.org> wrote:
>> UNIX systems used to have a File System DeBugger, fsdb, that could
>> be used to examine the underlying mount point. Might be using a
>> cannon to squash a beetle though. Are programs like fsdb still around?
>
> I haven't seen much like that in a while -- I think BSD/OS or NetBSD had
> a working one a few years back, but I have no idea whether they still do.
> (BSD/OS being a sort of hypothetical case anyway, now.)

[rute~]uname -v
FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 . . . . .
[rute~]which fsdb
/sbin/fsdb
[rute~]

Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm
From: Barry Margolin on 15 Mar 2010 14:29
In article <hnhol0$ais$1(a)news.eternal-september.org>,
Jon LaBadie <jlabadie(a)aXcXm.org> wrote:

> Francis Moreau wrote:
> > On Mar 12, 3:10 am, Barry Margolin <bar...(a)alum.mit.edu> wrote:
> >> In article
> >> <74384b7d-fac6-48bf-9da3-86894ecc5...(a)z11g2000yqz.googlegroups.com>,
> >> Francis Moreau <francis.m...(a)gmail.com> wrote:
> >>
> >>> But I'm not trying to access the content of the directory (hence not
> >>> trying to access to the remote data), I'm just try to stat the
> >>> directory .gvfs on which something is mounted (that's why I pass '-ld'
> >>> switches to ls(1))
> >> Stat accesses the mounted directory, not the underlying mount point.
> >>
> >
> > So are there any ways to stats the underlying mount point ?
>
> UNIX systems used to have a File System DeBugger, fsdb, that could
> be used to examine the underlying mount point. Might be using a
> cannon to squash a beetle though. Are programs like fsdb still around?

I'd expect fsdb to access the raw disk device, not go through the file
system. Am I wrong?

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: mount(8) followed by umount(8) fails
Next: how to automatically run a script as long as an input file is available