public inbox for util-linux@vger.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Phillip Susi <psusi@ubuntu.com>
Cc: util-linux@vger.kernel.org
Subject: Re: Bind mounts record fstype of none
Date: Thu, 31 Oct 2013 16:10:01 +0100	[thread overview]
Message-ID: <20131031151001.GH1536@x2.net.home> (raw)
In-Reply-To: <527266B0.7040201@ubuntu.com>

On Thu, Oct 31, 2013 at 10:18:24AM -0400, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/31/2013 6:57 AM, Karel Zak wrote:
> > On Wed, Oct 30, 2013 at 11:15:59AM -0400, Phillip Susi wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> I came across an old bug filed in debian noting that mount
> >> records the fstype for bind mounts as 'none' and this causes df
> >> to suppress
> > 
> > It was explicitly requested by Al Viro to use "none" for some VFS
> > operations years ago (c4966ccb16868fa748009a826340fac9d1b1ce39, 
> > 0fae284a7a13d4d2dba7a908e0662a6d9c46f877).
> > 
> > I think it's correct, because FS type does not make any sense
> > there and it's waste of time to try to determine FS type for
> > MS_BINS or MS_PROPAGATION operations.
> 
> How does it not make sense?

 It is not FS operation, FS type is completely irrelevant here, kernel
 does not use this argument of the mount(2) syscall.

> >> showing it.  This seems like an error to me.  The type should be
> >> what the actual filesystem type is, and if df wants to suppress
> >> showing bind mounts, it should do so based on the bind flag.
> > 
> > Seems like you're victim of the mtab file. My Fedora 19:
> > 
> > # mount --bind /home /mnt/test # mount | grep /mnt/test /dev/sda5
> > on /mnt/test type ext4 (rw,relatime,data=ordered)
> 
> Since the kernel reports the correct type, then I'd say mount should
> behave the same when using mtab, and record it right instead of
> forcing it to none.

 There is *many disadvantages* when you use mtab, not sure if it make
 sense to fix the issues especially when mtab is currently unused by 
 (almost) all distributions.

 Maybe we can keep the fstype and not replace it with "none" for mtab,
 but is it so important when we use "none" since 2009 and mtab is
 almost dead?

    Karel

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

  reply	other threads:[~2013-10-31 15:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30 15:15 Bind mounts record fstype of none Phillip Susi
2013-10-30 15:39 ` Bernhard Voelker
2013-10-30 15:59   ` Phillip Susi
2013-10-30 16:23     ` Bernhard Voelker
2013-10-30 16:31       ` Helmut Hullen
2013-10-30 16:45         ` Dave Reisner
2013-10-30 17:04           ` Helmut Hullen
2013-10-30 16:48         ` Bernhard Voelker
2013-10-30 19:10       ` Phillip Susi
2013-10-30 16:13 ` Helmut Hullen
2013-10-31 10:57 ` Karel Zak
2013-10-31 14:18   ` Phillip Susi
2013-10-31 15:10     ` Karel Zak [this message]
2013-10-31 15:28       ` Phillip Susi
2013-10-31 16:50         ` Karel Zak
2013-10-31 16:53         ` Karel Zak
2013-10-31 15:19     ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131031151001.GH1536@x2.net.home \
    --to=kzak@redhat.com \
    --cc=psusi@ubuntu.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox