Re: F15: ugly behavior of "df"

[Reindl Harald]

Am 22.07.2011 10:24, schrieb Karel Zak:

>  I hope that umount(8) in Fedora-17 will support --recursive option

well, more important is to fix it generally for F15
who is responsible for that?
where should a bugreport filed?



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

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 SOURCEFSTYPE 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 SOURCEFSTYPE 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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[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.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Lennart Poettering]

On Thu, 21.07.11 13:03, Jeff Spaleta (jspal...@gmail.com) wrote:

> On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak  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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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)





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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!




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

Am 21.07.2011 23:03, schrieb Jeff Spaleta:
> On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak  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






signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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  devtmpfs3,9G 0  3,9G   0% /dev
tmpfstmpfs1,0G  204K  1,0G   1% /dev/shm
tmpfstmpfs4,0G  3,0M  4,0G   1% /run
tmpfstmpfs4,0G 0  4,0G   0% /sys/fs/cgroup
tmpfstmpfs4,0G  3,0M  4,0G   1% /var/lock
tmpfstmpfs4,0G  3,0M  4,0G   1% /var/run
tmpfstmpfs4,0G 0  4,0G   0% /media



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

On Thu, Jul 21, 2011 at 01:03:52PM -0800, Jeff Spaleta wrote:
> On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak  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. 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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Jeff Spaleta]

On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Jeff Spaleta]

> 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/index.html

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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Genes MailLists]

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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Steve Clark]

On 07/20/2011 07:19 PM, Jeff Spaleta wrote:

On Wed, Jul 20, 2011 at 2:37 PM, Reindl Harald  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.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Jeff Spaleta]

On Wed, Jul 20, 2011 at 2:37 PM, Reindl Harald  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

Am 21.07.2011 00:18, schrieb Jeff Spaleta:
> On Wed, Jul 20, 2011 at 2:11 PM, Reindl Harald  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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Jeff Spaleta]

On Wed, Jul 20, 2011 at 2:11 PM, Reindl Harald  wrote:
> sorry, but this does not intesrest endusers

please don't speak for me.


-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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






signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

On Tue, Jul 19, 2011 at 02:31:15PM +0200, Reindl Harald wrote:
> 
> 
> Am 24.06.2011 09:43, schrieb Andreas Schwab:
> > Karel Zak  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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

Am 19.07.2011 16:56, schrieb Miloslav Trmaè:
> On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald  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   TypGröße Benut  Verf Ben%% Eingehängt auf
rootfs  rootfs 29G  8,2G   21G  29% /
udev  devtmpfs7,8G  4,0K  7,8G   1% /dev
tmpfstmpfs1,0G   52K  1,0G   1% /dev/shm
tmpfstmpfs7,9G  564K  7,9G   1% /run
/dev/md1  ext4 29G  8,2G   21G  29% /
tmpfstmpfs7,9G 0  7,9G   0% /sys/fs/cgroup
tmpfstmpfs7,9G  564K  7,9G   1% /var/run
tmpfstmpfs7,9G  564K  7,9G   1% /var/lock
tmpfstmpfs5,0G   11M  5,0G   1% /var/tmp
tmpfstmpfs7,9G 0  7,9G   0% /media
tmpfstmpfs5,0G   12M  5,0G   1% /tmp
tmpfstmpfs150M   56K  150M   1% /var/www/sessiondata
/dev/md0  ext4485M   49M  436M  11% /boot
/dev/md2  ext43,6T  506G  3,1T  14% /mnt/data
/dev/md2  ext43,6T  506G  3,1T  14% /home
/dev/md2  ext43,6T  506G  3,1T  14% /var/cache/yum
/dev/md2  ext43,6T  506G  3,1T  14% /Volumes/dune/www-servers
/dev/md2  ext43,6T  506G  3,1T  14% 
/Volumes/dune/www-servers/phpincludes
[root@rh:~]$




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Miloslav Trmač]

On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

Am 24.06.2011 09:43, schrieb Andreas Schwab:
> Karel Zak  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)





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Harald Hoyer]

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Pádraig Brady]

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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

On Fri, Jun 24, 2011 at 09:43:32AM +0200, Andreas Schwab wrote:
> Karel Zak  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  102297664892032   1% /mnt/A
  /dev/sdb1  102297664892032   1% /mnt/B

  $ findmnt /dev/sdb1
  TARGET SOURCEFSTYPE 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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Andreas Schwab]

Karel Zak  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, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Tomas Mraz]

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Pádraig Brady]

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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Karel Zak]

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  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Jeff Spaleta]

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  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       nice -n 19 run-parts /etc/cron.daily
> Datum: Mon, 20 Jun 2011 04:02:09 +0200 (CEST)
> Von: Cron Daemon 
> An: r...@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[Reindl Harald]

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   nice -n 19 run-parts /etc/cron.daily
Datum: Mon, 20 Jun 2011 04:02:09 +0200 (CEST)
Von: Cron Daemon 
An: r...@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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[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





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F15: ugly behavior of "df"

[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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F15: ugly behavior of "df"

[Reindl Harald]

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   TypGröße Benut  Verf Ben%% Eingehängt auf
rootfs  rootfs 29G  8,5G   21G  30% /
udev  devtmpfs7,8G  4,0K  7,8G   1% /dev
tmpfstmpfs1,0G 0  1,0G   0% /dev/shm
tmpfstmpfs7,9G  552K  7,9G   1% /run
/dev/md1  ext4 29G  8,5G   21G  30% /
tmpfstmpfs7,9G 0  7,9G   0% /sys/fs/cgroup
tmpfstmpfs7,9G  552K  7,9G   1% /var/run
tmpfstmpfs7,9G  552K  7,9G   1% /var/lock
tmpfstmpfs150M 0  150M   0% /var/www/sessiondata
tmpfstmpfs7,9G 0  7,9G   0% /media
/dev/md0  ext4485M   48M  437M  10% /boot
/dev/md2  ext43,6T  474G  3,1T  14% /mnt/data
/dev/md2  ext43,6T  474G  3,1T  14% /home
/dev/md2  ext43,6T  474G  3,1T  14% /Volumes/dune/www-servers
/dev/md2  ext43,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   TypGröße Benut  Verf Ben%% Eingehängt auf
rootfs  rootfs 29G  8,5G   21G  30% /
udev  devtmpfs7,8G  4,0K  7,8G   1% /dev
tmpfstmpfs1,0G 0  1,0G   0% /dev/shm
tmpfstmpfs7,9G  552K  7,9G   1% /run
/dev/md1  ext4 29G  8,5G   21G  30% /
tmpfstmpfs7,9G 0  7,9G   0% /sys/fs/cgroup
tmpfstmpfs7,9G  552K  7,9G   1% /var/run
tmpfstmpfs7,9G  552K  7,9G   1% /var/lock
tmpfstmpfs150M 0  150M   0% /var/www/sessiondata
tmpfstmpfs7,9G 0  7,9G   0% /media
/dev/md0  ext4485M   48M  437M  10% /boot
/dev/md2  ext43,6T  474G  3,1T  14% /mnt/data
/dev/md2  ext43,6T  474G  3,1T  14% /home
/dev/md2  ext43,6T  474G  3,1T  14% /Volumes/dune/www-servers
/dev/md2  ext43,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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel