Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208358 > unrolled thread

A Basic Mount Observation

Back to article view | Back to linux.debian.user

Contents

  A Basic Mount Observation "Martin McCormick" <martin.m@suddenlink.net> - 2019-05-07 17:00 +0200
    Re: A Basic Mount Observation Dan Ritter <dsr@randomstring.org> - 2019-05-07 17:30 +0200
      Re: A Basic Mount Observation <tomas@tuxteam.de> - 2019-05-07 17:40 +0200
        Re: A Basic Mount Observation Cindy Sue Causey <butterflybytes@gmail.com> - 2019-05-07 18:10 +0200
          Re: A Basic Mount Observation Dan Ritter <dsr@randomstring.org> - 2019-05-07 18:30 +0200
    Re: A Basic Mount Observation Cindy Sue Causey <butterflybytes@gmail.com> - 2019-05-07 18:10 +0200
      Re: A Basic Mount Observation Bob Weber <bobrweber@gmail.com> - 2019-05-07 19:00 +0200
      Re: A Basic Mount Observation "Thomas Schmitt" <scdbackup@gmx.net> - 2019-05-07 19:00 +0200

#208358 — A Basic Mount Observation

This Summer will mark 30 years since I first laid hands on a
unix-like system.  I probably was introduced to unix mount points
very shortly after starting in the unix world which reminded me a
lot of MSDOS except that there aren't nearly as many gotchas and
things worked like one would dream they should work so I was
probably introduced to the concept of the mount point somewhere
in those early days.

	I may just be remembering things the wrong way but it
seems like that for most of my memory, one could be root and, if
you cd'd to a mount point, one could mount /dev/whatever on that
mount point and immediately see the top of the new tree you had
just mounted.  If you cd'd in to that tree and tried to umount,
you got the error that the file system was busy which makes sense
because you are trying to saw off the limb you are sitting on, so
to speak.

	If you cd'd out of the mount point and nobody else was in
it, you could umount and all was well.

	I accidentally discovered now that I can become the root
user, cd to a mount point and mount something with a subsequent
ls of my current directory yielding nothing new.  One doesn't see
the new mount.

	If you open another session and look at the mount point,
the new mount is there.  You can even create a file under the new
mount which is only visible to you if you didn't cd out of the
mount point.  Everybody else who looks at that point will see
what's mounted there and not the test file slipped in under the
mount.

	Has this always been the normal behavior of mount or has
there been a change?

	I see this behavior as being useful like self-modifying
code which is usually a huge thing to avoid but it was kind of
interesting to notice.

Martin McCormick

[toc] | [next] | [standalone]

#208359

Martin McCormick wrote: 
> 	I may just be remembering things the wrong way but it
> seems like that for most of my memory, one could be root and, if
> you cd'd to a mount point, one could mount /dev/whatever on that
> mount point and immediately see the top of the new tree you had
> just mounted.  If you cd'd in to that tree and tried to umount,
> you got the error that the file system was busy which makes sense
> because you are trying to saw off the limb you are sitting on, so
> to speak.
> 
> 	If you cd'd out of the mount point and nobody else was in
> it, you could umount and all was well.
> 
> 	I accidentally discovered now that I can become the root
> user, cd to a mount point and mount something with a subsequent
> ls of my current directory yielding nothing new.  One doesn't see
> the new mount.
> 
> 	If you open another session and look at the mount point,
> the new mount is there.  You can even create a file under the new
> mount which is only visible to you if you didn't cd out of the
> mount point.  Everybody else who looks at that point will see
> what's mounted there and not the test file slipped in under the
> mount.
> 
> 	Has this always been the normal behavior of mount or has
> there been a change?

mkdir point
cd point
touch original
ls
    original
mount /dev/whatever .
ls 
    original
cd ..
cd point
ls
    whatever-was-in-whatever
cd ..
umount point
cd point
ls
    original

This behavior has always been consistent in Linux, as far as I am aware.

The handle to your current directory cannot be changed out from
underneath you; only when you move away from it can it be
released, and from then on you see the new mount.

-dsr-

[toc] | [prev] | [next] | [standalone]

#208361

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 07, 2019 at 11:20:57AM -0400, Dan Ritter wrote:
> Martin McCormick wrote: 
> > 	I may just be remembering things the wrong way [...]

[about not immediatlely "seeing" the results of a mount on the CWD]

[...]

> mkdir point
> cd point
> touch original
> ls

[practical demonstration illustrating that]

> This behavior has always been consistent in Linux, as far as I am aware.
> 
> The handle to your current directory cannot be changed out from
> underneath you; only when you move away from it can it be
> released, and from then on you see the new mount.

Makes sense: the current shell (and that is from where we're looking
at things) keeps the current working directory, CWD, open. This inode
doesn't go away after a mount -- thus as long as the shell doesn't
close it (by, e.g., changing to another directory), it will keep
"seeing" that directory, even if a new process doing an open() will
"see" the result after the mount.

