question about findmnt --target

question about findmnt --target

[Ruediger Meier]

Hi,

I wonder what is the correct way to find a mount which is mounted to a 
certain target directory. findmnt --target will also find a mount if 
you specify a subdirectory of a mountpoint:

$ mkdir /tmp/bla
$ findmnt --target /tmp/bla
TARGET SOURCE                        FSTYPE OPTIONS
/tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....

The man page let me think that --target should not find the parent 
directory.

man findmnt:
  [...]
  findmnt [options] device|mountpoint
  findmnt [options] [--source] device [--target] mountpoint
  [...]
  The device may be specified by [...].  Note that a device name may be
  interpreted as a mountpoint (and vice versa) if the --target
  or --source options are not specified.
  [...]
  -T, --target dir
         Explicitly define the mount target (mountpoint directory).


I'm asking because even our test-suite is using findmnt wrong, for 
example tests/ts/mount/move:
[...]
# move
$TS_CMD_MOUNT --move $DIR_A $DIR_B

# check the move
$TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null
[ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B"
[...]

This findmnt line will never fail I guess.

cu,
Rudi

Re: question about findmnt --target

[Karel Zak]

On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote:
> Hi,
> 
> I wonder what is the correct way to find a mount which is mounted to a 
> certain target directory. findmnt --target will also find a mount if 
> you specify a subdirectory of a mountpoint:
> 
> $ mkdir /tmp/bla
> $ findmnt --target /tmp/bla
> TARGET SOURCE                        FSTYPE OPTIONS
> /tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....
> 
> The man page let me think that --target should not find the parent 
> directory.

No, it's expected behavior since:

    commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1
    Author: Dave Reisner <dreisner@archlinux.org>
    Date:   Wed Apr 25 20:30:52 2012 -0400

and the current git tree contains:

       -T, --target path
             Explicitly define the mount target (mountpoint
             directory). If the path is not a  mountpoint file
             or directory than findmnt checks path elements in
             reverse order for get the mountpoint (this
             feature is supported only if search in kernel
             files and unsupported for --fstab).


> $TS_CMD_MOUNT --move $DIR_A $DIR_B
> 
> # check the move
> $TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null
> [ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B"
> [...]
> 
> This findmnt line will never fail I guess.

Right, this is mistake, solution is to remove --target:

    TS_CMD_FINDMNT --kernel "$DIR_B" &> /dev/null


The disadvantage is that without --source/target findmnt(8) tries
to use the path as source and then as target. It's bad in same cases.

Maybe we need a new option to disable the evaluation of the target
path elements. (--strict-target)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: question about findmnt --target

[Ruediger Meier]

On Tuesday 17 March 2015, Karel Zak wrote:
> On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote:
> > Hi,
> >
> > I wonder what is the correct way to find a mount which is mounted
> > to a certain target directory. findmnt --target will also find a
> > mount if you specify a subdirectory of a mountpoint:
> >
> > $ mkdir /tmp/bla
> > $ findmnt --target /tmp/bla
> > TARGET SOURCE                        FSTYPE OPTIONS
> > /tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....
> >
> > The man page let me think that --target should not find the parent
> > directory.
>
> No, it's expected behavior since:
>
>     commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1
>     Author: Dave Reisner <dreisner@archlinux.org>
>     Date:   Wed Apr 25 20:30:52 2012 -0400

Ok, but this was a regression for a common use case. I guess to late to 
revert. Even you liked this old behavior:

commit 1f42e1089aadbe537bb59143502ebd1767d3f7ea
Author: Karel Zak <kzak@redhat.com>
Date:   Sun Jan 2 22:56:31 2011 +0100

    tests: use findmnt(8) for mount --move test


> and the current git tree contains:
>
>        -T, --target path
>              Explicitly define the mount target (mountpoint
>              directory). If the path is not a  mountpoint file
>              or directory than findmnt checks path elements in
>              reverse order for get the mountpoint (this
>              feature is supported only if search in kernel
>              files and unsupported for --fstab).

Ah ok, but IMO because of this regression we should make it even more 
clear. Probably the first sentence should not contain "mount target" 
and "mountpoint" without also using the term "parent directory" or 
similar. 

I think for df(1) it's written nicely:

  df [OPTION]... [FILE]...
  Show information about the file system on which each FILE resides, or
  all file systems by default.

> > $TS_CMD_MOUNT --move $DIR_A $DIR_B
> >
> > # check the move
> > $TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null
> > [ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B"
> > [...]
> >
> > This findmnt line will never fail I guess.
>
> Right, this is mistake, solution is to remove --target:
>
>     TS_CMD_FINDMNT --kernel "$DIR_B" &> /dev/null

>
> The disadvantage is that without --source/target findmnt(8) tries
> to use the path as source and then as target. It's bad in same cases.
>
> Maybe we need a new option to disable the evaluation of the target
> path elements. (--strict-target)

What about "findmnt --target /bla/xyz --no-parents" instead 
of --strict-target?

I have to admint that I don't really like the current behavior 
of --target and the default case without --source/target. Of course we 
can't change it anymore.

cu,
Rudi

Re: question about findmnt --target

[Karel Zak]

On Tue, Mar 17, 2015 at 06:14:00PM +0100, Ruediger Meier wrote:
> On Tuesday 17 March 2015, Karel Zak wrote:
> > On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote:
> > > Hi,
> > >
> > > I wonder what is the correct way to find a mount which is mounted
> > > to a certain target directory. findmnt --target will also find a
> > > mount if you specify a subdirectory of a mountpoint:
> > >
> > > $ mkdir /tmp/bla
> > > $ findmnt --target /tmp/bla
> > > TARGET SOURCE                        FSTYPE OPTIONS
> > > /tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....
> > >
> > > The man page let me think that --target should not find the parent
> > > directory.
> >
> > No, it's expected behavior since:
> >
> >     commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1
> >     Author: Dave Reisner <dreisner@archlinux.org>
> >     Date:   Wed Apr 25 20:30:52 2012 -0400
> 
> Ok, but this was a regression for a common use case. I guess to late to 
> revert. Even you liked this old behavior:

Well, the common use-case is to not use --target :-) But I agree that
the feature is questionable. The mistake is that the original (non-df)
behavior has not been covered by test. 

> commit 1f42e1089aadbe537bb59143502ebd1767d3f7ea
> Author: Karel Zak <kzak@redhat.com>
> Date:   Sun Jan 2 22:56:31 2011 +0100
> 
>     tests: use findmnt(8) for mount --move test
> 
> 
> > and the current git tree contains:
> >
> >        -T, --target path
> >              Explicitly define the mount target (mountpoint
> >              directory). If the path is not a  mountpoint file
> >              or directory than findmnt checks path elements in
> >              reverse order for get the mountpoint (this
> >              feature is supported only if search in kernel
> >              files and unsupported for --fstab).
> 
> Ah ok, but IMO because of this regression we should make it even more 
> clear. Probably the first sentence should not contain "mount target" 
> and "mountpoint" without also using the term "parent directory" or 
> similar. 
> 
> I think for df(1) it's written nicely:
> 
>   df [OPTION]... [FILE]...
>   Show information about the file system on which each FILE resides, or
>   all file systems by default.

OK.

> > > $TS_CMD_MOUNT --move $DIR_A $DIR_B
> > >
> > > # check the move
> > > $TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null
> > > [ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B"
> > > [...]
> > >
> > > This findmnt line will never fail I guess.
> >
> > Right, this is mistake, solution is to remove --target:
> >
> >     TS_CMD_FINDMNT --kernel "$DIR_B" &> /dev/null
> 
> >
> > The disadvantage is that without --source/target findmnt(8) tries
> > to use the path as source and then as target. It's bad in same cases.
> >
> > Maybe we need a new option to disable the evaluation of the target
> > path elements. (--strict-target)
> 
> What about "findmnt --target /bla/xyz --no-parents" instead 
> of --strict-target?

No problem.

> I have to admint that I don't really like the current behavior 
> of --target and the default case without --source/target. Of course we 
> can't change it anymore.

Yes, after 3 years it's better to keep the current behavior and
provide an option to disable the "smart" target evaluation. Do you
want to send a patch? (or I can do that tomorrow.)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: question about findmnt --target

[Ruediger Meier]

On Tuesday 17 March 2015, Karel Zak wrote:
> On Tue, Mar 17, 2015 at 06:14:00PM +0100, Ruediger Meier wrote:
> > On Tuesday 17 March 2015, Karel Zak wrote:
> > > On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote:
> > > > Hi,
> > > >
> > > > I wonder what is the correct way to find a mount which is
> > > > mounted to a certain target directory. findmnt --target will
> > > > also find a mount if you specify a subdirectory of a
> > > > mountpoint:
> > > >
> > > > $ mkdir /tmp/bla
> > > > $ findmnt --target /tmp/bla
> > > > TARGET SOURCE                        FSTYPE OPTIONS
> > > > /tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....
> > > >
> > > > The man page let me think that --target should not find the
> > > > parent directory.
> > >
> > > No, it's expected behavior since:
> > >
> > >     commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1
> > >     Author: Dave Reisner <dreisner@archlinux.org>
> > >     Date:   Wed Apr 25 20:30:52 2012 -0400
> >
> > Ok, but this was a regression for a common use case. I guess to
> > late to revert. Even you liked this old behavior:
>
> Well, the common use-case is to not use --target :-)

Yes, but somehow I find the default mix of source and target
odd. For arbitrary unknown files I would never use it without
--target or --source.

BTW this kind of smart interpretation of input arguments
is something I really hate. I just played around with file names
like "253:0" or "LABEL=bla" as device nodes or mountpoints. IMO
it's horrible ... maybe even a security issue ... thinking about
placing such files or (symlinks!) into /tmp and wait until root
is there when he invokes findmnt.

Example:
$ touch  "253:0"
$ truncate -s 10 bla
$ sudo mount --bind bla "253:0"
$ findmnt --target "253:0"
TARGET                                  SOURCE                                                FSTYPE OPTIONS
/home/rudi/devel/util-linux/build/253:0 glaukos:/exports/home/rudi/devel/util-linux/build/bla nfs4   rw,...
$ findmnt "253:0"
TARGET SOURCE               FSTYPE OPTIONS
/      /dev/mapper/vg0-root ext4   rw,relatime,data=ordered

Shouldn't the last command also find all mounts with
mountpoint "./253:0"?

> But I agree that 
> the feature is questionable. The mistake is that the original
> (non-df) behavior has not been covered by test.
>
> > commit 1f42e1089aadbe537bb59143502ebd1767d3f7ea
> > Author: Karel Zak <kzak@redhat.com>
> > Date:   Sun Jan 2 22:56:31 2011 +0100
> >
> >     tests: use findmnt(8) for mount --move test
> >
> > > and the current git tree contains:
> > >
> > >        -T, --target path
> > >              Explicitly define the mount target (mountpoint
> > >              directory). If the path is not a  mountpoint file
> > >              or directory than findmnt checks path elements in
> > >              reverse order for get the mountpoint (this
> > >              feature is supported only if search in kernel
> > >              files and unsupported for --fstab).
> >
> > Ah ok, but IMO because of this regression we should make it even
> > more clear. Probably the first sentence should not contain "mount
> > target" and "mountpoint" without also using the term "parent
> > directory" or similar.
> >
> > I think for df(1) it's written nicely:
> >
> >   df [OPTION]... [FILE]...
> >   Show information about the file system on which each FILE
> > resides, or all file systems by default.
>
> OK.
>
> > > > $TS_CMD_MOUNT --move $DIR_A $DIR_B
> > > >
> > > > # check the move
> > > > $TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null
> > > > [ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B"
> > > > [...]
> > > >
> > > > This findmnt line will never fail I guess.
> > >
> > > Right, this is mistake, solution is to remove --target:
> > >
> > >     TS_CMD_FINDMNT --kernel "$DIR_B" &> /dev/null
> > >
> > >
> > > The disadvantage is that without --source/target findmnt(8) tries
> > > to use the path as source and then as target. It's bad in same
> > > cases.
> > >
> > > Maybe we need a new option to disable the evaluation of the
> > > target path elements. (--strict-target)
> >
> > What about "findmnt --target /bla/xyz --no-parents" instead
> > of --strict-target?
>
> No problem.

I'm still not 100% sure. Now I think --mountpoint could be nice
to change the current short usage from this:

 findmnt [options] <device> | <mountpoint>
 findmnt [options] [--source <device>] [--target <mountpoint>]

to this:

 findmnt [options] <source> | <mountpoint>
 findmnt [options] [--source <source>] [--target <file>] [--mountpoint <mountpoint>]

... without changing current behavior.

Moreover we could add "--parent" so that "--mountpoint --parent"
would do the same like "--target" does now. Just keeping --target for
compatibility. Maybe even set --target deprecated and remove it from
short usage documentation.


> > I have to admint that I don't really like the current behavior
> > of --target and the default case without --source/target. Of course
> > we can't change it anymore.
>
> Yes, after 3 years it's better to keep the current behavior and
> provide an option to disable the "smart" target evaluation. Do you
> want to send a patch? (or I can do that tomorrow.)

Please go ahead, I guess I would need much more time for this.

cu,
Rudi 

Re: question about findmnt --target

[Karel Zak]

On Wed, Mar 18, 2015 at 02:50:41PM +0100, Ruediger Meier wrote:
> On Tuesday 17 March 2015, Karel Zak wrote:
> > On Tue, Mar 17, 2015 at 06:14:00PM +0100, Ruediger Meier wrote:
> > > On Tuesday 17 March 2015, Karel Zak wrote:
> > > > On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote:
> > > > > Hi,
> > > > >
> > > > > I wonder what is the correct way to find a mount which is
> > > > > mounted to a certain target directory. findmnt --target will
> > > > > also find a mount if you specify a subdirectory of a
> > > > > mountpoint:
> > > > >
> > > > > $ mkdir /tmp/bla
> > > > > $ findmnt --target /tmp/bla
> > > > > TARGET SOURCE                        FSTYPE OPTIONS
> > > > > /tmp   /dev/mapper/vg0-tmpdirs[/tmp] ext4 ....
> > > > >
> > > > > The man page let me think that --target should not find the
> > > > > parent directory.
> > > >
> > > > No, it's expected behavior since:
> > > >
> > > >     commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1
> > > >     Author: Dave Reisner <dreisner@archlinux.org>
> > > >     Date:   Wed Apr 25 20:30:52 2012 -0400
> > >
> > > Ok, but this was a regression for a common use case. I guess to
> > > late to revert. Even you liked this old behavior:
> >
> > Well, the common use-case is to not use --target :-)
> 
> Yes, but somehow I find the default mix of source and target
> odd. 

 The idea has be to follow mount(8) behavior:

      mount /dev/sda1
      mount /mnt

 that's all the story. Yes, for serious usage (e.g. in scripts) it's
 better to use --source and --target. Now we have the options also
 for mount(8) to avoid the "smart" behavior.

>  findmnt [options] <source> | <mountpoint>
>  findmnt [options] [--source <source>] [--target <file>] [--mountpoint <mountpoint>]

 Yes, exactly. I have thought about it too. It seems like a more
 transparent solution.

> Please go ahead, I guess I would need much more time for this.

 OK.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: question about findmnt --target

[Bernhard Voelker]

On 03/17/2015 05:34 PM, Karel Zak wrote:
> Maybe we need a new option to disable the evaluation of the target
> path elements. (--strict-target)

Hey, we already have a tool for that: 'mountpoint' ;-)

What's wrong with

  mountpoint "$DIR_B" >/dev/null \
    && findmnt --target "$DIR_B" \
    && ...

?

Have a nice day,
Berny

Re: question about findmnt --target

[Karel Zak]

On Wed, Mar 18, 2015 at 08:33:10AM +0100, Bernhard Voelker wrote:
> On 03/17/2015 05:34 PM, Karel Zak wrote:
> > Maybe we need a new option to disable the evaluation of the target
> > path elements. (--strict-target)
> 
> Hey, we already have a tool for that: 'mountpoint' ;-)

 Yes, it's possible solution, but if we think about findmnt as
 "complete" tool to search in mount tables than I expect that it
 provides all necessary functionality.

