[systemd-devel] when will mount / df get fixed?
Reindl Harald
h.reindl at thelounge.net
Mon Oct 1 04:40:46 PDT 2012
Am 01.10.2012 13:29, schrieb Karel Zak:
> On Sat, Sep 29, 2012 at 07:36:54PM +0200, Reindl Harald wrote:
> There is no difference. The "bind" is an operation, not a special
> state of any mountpoint. Nowhere in the system is information that
> the mountpoint has been created by "bind" -- the kernel does not
> see any difference between the original and bind mount. It's just
> another reference to the same object (device).
> mount /dev/sda1 /mnt1
> mount /dev/sda1 /mnt2
>
> is exactly the same as:
>
> mount /dev/sda1 /mnt1
> mount --bind /mnt1 /mnt2
but there was a difference until F15 came out with systemd
> We should not care about "bind" flag in mtab (or another place) at
> all. The solution is to de-duplicate df(1) output.
and how should "df" do this?
how should "df" smell that "/mnt/data" is the one to display?
/dev/md2 3814414416 2335948104 1478466312 62% /mnt/data
/dev/md2 3814414416 2335948104 1478466312 62% /home
/dev/md2 3814414416 2335948104 1478466312 62% /tmp
/dev/md2 3814414416 2335948104 1478466312 62% /var/tmp
/dev/md2 3814414416 2335948104 1478466312 62% /Volumes/dune/www-servers
/dev/md2 3814414416 2335948104 1478466312 62% /Volumes/dune/www-servers/phpincludes
> It's fine to blame systemd guys for all the bad things in the World,
> but kill the original mtab concept was planned independently on
> systemd.
however, before killing things which worked fine for decades
there should be a thought how to change things internally
without change the behavior from the users view
only the fact that the named-chroot mounts caused a error
message for a normal user proves that there was not much
testing/thinking about impacts - this one meant to get
error-mails from EVERY cronjob-script using "df"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121001/b1eeb4d5/attachment.pgp>
More information about the systemd-devel
mailing list