5:30 p.m.
what triggers that since F15 every bind-mount is displayed in
"df" with "ext4" and the full volume-szize and additionally
if BIND is running in a chroot FOUR volumes with the size
of the root-fs are shown and a normal user gets "access denied"?
this is way too much for 3 physical volumes!
[root@rh:~]$ /bin/df -hT
Dateisystem Typ Größe Benut Verf Ben%% Eingehängt auf
rootfs rootfs 29G 8,5G 21G 30% /
udev devtmpfs 7,8G 4,0K 7,8G 1% /dev
tmpfs tmpfs 1,0G 0 1,0G 0% /dev/shm
tmpfs tmpfs 7,9G 552K 7,9G 1% /run
/dev/md1 ext4 29G 8,5G 21G 30% /
tmpfs tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/run
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/lock
tmpfs tmpfs 150M 0 150M 0% /var/www/sessiondata
tmpfs tmpfs 7,9G 0 7,9G 0% /media
/dev/md0 ext4 485M 48M 437M 10% /boot
/dev/md2 ext4 3,6T 474G 3,1T 14% /mnt/data
/dev/md2 ext4 3,6T 474G 3,1T 14% /home
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers/phpincludes
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/usr/lib64/bind
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named.iscdlv.key
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named.root.key
[root@rh:~]$ su - harry
[harry@rh:~]$ /bin/df -hT
Dateisystem Typ Größe Benut Verf Ben%% Eingehängt auf
rootfs rootfs 29G 8,5G 21G 30% /
udev devtmpfs 7,8G 4,0K 7,8G 1% /dev
tmpfs tmpfs 1,0G 0 1,0G 0% /dev/shm
tmpfs tmpfs 7,9G 552K 7,9G 1% /run
/dev/md1 ext4 29G 8,5G 21G 30% /
tmpfs tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/run
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/lock
tmpfs tmpfs 150M 0 150M 0% /var/www/sessiondata
tmpfs tmpfs 7,9G 0 7,9G 0% /media
/dev/md0 ext4 485M 48M 437M 10% /boot
/dev/md2 ext4 3,6T 474G 3,1T 14% /mnt/data
/dev/md2 ext4 3,6T 474G 3,1T 14% /home
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers/phpincludes
/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung
7:11 p.m.
On 06/19/2011 03:30 PM, Reindl Harald wrote:
what triggers that since F15 every bind-mount is displayed in
"df" with "ext4" and the full volume-szize and additionally
if BIND is running in a chroot FOUR volumes with the size
of the root-fs are shown and a normal user gets "access denied"?
this is way too much for 3 physical volumes!
This is because /proc/mounts doesn't store the fact that they're bind
mounts, and /etc/mtab is now a symlink to /proc/mounts instead of a
regular file maintained by mount and umount.
7:16 p.m.
Am 20.06.2011 02:11, schrieb Nicholas Miell:
On 06/19/2011 03:30 PM, Reindl Harald wrote:
> what triggers that since F15 every bind-mount is displayed in
> "df" with "ext4" and the full volume-szize and additionally
> if BIND is running in a chroot FOUR volumes with the size
> of the root-fs are shown and a normal user gets "access denied"?
>
> this is way too much for 3 physical volumes!
This is because /proc/mounts doesn't store the fact that they're bind
mounts, and /etc/mtab is now a symlink to /proc/mounts instead of a
regular file maintained by mount and umount
hm - bad
thinking of chrooted sftp with a hughe count of bind-mounts
for the users this will be really confusing
3:04 a.m.
Am 20.06.2011 02:16, schrieb Reindl Harald:
Am 20.06.2011 02:11, schrieb Nicholas Miell:
> On 06/19/2011 03:30 PM, Reindl Harald wrote:
>> what triggers that since F15 every bind-mount is displayed in
>> "df" with "ext4" and the full volume-szize and additionally
>> if BIND is running in a chroot FOUR volumes with the size
>> of the root-fs are shown and a normal user gets "access denied"?
>>
>> this is way too much for 3 physical volumes!
>
> This is because /proc/mounts doesn't store the fact that they're bind
> mounts, and /etc/mtab is now a symlink to /proc/mounts instead of a
> regular file maintained by mount and umount
hm - bad
thinking of chrooted sftp with a hughe count of bind-mounts
for the users this will be really confusing
and here the first cron-mails because scripts do see things they
have not to see, this is not only ugly, it changes behavior and
should be reverted - not anything waht will be changed in things
worked for nearly 40 years makes them really better!
-------- Original-Nachricht --------
Betreff: Cron <root@srv-rhsoft> nice -n 19 run-parts /etc/cron.daily
Datum: Mon, 20 Jun 2011 04:02:09 +0200 (CEST)
Von: Cron Daemon <root(a)srv-rhsoft.rhsoft.net>
An: root(a)srv-rhsoft.rhsoft.net
/etc/cron.daily/linuxcounter.cron:
/bin/df: `/var/named/chroot/etc/named': Permission denied
/bin/df: `/var/named/chroot/usr/lib64/bind': Permission denied
/bin/df: `/var/named/chroot/etc/named.iscdlv.key': Permission denied
/bin/df: `/var/named/chroot/etc/named.root.key': Permission denied
2:01 p.m.
For context on the change in mtab behavior please read over the
upstream util-linux mailing list discussions concerning /etc/mtab.
I would suggest you start your review of discussion with this thread from 2007:
http://thread.gmane.org/gmane.linux.file-systems/15576/focus=15594
-jef
On Mon, Jun 20, 2011 at 12:04 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 20.06.2011 02:16, schrieb Reindl Harald:
>
> Am 20.06.2011 02:11, schrieb Nicholas Miell:
>> On 06/19/2011 03:30 PM, Reindl Harald wrote:
>>> what triggers that since F15 every bind-mount is displayed in
>>> "df" with "ext4" and the full volume-szize and
additionally
>>> if BIND is running in a chroot FOUR volumes with the size
>>> of the root-fs are shown and a normal user gets "access denied"?
>>>
>>> this is way too much for 3 physical volumes!
>>
>> This is because /proc/mounts doesn't store the fact that they're bind
>> mounts, and /etc/mtab is now a symlink to /proc/mounts instead of a
>> regular file maintained by mount and umount
>
> hm - bad
>
> thinking of chrooted sftp with a hughe count of bind-mounts
> for the users this will be really confusing
and here the first cron-mails because scripts do see things they
have not to see, this is not only ugly, it changes behavior and
should be reverted - not anything waht will be changed in things
worked for nearly 40 years makes them really better!
-------- Original-Nachricht --------
Betreff: Cron <root@srv-rhsoft> nice -n 19 run-parts /etc/cron.daily
Datum: Mon, 20 Jun 2011 04:02:09 +0200 (CEST)
Von: Cron Daemon <root(a)srv-rhsoft.rhsoft.net>
An: root(a)srv-rhsoft.rhsoft.net
/etc/cron.daily/linuxcounter.cron:
/bin/df: `/var/named/chroot/etc/named': Permission denied
/bin/df: `/var/named/chroot/usr/lib64/bind': Permission denied
/bin/df: `/var/named/chroot/etc/named.iscdlv.key': Permission denied
/bin/df: `/var/named/chroot/etc/named.root.key': Permission denied
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
9:53 a.m.
On Mon, Jun 20, 2011 at 12:30:15AM +0200, Reindl Harald wrote:
what triggers that since F15 every bind-mount is displayed in
"df" with "ext4" and the full volume-szize and additionally
https://bugzilla.redhat.com/show_bug.cgi?id=709351
The tools (not only df(1)) have to be fixed to de-duplicate the list
of fileststems. It's standard behavior that the same filesystem could
be mounted on more places.
The 'bind' flag is another way how to achieve that the filesystem is
mounted on another place. Nothing other.
# mount /dev/sdb1 /mnt/A
# mount --bind /mnt/A /mnt/B
is the same thing as:
# mount /dev/sdb1 /mnt/A
# mount /dev/sdb1 /mnt/B
there is nothing like 'bind' state of the filesystem. The 'bind' info in
mtab was always broken by design.
http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
10:21 a.m.
On 23/06/11 15:53, Karel Zak wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=709351
The tools (not only df(1)) have to be fixed to de-duplicate the list
of fileststems. It's standard behavior that the same filesystem could
be mounted on more places.
The 'bind' flag is another way how to achieve that the filesystem is
mounted on another place. Nothing other.
# mount /dev/sdb1 /mnt/A
# mount --bind /mnt/A /mnt/B
is the same thing as:
# mount /dev/sdb1 /mnt/A
# mount /dev/sdb1 /mnt/B
there is nothing like 'bind' state of the filesystem. The 'bind' info in
mtab was always broken by design.
http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html
Thanks for that info.
I did a find_bind_mount() function as part of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
I also adjusted df to handle bind mounts better with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9
I'll have to revisit these to see if they're still valid.
I'll have a look at fixing up df (I guess I'll reverse the mount list
and have some internal hash to detect dupes?).
I need to see why F15 has started doing this too.
For example on my system there are 2 _identical_ entries
for /home in /proc/mounts.
cheers,
Pádraig.
4:44 p.m.
On Thu, 2011-06-23 at 16:21 +0100, Pádraig Brady wrote:
On 23/06/11 15:53, Karel Zak wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=709351
>
> The tools (not only df(1)) have to be fixed to de-duplicate the list
> of fileststems. It's standard behavior that the same filesystem could
> be mounted on more places.
>
> The 'bind' flag is another way how to achieve that the filesystem is
> mounted on another place. Nothing other.
>
> # mount /dev/sdb1 /mnt/A
> # mount --bind /mnt/A /mnt/B
>
> is the same thing as:
>
> # mount /dev/sdb1 /mnt/A
> # mount /dev/sdb1 /mnt/B
>
> there is nothing like 'bind' state of the filesystem. The 'bind'
info in
> mtab was always broken by design.
>
> http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html
Thanks for that info.
I did a find_bind_mount() function as part of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
I also adjusted df to handle bind mounts better with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9
I'll have to revisit these to see if they're still valid.
I'll have a look at fixing up df (I guess I'll reverse the mount list
and have some internal hash to detect dupes?).
I need to see why F15 has started doing this too.
For example on my system there are 2 _identical_ entries
for /home in /proc/mounts.
If you have the sandbox package installed, that is the reason.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
2:43 a.m.
Karel Zak <kzak(a)redhat.com> writes:
The 'bind' flag is another way how to achieve that the
filesystem is
mounted on another place. Nothing other.
# mount /dev/sdb1 /mnt/A
# mount --bind /mnt/A /mnt/B
is the same thing as:
# mount /dev/sdb1 /mnt/A
# mount /dev/sdb1 /mnt/B
There is a big difference between "mount --bind /mnt/A/B /mnt/B" and
"mount /dev/sdb1 /mnt/B".
Andreas.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
5:02 a.m.
On Fri, Jun 24, 2011 at 09:43:32AM +0200, Andreas Schwab wrote:
Karel Zak <kzak(a)redhat.com> writes:
> The 'bind' flag is another way how to achieve that the filesystem is
> mounted on another place. Nothing other.
Pedantic note, there are some extra features usable with MS_BIND,
like MS_UNBINDABLE, MS_REC, etc.
> # mount /dev/sdb1 /mnt/A
> # mount --bind /mnt/A /mnt/B
>
> is the same thing as:
>
> # mount /dev/sdb1 /mnt/A
> # mount /dev/sdb1 /mnt/B
There is a big difference between "mount --bind /mnt/A/B /mnt/B" and
"mount /dev/sdb1 /mnt/B".
Sure. The difference is that the mountpoint is not connected with root
of the filesystem, but with some subdirectory. This information is
stored in /proc/self/mountinfo.
The important is that there is not dependence on the original
mountpoint -- this fact was ignored in mtab, because mtab info about
bind mounts was always based on the paths (e.g. /mnt/A/B) instead on
devices (e.g. /dev/sdb1).
BTW, this is not specific to bind mounts, you can do the same with
btrfs subvolumes.
# mount /dev/sdb1 /mnt/A
# btrfs subvolume create /mnt/A/B
# mount /dev/sdb1 /mnt/B subvol=B
$ df | grep sdb1
/dev/sdb1 1022976 64 892032 1% /mnt/A
/dev/sdb1 1022976 64 892032 1% /mnt/B
$ findmnt /dev/sdb1
TARGET SOURCE FSTYPE OPTIONS
/mnt/A /dev/sdb1 btrfs rw,relatime,ssd
/mnt/B /dev/sdb1[/B] btrfs rw,relatime,ssd
Anyway, let's fix the utils to be usable with Linux VFS independently
on mtab.
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
6:15 a.m.
On 23/06/11 16:21, Pádraig Brady wrote:
On 23/06/11 15:53, Karel Zak wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=709351
>
> The tools (not only df(1)) have to be fixed to de-duplicate the list
> of fileststems. It's standard behavior that the same filesystem could
> be mounted on more places.
>
> The 'bind' flag is another way how to achieve that the filesystem is
> mounted on another place. Nothing other.
>
> # mount /dev/sdb1 /mnt/A
> # mount --bind /mnt/A /mnt/B
>
> is the same thing as:
>
> # mount /dev/sdb1 /mnt/A
> # mount /dev/sdb1 /mnt/B
>
> there is nothing like 'bind' state of the filesystem. The 'bind' info
in
> mtab was always broken by design.
>
> http://karelzak.blogspot.com/2011/04/bind-mounts-mtab-and-read-only.html
Thanks for that info.
I did a find_bind_mount() function as part of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
That's no longer valid.
Looks like I'll need to separately parse /proc/self/mountinfo
if we need that functionality :(
I'm sure there was a very good reason for changing that?
I also adjusted df to handle bind mounts better with:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0380e4c9
I'll have to revisit these to see if they're still valid.
That one seems less necessary now.
I'll have a look at fixing up df (I guess I'll reverse the
mount list
and have some internal hash to detect dupes?).
I had a 5 min look and I don't think it will be this easy.
I need to see why F15 has started doing this too.
For example on my system there are 2 _identical_ entries
for /home in /proc/mounts.
I've not got sandbox installed BTW.
Still need to look at this.
cheers,
Pádraig.
4:28 a.m.
On Fri, Jun 24, 2011 at 12:15:52PM +0100, Pádraig Brady wrote:
> I did a find_bind_mount() function as part of:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
Note, be careful with st_dev, because:
* after
mount --bind /mnt/A /mnt/A
/mnt/A has the same devno as /mnt/A/B, but /mnt/A is a mountpoint
* btrfs returns different st_dev for different subvolumes within the
same filesystem and the numbers don't match with the maj:min
numbers from /proc/self/mountinfo (in the file is used only
devno for entire FS).
https://bugzilla.redhat.com/show_bug.cgi?id=711881
I've not got sandbox installed BTW.
Still need to look at this.
I have the same problem... not sure why :-(
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
6:44 a.m.
On 27.06.2011 11:28, Karel Zak wrote:
On Fri, Jun 24, 2011 at 12:15:52PM +0100, Pádraig Brady wrote:
>> I did a find_bind_mount() function as part of:
>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=ddf6fb86
Note, be careful with st_dev, because:
* after
mount --bind /mnt/A /mnt/A
/mnt/A has the same devno as /mnt/A/B, but /mnt/A is a mountpoint
* btrfs returns different st_dev for different subvolumes within the
same filesystem and the numbers don't match with the maj:min
numbers from /proc/self/mountinfo (in the file is used only
devno for entire FS).
https://bugzilla.redhat.com/show_bug.cgi?id=711881
> I've not got sandbox installed BTW.
> Still need to look at this.
I have the same problem... not sure why :-(
Karel
# rpm -qf /etc/rc.d/init.d/sandbox
policycoreutils-2.0.86-7.fc15.x86_64
and you might want
# chkconfig sandbox off
7:31 a.m.
Am 24.06.2011 09:43, schrieb Andreas Schwab:
Karel Zak <kzak(a)redhat.com> writes:
> The 'bind' flag is another way how to achieve that the filesystem is
> mounted on another place. Nothing other.
>
> # mount /dev/sdb1 /mnt/A
> # mount --bind /mnt/A /mnt/B
>
> is the same thing as:
>
> # mount /dev/sdb1 /mnt/A
> # mount /dev/sdb1 /mnt/B
There is a big difference between "mount --bind /mnt/A/B /mnt/B" and
"mount /dev/sdb1 /mnt/B"
the new dumb behavior BREAKS LOCATE, displays thousands of things
in "df", gives wrong error-messages for normal users if named
is running as chroot and should be REVERTED / FIXED
"locate" does find only things under "/Volumes/dune/www-servers"
# BIND-Mounts
/mnt/data/home /home none bind
/mnt/data/yum-cache /var/cache/yum none bind
/mnt/data/www/thelounge.net /Volumes/dune/www-servers none bind
/mnt/data/www/phpincludes /Volumes/dune/www-servers/phpincludes none bind
/dev/md2 is a RAID10
UUID=1abf071b-0c78-4b82-bb21-b3dfb269afa8 /mnt/data
/dev/md2 on /mnt/data type ext4
(rw,nosuid,noatime,nodiratime,stripe=256,inode_readahead_blks=64)
/dev/md2 on /home type ext4
(rw,nosuid,noatime,nodiratime,stripe=256,inode_readahead_blks=64)
/dev/md2 on /var/cache/yum type ext4
(rw,nosuid,noatime,nodiratime,stripe=256,inode_readahead_blks=64)
/dev/md2 on /Volumes/dune/www-servers type ext4
(rw,nosuid,noatime,nodiratime,stripe=256,inode_readahead_blks=64)
/dev/md2 on /Volumes/dune/www-servers/phpincludes type ext4
(rw,nosuid,noatime,nodiratime,stripe=256,inode_readahead_blks=64)
9:56 a.m.
On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
the new dumb behavior BREAKS LOCATE,
I did update mlocate to
handle the removal of /etc/mtab data in F15,
and it seems to work fine for me. Please file a proper bug report
with detailed steps to reproduce, and attach contents of
/proc/self/mountinfo.
Thanks,
Mirek
10:20 a.m.
Am 19.07.2011 16:56, schrieb Miloslav Trmaè:
On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> the new dumb behavior BREAKS LOCATE,
I did update mlocate to handle the removal of /etc/mtab data in F15,
and it seems to work fine for me. Please file a proper bug report
with detailed steps to reproduce, and attach contents of
/proc/self/mountinfo.
Thanks,
Mirek
https://bugzilla.redhat.com/show_bug.cgi?id=723279
but "locate" is one thing, the other one is that nobody is interested
in the following output where only 3 physical devices are mounted
and if a normal user calls "df" on a machine where "named"
is running there are error-messages which also result in
cron-mails
/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung
[root@rh:~]$ /bin/df -hT
Dateisystem Typ Größe Benut Verf Ben%% Eingehängt auf
rootfs rootfs 29G 8,2G 21G 29% /
udev devtmpfs 7,8G 4,0K 7,8G 1% /dev
tmpfs tmpfs 1,0G 52K 1,0G 1% /dev/shm
tmpfs tmpfs 7,9G 564K 7,9G 1% /run
/dev/md1 ext4 29G 8,2G 21G 29% /
tmpfs tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
tmpfs tmpfs 7,9G 564K 7,9G 1% /var/run
tmpfs tmpfs 7,9G 564K 7,9G 1% /var/lock
tmpfs tmpfs 5,0G 11M 5,0G 1% /var/tmp
tmpfs tmpfs 7,9G 0 7,9G 0% /media
tmpfs tmpfs 5,0G 12M 5,0G 1% /tmp
tmpfs tmpfs 150M 56K 150M 1% /var/www/sessiondata
/dev/md0 ext4 485M 49M 436M 11% /boot
/dev/md2 ext4 3,6T 506G 3,1T 14% /mnt/data
/dev/md2 ext4 3,6T 506G 3,1T 14% /home
/dev/md2 ext4 3,6T 506G 3,1T 14% /var/cache/yum
/dev/md2 ext4 3,6T 506G 3,1T 14% /Volumes/dune/www-servers
/dev/md2 ext4 3,6T 506G 3,1T 14% /Volumes/dune/www-servers/phpincludes
[root@rh:~]$
10:47 a.m.
On Tue, Jul 19, 2011 at 02:31:15PM +0200, Reindl Harald wrote:
Am 24.06.2011 09:43, schrieb Andreas Schwab:
> Karel Zak <kzak(a)redhat.com> writes:
>
>> The 'bind' flag is another way how to achieve that the filesystem is
>> mounted on another place. Nothing other.
>>
>> # mount /dev/sdb1 /mnt/A
>> # mount --bind /mnt/A /mnt/B
>>
>> is the same thing as:
>>
>> # mount /dev/sdb1 /mnt/A
>> # mount /dev/sdb1 /mnt/B
>
> There is a big difference between "mount --bind /mnt/A/B /mnt/B" and
> "mount /dev/sdb1 /mnt/B"
the new dumb behavior BREAKS LOCATE, displays thousands of things
in "df", gives wrong error-messages for normal users if named
is running as chroot and should be REVERTED / FIXED
FIXED, not reverted. The old behavior (mtab) had many other
problems...
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
5:11 p.m.
Am 20.07.2011 17:47, schrieb Karel Zak:
> the new dumb behavior BREAKS LOCATE, displays thousands of
things
> in "df", gives wrong error-messages for normal users if named
> is running as chroot and should be REVERTED / FIXED
FIXED, not reverted. The old behavior (mtab) had many other
problems...
sorry, but this does not intesrest endusers
FIX IT BEFORE replace for ages existing behavior or do not touch
it since the userbase have arranged with "many other problems" and
is running working systems
it is bad practice to break known behavior to fix some undefined
things - if a drop-in replacement is ready do it, if not it is
not a drop-in replacement
5:37 p.m.
Am 21.07.2011 00:18, schrieb Jeff Spaleta:
On Wed, Jul 20, 2011 at 2:11 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> sorry, but this does not intesrest endusers
please don't speak for me
if YOU like it that "df" is showing BIND-MOUNTS mixed up
with "permission denied" as nomal user for a lot of things
/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key: Keine Berechtigung
and spamming you inbox full if any cronjob is using "df" this is
fine for you - for MOST users "df" i used for "disk free" and
a bind-mount is NOT a disk
if you do not understand me:
if have no problem with WORKING replacements
but i have A HUGHE problem with things that should solve
problems nobody sees and brings a lot of new ones
6:19 p.m.
On Wed, Jul 20, 2011 at 2:37 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
if you do not understand me:
if have no problem with WORKING replacements
but i have A HUGHE problem with things that should solve
problems nobody sees and brings a lot of new ones
I have no problem with you speaking for yourself and expressing
frustration concerning a change in system behavior that impacts your
site specific cronjobs (I'm assuming shell scripts) that only you have
access to and are not shipped with the OS.
Hey I've been there. I've seen changes up and down the stack over the
years that caused failures in my personal shell and perl and python
scripts. The switch to udev in particular was a _fun_ learning
experience.
But you really need to reset your expectations, and develop a roll out
plan for your critical systems that anticipates unexpected changes in
behavior between OS releases.
-jef
6:23 p.m.
Am 21.07.2011 01:19, schrieb Jeff Spaleta:
But you really need to reset your expectations, and develop a roll
out
plan for your critical systems that anticipates unexpected changes in
behavior between OS releases.
where did i say anything about critical systems?
getting dumb cron-mails about "access denied" si not critical
i need NOT to "reset your expectations" because if i would
start to expect that it is mordern everywhere to replace working
things with new stuff which is NOT READY i should throw
away all my computers and search a job in a church
6:09 a.m.
On 07/20/2011 07:19 PM, Jeff Spaleta wrote:
On Wed, Jul 20, 2011 at 2:37 PM, Reindl
Harald<h.reindl(a)thelounge.net> wrote:
> if you do not understand me:
> if have no problem with WORKING replacements
> but i have A HUGHE problem with things that should solve
> problems nobody sees and brings a lot of new ones
I have no problem with you speaking for yourself and expressing
frustration concerning a change in system behavior that impacts your
site specific cronjobs (I'm assuming shell scripts) that only you have
access to and are not shipped with the OS.
Hey I've been there. I've seen changes up and down the stack over the
years that caused failures in my personal shell and perl and python
scripts. The switch to udev in particular was a _fun_ learning
experience.
But you really need to reset your expectations, and develop a roll out
plan for your critical systems that anticipates unexpected changes in
behavior between OS releases.
-jef
Well what benefit(s) does the new 'df' provide, is it worth all the
pain it brings?
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
7:09 a.m.
On 07/21/2011 07:09 AM, Steve Clark wrote:
Well what benefit(s) does the new 'df' provide, is it worth
all the pain
it brings?
I concur - the current df behavior is well .. goofy :-) - however this
may be tricky to fix in the new world - but should be fixed.
If this behavior is somehow desirable it would be preferable to make
it an option (like df --full or whatever) and make the default something
more sensible.
That said, it may be tricky in the new world;
where can you retrieve the info about a mount being a bind mount ?
How can you push the chrooted bind mounts into being less obtrusive (or
even optional, --show-chrooted-mounts)
/proc/mounts does not seem to distinguish bind mounts - so this may
have to be a kernel change and perhaps adding /proc/mounts/bind and
moving bind mounts 1 level down - this is not an area I know a lot about
however, so I'll leave this to the real experts.
1:51 p.m.
i need NOT to "reset your expectations" because if i would
start to expect that it is mordern everywhere to replace working
things with new stuff which is NOT READY i should throw
away all my computers and search a job in a church
Well you do what you feel is best for you. Working at a church can be
a rewarding experience, it may in fact help you develop a modicum of
empathy for other human beings in a way that living entirely through
electronic interaction cannot. I personally enjoy the time I volunteer
at my church
Anyways....
I've tried to point you to a modicum of historical context to give you
some breadcrumbs to follow to gain some perspective on how long people
(not just our distribution) have been struggling to resolve the
problems associated with relying on /etc/mtab. The reality is
"mounting" over the years in linux has seen a lot of changes in the
past 10 years with more and more kernel level fake filesystems that
are not attached to block devices show up. Many people have come to
understand that the best solution to all the problems is to rely on
the kernel's own knowledge of the mount points and to stop relying on
/etc/mstab as constructed artificially which can get out of sync with
the kernel's mounting information.
Some of the historic problems with relying on mtab has been encoded in
the mount manpage for awhile now(well before Fedora even considered
moving away from mtab) and I've personally pointed you to an upstream
list discussion concerning the problems relying on mtab dating back to
2007.
And to be clear Fedora isn't the first distribution to turn /etc/mtab
into a symlink. Hell, even _historic_ "linux from scratch" manual has
instructions that tell people to turn mtab into a symlink into
/proc/mounts.
http://archive.linuxfromscratch.org/lfs-museum/3.3/LFS-BOOK-3.3-HTML/inde...
That dates from 2003!!!!!! 2003!!!!!!! There have been people out
there, smart do-it-yourselfers working with LFS to build up their own
linux distro from sources who have been making the very change that is
frustrating you in 2003.
is there a problem with bind mount handling? Yes Was it caught in
testing? Seems like it wasn't. Does Fedora make any effort to test
bind mounts as part of organized pre-release QA? I'm not aware that we
do as our pre-release QA is quite narrowly scoped to ensure default
install configs as we don't have the resources to test all possible
configurations and command options. Did anyone who makes use of bind
mounts day to day in our userbase flag this ahead of release? I didn't
and I really can't lay the blame at the feet of developers for
shipping something "not ready" when I myself, who was actively testing
for breakage, didn't catch this.
And make no mistake the solution to bind mount handling and
representation moving forward will not depend on reverting to using
the constructed information in /etc/mtab and will have to depend on
the kernel's /proc/mounts. Tools that relied on mtab's understanding
of what a bind mount was (and it seems also the user option if I'm
reading the mount manpage correctly.) There has been years of
discussion on the issue of mtab versus /proc/mounts outside of our
specific distribution channels, and there is no getting around it that
the long term solution is to rely on the kernel's own representation
of mounts.
Though I wonder, since /etc/mtab is just a symlink. is the mount
command we ship still able to write to /etc/mtab if a local admin
decided to revert and make /etc/mtab a normal file again. Would our
mount command then update that file as per the legacy way? because
really that is exactly what you want to do on your system. If our
mount command will still attempt to write to /etc/mtab once its a real
file again, maybe things will work for you as expected.
-jef
You've only taken notice because its finally impacted you.
I think its ready enough to ship
I believe your definition of ready is incompatible with the release
model Fedora has chosen.
Your expectation is that new things work exactly the same and have
detailed backwards compatability. That's hasn't been true _ever_ in
any system I've had the pleasure of doing upgrades across major
releases.
windows, qnx,vms,mac os, linux.... tons and tons and tons of subtle
syntax channges in shipped functionality that resulted in breakage in
my "working" code on all those systems in different places at
different times.
2:58 p.m.
Am 21.07.2011 20:51, schrieb Jeff Spaleta:
is there a problem with bind mount handling? Yes Was it caught in
testing? Seems like it wasn't. Does Fedora make any effort to test
bind mounts as part of organized pre-release QA? I'm not aware that we
do as our pre-release QA is quite narrowly scoped to ensure default
install configs as we don't have the resources to test all possible
configurations and command options.
* bind-chroot-9.8.0-7.P4.fc15.x86_64 is a untouched fedora-package
* so fedora is ACTIVE creating bind-mounts
* /bin/df is a core utility and throws error
* /bin/mount is a core utility
* /bin/mount has NO information about a bind-mount
so if "/proc/mounts" is the kernel-layer why do it not
contain any hint what is a physical device and hwat
are bind-mounts? in other words: HOW get the information?
from my point of view i would have no idea how anybody should
fix /bin/df or /bin/mount if /proc/mounts has no informations
for the userland what is going on on the system
________________
here is nothing manually changed, this is DEFAULT-SETUP:
/bin/df with a running named:
/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung
/bin/mount | grep /dev/sda2
/dev/sda2 on / type ext4
(rw,noatime,nodiratime,nouser_xattr,noacl,commit=60,barrier=0,journal_async_commit,data=writeback,inode_readahead_blks=64)
/dev/sda2 on /var/named/chroot/etc/named type ext4
(rw,noatime,nodiratime,nouser_xattr,noacl,commit=60,barrier=0,journal_async_commit,data=writeback,inode_readahead_blks=64)
/dev/sda2 on /var/named/chroot/usr/lib64/bind type ext4
(rw,noatime,nodiratime,nouser_xattr,noacl,commit=60,barrier=0,journal_async_commit,data=writeback,inode_readahead_blks=64)
/dev/sda2 on /var/named/chroot/etc/named.iscdlv.key type ext4
(rw,noatime,nodiratime,nouser_xattr,noacl,commit=60,barrier=0,journal_async_commit,data=writeback,inode_readahead_blks=64)
/dev/sda2 on /var/named/chroot/etc/named.root.key type ext4
(rw,noatime,nodiratime,nouser_xattr,noacl,commit=60,barrier=0,journal_async_commit,data=writeback,inode_readahead_blks=64)
the permanently raising number of all sorts of "tmpfs" makes the output of
"df"
also not better readable and their size of 4GB on a machine with 8GB
pyhiscal memory makes my look also critical
udev devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs tmpfs 1,0G 204K 1,0G 1% /dev/shm
tmpfs tmpfs 4,0G 3,0M 4,0G 1% /run
tmpfs tmpfs 4,0G 0 4,0G 0% /sys/fs/cgroup
tmpfs tmpfs 4,0G 3,0M 4,0G 1% /var/lock
tmpfs tmpfs 4,0G 3,0M 4,0G 1% /var/run
tmpfs tmpfs 4,0G 0 4,0G 0% /media
3:45 p.m.
On Thu, Jul 21, 2011 at 10:51:59AM -0800, Jeff Spaleta wrote:
Though I wonder, since /etc/mtab is just a symlink. is the mount
command we ship still able to write to /etc/mtab if a local admin
decided to revert and make /etc/mtab a normal file again. Would our
mount command then update that file as per the legacy way?
Yes.
because
really that is exactly what you want to do on your system. If our
mount command will still attempt to write to /etc/mtab once its a real
file again, maybe things will work for you as expected.
No. systemd is not compatible with /etc/mtab
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
4:03 p.m.
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com> wrote:
> because
> really that is exactly what you want to do on your system. If our
> mount command will still attempt to write to /etc/mtab once its a real
> file again, maybe things will work for you as expected.
No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
If so, I believe a sufficiently motivated admin would be able to
figure out a way to manually update /etc/mtab from /proc/mounts if
they wanted to see systemd mounted items in their site specific mtab
they are trying to maintain. I don't think its impossible, I've
seen(created) crazier site specific admin hacks to keep backwards
compatibility on an as needed basis.
Just for completely I've done some more historical searches and I'm
seeing this argument between mtab and /proc/*/mounts going all the
way back to 2000. And in all of the historic discussion I've seen
relying on ./proc/*/mount has been the recommendation due to it being
a canonical representation of what the mount points actually are at
any given point in time.
Ten+ years of trying to live with two slightly different ways of
accounting for mountpoints, each with their own limitations is more
than enough time. While the bind mount situation we have now is
somewhat unfortunate in that we didn't catch it in time to be
proactive about it in F15, the fact that we've been living with this
divergence for ten years speaks volumes about the necessity to bite
the bullet and cut over to the /proc/*/mount information in a release
and triage accordingly as the breakage reports come it.
Do you have a complete listing somewhere of the info thekernel does
not encode into /proc/mounts that mount has traditionally encodes into
/etc/mtab that existing tools might be making use of? I'm pretty sure
based on everything I've read its not just bind mount info, but also
perhaps user or group info concerning who has permission to mount and
umount? Moving foward such a list would probably help mitigate
frustration and give admins a starting point to adjusting their site
specific configs.
-jef
4:04 p.m.
On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote:
On 07/21/2011 07:09 AM, Steve Clark wrote:
> Well what benefit(s) does the new 'df' provide, is it worth all the pain
> it brings?
>
I concur - the current df behavior is well .. goofy :-) - however this
may be tricky to fix in the new world - but should be fixed.
If this behavior is somehow desirable it would be preferable to make
it an option (like df --full or whatever) and make the default something
more sensible.
That said, it may be tricky in the new world;
where can you retrieve the info about a mount being a bind mount ?
How can you push the chrooted bind mounts into being less obtrusive (or
even optional, --show-chrooted-mounts)
/proc/mounts does not seem to distinguish bind mounts - so this may
have to be a kernel change and perhaps adding /proc/mounts/bind and
moving bind mounts 1 level down - this is not an area I know a lot about
however, so I'll leave this to the real experts.
I've already talked about it in this list... "bind" is operation, not
state of any mountpoint. Something like /proc/mounts/bind does not
make sense from kernel's point of view.
On Linux arbitrary filesystem could be mounted to more than one place
in VFS -- our userspace utils have to accept this fact...
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
4:09 p.m.
Am 21.07.2011 23:03, schrieb Jeff Spaleta:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com>
wrote:
>> because
>> really that is exactly what you want to do on your system. If our
>> mount command will still attempt to write to /etc/mtab once its a real
>> file again, maybe things will work for you as expected.
>
> No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
If so, I believe a sufficiently motivated admin would be able to
figure out a way to manually update /etc/mtab from /proc/mounts if
they wanted to see systemd mounted items in their site specific mtab
they are trying to maintain
about what are you speaking?
in /proc/mounts is no hint what are bind-mounts and what real devcies
this is the root of the hwole evil and why F15 is borked for
anything which will useful DISPLAY mounted devcies / df and so on
where did i say that i want maintain anything?
i want not see bind-mounts in df / mount output and no
warnings if a call "df" as normal user while named is running
not more and not less
4:15 p.m.
Am 21.07.2011 23:04, schrieb Karel Zak:
On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote:
> /proc/mounts does not seem to distinguish bind mounts - so this may
> have to be a kernel change and perhaps adding /proc/mounts/bind and
> moving bind mounts 1 level down - this is not an area I know a lot about
> however, so I'll leave this to the real experts.
I've already talked about it in this list... "bind" is operation, not
state of any mountpoint. Something like /proc/mounts/bind does not
make sense from kernel's point of view
sorry but if i get borked as suer with endless lists in "df"
and useless warnings while callign "df" the kernels point
of view does not matter for me!
you want a example of the real world - here it is:
* openssh / sftp
* chroot
Match User anyuser
ChrootDirectory /some/mepty/folder
* to use sftp as ftp-replacement you need bind-mounts
* create 20 empty folders
* every of this gets a bind-mount to the users webspaces
having 100 user with 5 subfolders in F15 means you
see a list with 500 entries calling "df" in F15
is this funny?
no it is not!
5:39 p.m.
On Thu, Jul 21, 2011 at 01:03:52PM -0800, Jeff Spaleta wrote:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com>
wrote:
>> because
>> really that is exactly what you want to do on your system. If our
>> mount command will still attempt to write to /etc/mtab once its a real
>> file again, maybe things will work for you as expected.
>
> No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
https://bugzilla.redhat.com/show_bug.cgi?id=666152
(and maybe some others reports)
Just for completely I've done some more historical searches and
I'm
seeing this argument between mtab and /proc/*/mounts going all the
way back to 2000. And in all of the historic discussion I've seen
relying on ./proc/*/mount has been the recommendation due to it being
a canonical representation of what the mount points actually are at
any given point in time.
Sure, /etc/mtab is broken by design, because
* Linux uses namespaces - you can unshare part of VFS with the rest of
the system
* only kernel has all information (typical problem is 'rw' in mtab
for read-only exported NFS)
* bind mounts are represented as /A -> /B dependence, reality is
/A -> device, /B -> device (and /A could be umounted, moved, ...)
* mount(2) is syscall, nobody is forced to use mount(8) util
* remount with options from mtab is problem if the options don't match
with real FS mount options used by kernel
* /etc/mtab~ lock is badly designed (proper fix means that you have to
fix *all* /sbin/mount.<type> helpers)
* /etc/mtab~ lock is performance problem (real issue for large
systems with autofs)
* use /etc for lock files and frequently updated files is really bad
idea (again, almost unfixable, real issue for read-only root fs)
* you need root permissions to update the file
Do you have a complete listing somewhere of the info thekernel does
not encode into /proc/mounts that mount has traditionally encodes into
/etc/mtab that existing tools might be making use of?
* userspace mount(8) specific mount options (e.g. user=, uhelper=),
libmount stores these options to the *private* /run/mount/utab file.
* NFS uses also libmount to store some extra information in userspace
I'm pretty sure based on everything I've read its not just
bind
mount info, but also perhaps user or group info concerning who has
permission to mount and umount? Moving foward such a list would
probably help mitigate frustration and give admins a starting point
to adjusting their site specific configs.
I know only about the problem with 'df'.
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
5:55 p.m.
Am 22.07.2011 00:39, schrieb Karel Zak:
* bind mounts are represented as /A -> /B dependence, reality is
/A -> device, /B -> device (and /A could be umounted, moved, ...)
this is not generally true
look below
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers
umount: /Volumes/dune/www-servers: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers/phpincludes
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers/phpincludes
mount: Einhängepunkt /Volumes/dune/www-servers/phpincludes existiert nicht
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers/phpincludes
[root@srv-rhsoft:~]$ cat /etc/fstab | grep www-servers
/mnt/data/www/thelounge.net /Volumes/dune/www-servers none bind
/mnt/data/www/phpincludes /Volumes/dune/www-servers/phpincludes none bind
so something, somewhere knows that one bind-mount is inside another
why this is configured this way?
because the /Volues/dune-Stuff is the physical structure of a
live-server and this way you can clone whole configurations
with whatever complexitiy on a development-machine with
a different physical disk-layout/structure
______________________________
another example of useing bind-mounts:
* 4x2 TB hard-disks
* RAID1 for /boot with 500 MB
* RAID10 for / with 30 GB
* RAID10 for data with the rest
another RADI for /home is wasting space
so /home lives on the data-disk and instead dealing with symlinks
or change /etc/passwd every part if the system can use /home
the same way as it would be a own partition and it is strictly
seperated from the operating system (damage, reinstall, whatever)
7:11 p.m.
On Thu, 21.07.11 13:03, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com>
wrote:
>> because
>> really that is exactly what you want to do on your system. If our
>> mount command will still attempt to write to /etc/mtab once its a real
>> file again, maybe things will work for you as expected.
>
> No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
systemd does not reset /etc/mtab on boot, and won't update /etc/mtab
with all previous mounts when / becomes writable, and will mount a few
selected mount points with raw syscalls, so that they /bin/mount nevers
sees them, so that it cannot update mtab accordingly.
So if your /etc/mtab is not a symlink you'll most likely see mounts from
a previous boot in it, and will miss a couple of mount points actually
mounted.
Lennart
--
Lennart Poettering - Red Hat, Inc.
2:31 a.m.
On Thu, 2011-07-21 at 23:15 +0200, Reindl Harald wrote:
Am 21.07.2011 23:04, schrieb Karel Zak:
> On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote:
>> /proc/mounts does not seem to distinguish bind mounts - so this may
>> have to be a kernel change and perhaps adding /proc/mounts/bind and
>> moving bind mounts 1 level down - this is not an area I know a lot about
>> however, so I'll leave this to the real experts.
>
> I've already talked about it in this list... "bind" is operation,
not
> state of any mountpoint. Something like /proc/mounts/bind does not
> make sense from kernel's point of view
sorry but if i get borked as suer with endless lists in "df"
and useless warnings while callign "df" the kernels point
of view does not matter for me!
you want a example of the real world - here it is:
* openssh / sftp
* chroot
Match User anyuser
ChrootDirectory /some/mepty/folder
* to use sftp as ftp-replacement you need bind-mounts
* create 20 empty folders
* every of this gets a bind-mount to the users webspaces
having 100 user with 5 subfolders in F15 means you
see a list with 500 entries calling "df" in F15
is this funny?
no it is not!
But it still does just mean that df must be fixed, not
that /proc/mounts/bind would make any sense or even if patched somehow
would be acceptable into the kernel.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
2:57 a.m.
Am 22.07.2011 09:31, schrieb Tomas Mraz:
On Thu, 2011-07-21 at 23:15 +0200, Reindl Harald wrote:
>
> Am 21.07.2011 23:04, schrieb Karel Zak:
>> On Thu, Jul 21, 2011 at 08:09:08AM -0400, Genes MailLists wrote:
>>> /proc/mounts does not seem to distinguish bind mounts - so this may
>>> have to be a kernel change and perhaps adding /proc/mounts/bind and
>>> moving bind mounts 1 level down - this is not an area I know a lot about
>>> however, so I'll leave this to the real experts.
>>
>> I've already talked about it in this list... "bind" is operation,
not
>> state of any mountpoint. Something like /proc/mounts/bind does not
>> make sense from kernel's point of view
>
> sorry but if i get borked as suer with endless lists in "df"
> and useless warnings while callign "df" the kernels point
> of view does not matter for me!
>
> you want a example of the real world - here it is:
>
> * openssh / sftp
> * chroot
>
> Match User anyuser
> ChrootDirectory /some/mepty/folder
>
> * to use sftp as ftp-replacement you need bind-mounts
> * create 20 empty folders
> * every of this gets a bind-mount to the users webspaces
>
> having 100 user with 5 subfolders in F15 means you
> see a list with 500 entries calling "df" in F15
>
> is this funny?
> no it is not!
But it still does just mean that df must be fixed, not
that /proc/mounts/bind would make any sense or even if patched somehow
would be acceptable into the kernel
who does it and will this happen this year or have we to
wait until Fedora 16 as for clean systemd-servcies where
QA forces even maintainers which having ready and from
users confirmed to remove them becuase the are not allow
should/must are nice words if nobody will do it
i can't becuase i am no c/c++ programmer and even if
i do not know until know WHERE the kernel spits out
the informationif anything is a bind-mount
3:24 a.m.
On Fri, Jul 22, 2011 at 12:55:54AM +0200, Reindl Harald wrote:
Am 22.07.2011 00:39, schrieb Karel Zak:
> * bind mounts are represented as /A -> /B dependence, reality is
> /A -> device, /B -> device (and /A could be umounted, moved, ...)
this is not generally true
# mount /dev/sdb1 /mnt/A
# mount --bind /mnt/A /mnt/B
# findmnt /dev/sdb1
TARGET SOURCE FSTYPE OPTIONS
/mnt/A /dev/sdb1 ext4 rw,relatime,barrier=1,stripe=32,data=ordered
/mnt/B /dev/sdb1 ext4 rw,relatime,barrier=1,stripe=32,data=ordered
# umount /mnt/A
# findmnt /dev/sdb1
TARGET SOURCE FSTYPE OPTIONS
/mnt/B /dev/sdb1 ext4 rw,relatime,barrier=1,stripe=32,data=ordered
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers
umount: /Volumes/dune/www-servers: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers/phpincludes
[root@srv-rhsoft:~]$ umount /Volumes/dune/www-servers
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers/phpincludes
mount: Einhängepunkt /Volumes/dune/www-servers/phpincludes existiert nicht
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers
[root@srv-rhsoft:~]$ mount /Volumes/dune/www-servers/phpincludes
[root@srv-rhsoft:~]$ cat /etc/fstab | grep www-servers
/mnt/data/www/thelounge.net /Volumes/dune/www-servers none bind
/mnt/data/www/phpincludes /Volumes/dune/www-servers/phpincludes none bind
so something, somewhere knows that one bind-mount is inside another
Oh... this is generic thing, you cannot umount any part of VFS if
there is active submount. This is not related to bind mounts.
# mount /dev/sdb1 /mnt/A
# mkdir /mnt/A/subdir
# mount /dev/sda1 /mnt/A/subdir
# umount /mnt/A
umount: /mnt/A: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
I hope that umount(8) in Fedora-17 will support --recursive option.
Karel
--
Karel Zak <kzak(a)redhat.com>
http://karelzak.blogspot.com
4655
days inactive
4688
days old
37 comments
12 participants
participants (12)
-
Andreas Schwab -
Genes MailLists -
Harald Hoyer -
Jef Spaleta -
Karel Zak -
Lennart Poettering -
Miloslav Trmač -
Nicholas Miell -
Pádraig Brady -
Reindl Harald -
Steve Clark -
Tomas Mraz