You can achieve similarly funny results by removing a file (or directory)
while it's kept open by a process.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#208362

On 5/7/19, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Tue, May 07, 2019 at 11:20:57AM -0400, Dan Ritter wrote:
>> Martin McCormick wrote:
>> > 	I may just be remembering things the wrong way [...]
>
> [about not immediatlely "seeing" the results of a mount on the CWD]
>
> [...]
>
>> mkdir point
>> cd point
>> touch original
>> ls
>
> [practical demonstration illustrating that]
>
>> This behavior has always been consistent in Linux, as far as I am aware.
>>
>> The handle to your current directory cannot be changed out from
>> underneath you; only when you move away from it can it be
>> released, and from then on you see the new mount.
>
> Makes sense: the current shell (and that is from where we're looking
> at things) keeps the current working directory, CWD, open. This inode
> doesn't go away after a mount -- thus as long as the shell doesn't
> close it (by, e.g., changing to another directory), it will keep
> "seeing" that directory, even if a new process doing an open() will
> "see" the result after the mount.
>
> You can achieve similarly funny results by removing a file (or directory)
> while it's kept open by a process.


Okayyyy.. It sounds like this is a good training point for learning
interoperability that's occurring if there's any way to... maybe point
to images or something that help drive that point on home. I'm almost
already fully grasping at this second because I just worked my own
thought process via terminal. I'm going to reread the above a few more
times then wait for that Linux operation that finally draws it all
together enough to invoke an *ah-HAAA* moment. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#208364

Cindy Sue Causey wrote: 
> On 5/7/19, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> >
> > Makes sense: the current shell (and that is from where we're looking
> > at things) keeps the current working directory, CWD, open. This inode
> > doesn't go away after a mount -- thus as long as the shell doesn't
> > close it (by, e.g., changing to another directory), it will keep
> > "seeing" that directory, even if a new process doing an open() will
> > "see" the result after the mount.
> 
> Okayyyy.. It sounds like this is a good training point for learning
> interoperability that's occurring if there's any way to... maybe point
> to images or something that help drive that point on home. I'm almost
> already fully grasping at this second because I just worked my own
> thought process via terminal. I'm going to reread the above a few more
> times then wait for that Linux operation that finally draws it all
> together enough to invoke an *ah-HAAA* moment. :)

Each process opens files and closes them. In this case, a
directory counts as a special kind of file.

An "open" is a process telling the kernel that it wants to use
a file. If it's successful, the kernel gives the process a file
handle, which is a bit of identifying data. When the process
"closes" the file, it hands the file handle back to the kernel. 
In the meantime, it may have called for read or write operations
on the handle.

Your shell is a process. When you issue a 'cd' command, it
opens the new directory, and when that works, closes the old
directory. If it fails, it still has the old directory's file
handle and doesn't close it, so you have a "place" to be.

When a mount happens, that doesn't change the file handles that
have already been issued. They are still valid. When an unmount
happens, issued file handles will become invalid if they were
part of the mounted filesystem which has now gone away.

Does that help? 

-dsr-

[toc] | [prev] | [next] | [standalone]

#208363

On 5/7/19, Martin McCormick <martin.m@suddenlink.net> wrote:
> This Summer will mark 30 years since I first laid hands on a
> unix-like system.  I probably was introduced to unix mount points
> very shortly after starting in the unix world which reminded me a
> lot of MSDOS except that there aren't nearly as many gotchas and
> things worked like one would dream they should work so I was
> probably introduced to the concept of the mount point somewhere
> in those early days.
>
> 	I may just be remembering things the wrong way but it
> seems like that for most of my memory, one could be root and, if
> you cd'd to a mount point, one could mount /dev/whatever on that
> mount point and immediately see the top of the new tree you had
> just mounted.  If you cd'd in to that tree and tried to umount,
> you got the error that the file system was busy which makes sense
> because you are trying to saw off the limb you are sitting on, so
> to speak.
>
> 	If you cd'd out of the mount point and nobody else was in
> it, you could umount and all was well.
>
> 	I accidentally discovered now that I can become the root
> user, cd to a mount point and mount something with a subsequent
> ls of my current directory yielding nothing new.  One doesn't see
> the new mount.
>
> 	If you open another session and look at the mount point,
> the new mount is there.  You can even create a file under the new
> mount which is only visible to you if you didn't cd out of the
> mount point.  Everybody else who looks at that point will see
> what's mounted there and not the test file slipped in under the
> mount.
>
> 	Has this always been the normal behavior of mount or has
> there been a change?
>
> 	I see this behavior as being useful like self-modifying
> code which is usually a huge thing to avoid but it was kind of
> interesting to notice.


I didn't fully *cognitively* grasp what you're saying, BUT I did grasp
enough to attempt the following via xfce4-terminal:

