GNU bug report logs - #11844
du: continue processing after bind-mount induced dir-cycle

Previous Next

Package: coreutils;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Jim Meyering <jim <at> meyering.net>
To: bug-coreutils <at> gnu.org
Subject: du: continue processing after bind-mount induced dir-cycle
Date: Mon, 02 Jul 2012 19:04:20 +0200
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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11844 <at> debbugs.gnu.org
Subject: Re: bug#11844: du: continue processing after bind-mount induced
	dir-cycle
Date: Mon, 02 Jul 2012 16:49:14 -0700
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):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 11844 <at> debbugs.gnu.org
Subject: Re: bug#11844: du: continue processing after bind-mount induced
	dir-cycle
Date: Tue, 03 Jul 2012 10:33:24 +0200
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):

From: Jim Meyering <jim <at> meyering.net>
To: Ondrej Oprala <ooprala <at> redhat.com>
Cc: 11844-done <at> debbugs.gnu.org
Subject: Re: du bogus warning with bind mounts
Date: Tue, 21 Aug 2012 22:24:05 +0200
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.