> What's wrong with
> 
>   mountpoint "$DIR_B" >/dev/null \
>     && findmnt --target "$DIR_B" \
>     && ...

 race, if you umount between mountpoint and findmnt.
 
 And it will also read and parse /proc/self/mountinfo in both tools. 
 
 And force kernel to compose mount table is already reported performance 
 issue on some large systems. The real solution and long-term wish is to 
 have per-mountpoint kernel API, something like
 
    fd = mountfd("/mnt", O_RDONLY);
    read(fd, buf, sizeof(fs_mountinfo));

 and in O_RDWR to mount, remount and umount, and then send old mount(2)
 syscall to hell...

   Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: question about findmnt --target

[Ruediger Meier]

On Wednesday 18 March 2015, Bernhard Voelker wrote:
> On 03/17/2015 05:34 PM, Karel Zak wrote:
> > Maybe we need a new option to disable the evaluation of the target
> > path elements. (--strict-target)
>
> Hey, we already have a tool for that: 'mountpoint' ;-)
>
> What's wrong with
>
>   mountpoint "$DIR_B" >/dev/null \
>     && findmnt --target "$DIR_B" \
>     && ...

Yeah! In context of that tests/ts/mount/move snippet this should be 
enough:

[...]
# move
$TS_CMD_MOUNT --move $DIR_A $DIR_B