$ cd /mountpoint
$ ls
$ *(anticipated) crickets*
$ sudo (YEAH, I KNOW!) mount LABEL=buster-backup /mountpoint
$ ls
$ *mammoth-sized crickets*

*hm* so I next....

$ thunar /mountpoint

That same mountpoint via Thunar file manager (opened via the terminal
at that same mountpoint) is now chock full of the expected
directories, initrd's, vmlinuz's...

*HM* so I next closed Thunar with the thought process being that maybe
opening Thunar finally brought everything to Life. I once again
ran....

$ ls
$ *STILL. crickets.*

Nothin' comes back in answer to "ls". I actually figured this NEXT
attempt would FINALLY work. INSTEAD, that which "always does work" has
now been amended to... "almost always does work":

$ ls -ld *
ls: cannot access '*': No such file or directory

??? LOL. In the past, "ls -ld *" has ALWAYS presented query feedback
at times when "ls *" has failed for (system ordained) reasons that so
far zip on by overhead.

Was still not ready to give up SO THEN I lastly tried....

CTRL+SHIFT+T to open a new terminal tab. By default in xfce4-terminal,
that opens up in the same directory that the last active tab was
using. Directories and files now all pull up for "ls" while sitting in
/mountpoint.

There was another something I did a while back that I can't remember
now, but you had to exit the terminal then reopen it for the desired
effect to take place. I'm halfway thinking it might be something from
Linux From Scratch (LFS) or similar Linux self-education type
exercises. Whatever I'm not remembering, that's what this feels
like...

If it's not quite what you were saying, it's still showing a...
not-quite-anticipated twist on things so that's why I posted. The last
few steps came to mind to test as I was typing this up. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#208366

[Multipart message — attachments visible in raw view] — view raw

On 5/7/19 12:02 PM, Cindy Sue Causey wrote:
> I didn't fully *cognitively* grasp what you're saying, BUT I did grasp
> enough to attempt the following via xfce4-terminal:
>
> $ cd /mountpoint
> $ ls
> $ *(anticipated) crickets*
> $ sudo (YEAH, I KNOW!) mount LABEL=buster-backup /mountpoint
> $ ls
> $ *mammoth-sized crickets*

I would never have thought to do it this way.  It always made more sense to be 
in the directory just above the actual mount point.  Say I have a directory 
/mnt/tom.  I would:

cd  /mnt

mount /dev/whatever tom

ls tom

... would show the contents of what was just mounted if there were no errors.

If you have the following line in /etc/fstab (and the fuse programs necessary):

sshfs#sue@cindyslaptop:/home/sue /mnt/sue         fuse        user,noauto,rw    
0       0

and run:

cd /mnt

mount sue

ls sue

... would show sue's directory on cindyslaptop.  Notice that since there is an 
entry for /mnt/sue in fstab you only need to mount the directory /mnt/sue.

I use this to mount a directory on a remote machine locally after setting up 
public key authentication so it doesn't even ask for a password.   This could 
also be used with file systems in /dev but they would always need to be the same 
name (like /dev/sdc1) or some other way to identify the exact drive to be 
mounted like the drives UUID.


*...Bob*

[toc] | [prev] | [next] | [standalone]

#208367

Hi,

Cindy Sue Causey wrote:
> $ ls
> $ *STILL. crickets.*

You need to re-enter the directory, because the thing which now has
its name is not the directory which you entered before mount.

All programs which show the mounted content have addressed the directory
by its name after the mount operation.
Those programs which show the empty mount point directory have resolved
the address to a directory inode before the mount operation.


Let's look at device and inode numbers rather than names:

  # stat --format='%d %i' /mnt/iso
  2051 11796486
  # cd /mnt/iso
  # ls -ldi .
  11796486 drwxr-xr-x 2 root root 4096 ...date... .

You see that the mount point directory has inode number 11796486 in its
filesystem on device 2051.
Now with mounting

  # mount test.iso /mnt/iso
  # stat --format='%d %i' /mnt/iso
  1792 1216
  # ls -ldi /mnt/iso
  1216 dr-xr-xr-x 1 root root 2048 ...other.date... /mnt/iso

The mounted directory has inode number 1216 in the mounted ISO filesystem
on device 1792.

But your working directory is still the other inode

  # ls -ldi .
  11796486 drwxr-xr-x 2 root root 4096 ...date... .

Now set your working directory to what is pointed to by path /mnt/iso:

  # cd /mnt/iso
  # ls -ldi .
  1216 dr-xr-xr-x 1 root root 2048 ...other.date... .

Now you are in the root inode of the ISO and normally cannot unmount
before you leave it.

Go away and unmount to see the inode numer in the disk filesystem again:

  # cd
  # umount /mnt/iso
  # ls -ldi /mnt/iso
  11796486 drwxr-xr-x 2 root root 4096 ...date... /mnt/iso


Have a nice day :)

Thomas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web