GNU bug report logs -
#11844
du: continue processing after bind-mount induced dir-cycle
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Mon, 2 Jul 2012 17:10:02 UTC
Severity: normal
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11844 in the body.
You can then email your comments to 11844 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#11844
; Package
coreutils
.
(Mon, 02 Jul 2012 17:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jim Meyering <jim <at> meyering.net>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Mon, 02 Jul 2012 17:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
du and other fts-using tools like rm, chmod, chown, chgrp, etc.
must detect directory cycles. Such cycles can indicate disk corruption
or (when following symlinks) a merely-ignorable cycle.
There is also the issue of how these tools treat a bind-mount-induced
directory cycle. One might hope that du's --one-file-system (-x) option
would help you avoid bind-mounted mount points, but that's not
what "one file system" means.
Two years ago, this was discussed here:
http://lists.gnu.org/archive/html/bug-coreutils/2010-01/msg00011.html
Recently, the issue came up again here:
http://bugzilla.redhat.com/836557
where I outlined a solution:
I have been considering a fix for this:
- read+stat all mount points at start-up
For now, I would do this in du.c, not fts.c, since fts clients
like rm, chmod, chown, etc. are much less likely to be used to
process mount points in a recursive traversal. Eventually, this
could migrate into fts.c, and be enabled via a new option. Once
ls is converted to use fts, we would have two clients using the
new feature. We'd probably want to ignore stat failure.
- put each dev/ino pair in a small hash table
- for each regular (i.e., not XDEV) dir encountered while traversing,
if its dev/ino is in the hash table, emit a diagnostic, arrange
not to process its entries, and arrange to exit nonzero.
If someone is interested in implementing this, I'd welcome a patch.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#11844
; Package
coreutils
.
(Mon, 02 Jul 2012 23:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 11844 <at> debbugs.gnu.org (full text, mbox):
On 07/02/2012 10:04 AM, Jim Meyering wrote:
> - read+stat all mount points at start-up
This sounds like it might have problems on hosts that have
lots of mount points, or where some mount points are remote.
I've been on many systems where statting a remote
mount point can take a long time, or even hang indefinitely.
The problem with remote mounts might be attacked by using
getmntent to find out which mount points are on the
current file system and can therefore be safely statted
(I haven't used getmntent enough to know whether this is feasible,
sorry).
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#11844
; Package
coreutils
.
(Tue, 03 Jul 2012 08:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 11844 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> On 07/02/2012 10:04 AM, Jim Meyering wrote:
>> - read+stat all mount points at start-up
>
> This sounds like it might have problems on hosts that have
> lots of mount points, or where some mount points are remote.
> I've been on many systems where statting a remote
> mount point can take a long time, or even hang indefinitely.
>
> The problem with remote mounts might be attacked by using
> getmntent to find out which mount points are on the
> current file system and can therefore be safely statted
> (I haven't used getmntent enough to know whether this is feasible,
> sorry).
Since with bind mounts we care only about non-remote mount points,
we can call read_file_system_list to get the list, and then stat only
those mount point directories for which !mount_entry.me_remote
(and probably && !...me_dummy)
Reply sent
to
Jim Meyering <jim <at> meyering.net>
:
You have taken responsibility.
(Tue, 21 Aug 2012 20:25:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jim Meyering <jim <at> meyering.net>
:
bug acknowledged by developer.
(Tue, 21 Aug 2012 20:25:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 11844-done <at> debbugs.gnu.org (full text, mbox):
Jim Meyering wrote:
> [Re: http://bugs.gnu.org/11844
> du: continue processing after bind-mount induced dir-cycle ]
>
> Ondrej Oprala wrote:
>> Sure, that looks great. Thanks for the help.
>
> I added this to the log:
>
> * THANKS.in: Update.
> This implements the proposal in http://bugs.gnu.org/11844.
> Originally reported in http://bugs.debian.org/563254 by Alan Jenkins
> and more recently as http://bugzilla.redhat.com/836557
>
> and pushed:
> http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=cf7e1b5b8fb53aef2a9103a32
The "du"-related part of this bug is now resolved,
so I'm marking it "done".
As I mentioned in the proposal, http://bugs.gnu.org/11844:
I have been considering a fix for this:
- read+stat all mount points at start-up
For now, I would do this in du.c, not fts.c, since fts clients
like rm, chmod, chown, etc. are much less likely to be used to
process mount points in a recursive traversal. Eventually, this
could migrate into fts.c, and be enabled via a new option. Once
ls is converted to use fts, we would have two clients using the
new feature.
Which means until ls.c is converted to use fts.c (a big job)
there's little point in trying to move this functionality into fts.c.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 19 Sep 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 194 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.