# check the move
$TS_CMD_MOUNTPOINT -q $DIR_B || ts_failed "Cannot find binded $DIR_B"
[...]

I still wonder why we don't check mount's return value too. Here it 
should always return 0, right?

cu,
Rudi

Re: question about findmnt --target

[Karel Zak]

On Wed, Mar 18, 2015 at 11:39:45AM +0100, Ruediger Meier wrote:
> On Wednesday 18 March 2015, Bernhard Voelker wrote:
> > On 03/17/2015 05:34 PM, Karel Zak wrote:
> > > Maybe we need a new option to disable the evaluation of the target
> > > path elements. (--strict-target)
> >
> > Hey, we already have a tool for that: 'mountpoint' ;-)
> >
> > What's wrong with
> >
> >   mountpoint "$DIR_B" >/dev/null \
> >     && findmnt --target "$DIR_B" \
> >     && ...
> 
> Yeah! In context of that tests/ts/mount/move snippet this should be 
> enough:
> 
> [...]
> # move
> $TS_CMD_MOUNT --move $DIR_A $DIR_B
> 
> # check the move
> $TS_CMD_MOUNTPOINT -q $DIR_B || ts_failed "Cannot find binded $DIR_B"
> [...]
> 
> I still wonder why we don't check mount's return value too. Here it 
> should always return 0, right?

 check return code is good idea, but please still check the mountpoint
 too. It's mount(8) test - we need an independent verification.


    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com