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
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
#
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
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
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
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
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
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
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak k...@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
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
On Thu, Jul 21, 2011 at 01:03:52PM -0800, Jeff Spaleta wrote:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak k...@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,
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
Am 21.07.2011 23:03, schrieb Jeff Spaleta:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak k...@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
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
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:
On Thu, 21.07.11 13:03, Jeff Spaleta (jspal...@gmail.com) wrote:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak k...@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
On Tue, Jul 19, 2011 at 02:31:15PM +0200, Reindl Harald wrote:
Am 24.06.2011 09:43, schrieb Andreas Schwab:
Karel Zak k...@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
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
On Wed, Jul 20, 2011 at 2:11 PM, Reindl Harald h.rei...@thelounge.net 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
Am 21.07.2011 00:18, schrieb Jeff Spaleta:
On Wed, Jul 20, 2011 at 2:11 PM, Reindl Harald h.rei...@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
On Wed, Jul 20, 2011 at 2:37 PM, Reindl Harald h.rei...@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
Am 24.06.2011 09:43, schrieb Andreas Schwab:
Karel Zak k...@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
On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald h.rei...@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
Am 19.07.2011 16:56, schrieb Miloslav Trmaè:
On Tue, Jul 19, 2011 at 2:31 PM, Reindl Harald h.rei...@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
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
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
Karel Zak k...@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
On Fri, Jun 24, 2011 at 09:43:32AM +0200, Andreas Schwab wrote:
Karel Zak k...@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
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
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
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
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
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
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,
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:~]$
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
36 matches
Mail list logo
