GNU bug report logs - #27739
Link counter of ls stops working at 65'000 hard links

Previous Next

Package: coreutils;

Reported by: Christoph Michelbach <michelbach94 <at> gmail.com>

Date: Mon, 17 Jul 2017 19:09:02 UTC

Severity: normal

Tags: notabug

Done: Eric Blake <eblake <at> redhat.com>

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 27739 in the body.
You can then email your comments to 27739 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#27739; Package coreutils. (Mon, 17 Jul 2017 19:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Michelbach <michelbach94 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 17 Jul 2017 19:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christoph Michelbach <michelbach94 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Link counter of ls stops working at 65'000 hard links
Date: Mon, 17 Jul 2017 20:58:42 +0200
The link counter of ls stops working if a directory exceeds being linked to
64'999 times.

You can replicate this by first creating a folder on an ext4 file system

    $ mkdir deleteMe

and then filling it with 64'997 additional directories.

    $ mkdir deleteMe/{1..64997}

At this point, ls still reports the correct number of hard links:

    $ ls -l
    total 1376
    drwxrwxr-x 64999 christoph christoph 1404928 Jul 17 20:46 deleteMe

But after creating another folder

    $ mkdir deleteMe/64998

, ll reports only 1 hard link to `deleteMe`:

    $ ls -l
    total 1376
    drwxrwxr-x 1 christoph christoph 1404928 Jul 17 20:46 deleteMe

Even after the latest hard link is removed, ls still reports only 1 hard link:

    $ rm -R deleteMe/64998
    $ ls -l
    total 1376
    drwxrwxr-x 1 christoph christoph 1404928 Jul 17 20:49 deleteMe

I neither understand why this happens, nor why it happens at such a weird
number. It would be obvious that there is a 16 bit counter running out of values
if it stopped working at at or after 65'535, but it stopping to work at 65'000
hard links seems weird.

I tested this on a 64 bit system running Linux 4.4.0-83 and on a 32 bit system
running Linux 4.1.18 with the exact same result.

-- 
Christoph Michelbach <michelbach94 <at> gmail.com>





Added tag(s) notabug. Request was from Eric Blake <eblake <at> redhat.com> to control <at> debbugs.gnu.org. (Mon, 17 Jul 2017 19:34:02 GMT) Full text and rfc822 format available.

Reply sent to Eric Blake <eblake <at> redhat.com>:
You have taken responsibility. (Mon, 17 Jul 2017 19:34:02 GMT) Full text and rfc822 format available.

Notification sent to Christoph Michelbach <michelbach94 <at> gmail.com>:
bug acknowledged by developer. (Mon, 17 Jul 2017 19:34:03 GMT) Full text and rfc822 format available.

Message #12 received at 27739-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Christoph Michelbach <michelbach94 <at> gmail.com>, 27739-done <at> debbugs.gnu.org
Subject: Re: bug#27739: Link counter of ls stops working at 65'000 hard links
Date: Mon, 17 Jul 2017 14:33:28 -0500
[Message part 1 (text/plain, inline)]
tag 27739 notabug
thanks

On 07/17/2017 01:58 PM, Christoph Michelbach wrote:
> The link counter of ls stops working if a directory exceeds being linked to
> 64'999 times.

ls is just reporting the value returned by stat() from the kernel; this
sounds like a kernel (or filesystem) bug.  To double-check, you should
also be able to use the stat(1) utility (instead of ls) to show the same
results.

Since we can't address it in userspace, I'm marking this as notabug from
the perspective of the coreutils database, but please feel free to reply
further with any results you get after reporting this to the right
kernel folks.

> I neither understand why this happens, nor why it happens at such a weird
> number. It would be obvious that there is a 16 bit counter running out of values
> if it stopped working at at or after 65'535, but it stopping to work at 65'000
> hard links seems weird.

Not the first time the kernel has done something weird.

> 
> I tested this on a 64 bit system running Linux 4.4.0-83 and on a 32 bit system
> running Linux 4.1.18 with the exact same result.

Your filesystem may also matter (not all filesystems are created equal).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#27739; Package coreutils. (Mon, 17 Jul 2017 19:43:02 GMT) Full text and rfc822 format available.

Message #15 received at 27739 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 27739 <at> debbugs.gnu.org, eblake <at> redhat.com, michelbach94 <at> gmail.com
Subject: Re: bug#27739: Link counter of ls stops working at 65'000 hard links
Date: Mon, 17 Jul 2017 12:42:25 -0700
On 07/17/2017 12:33 PM, Eric Blake wrote:
> feel free to reply  > further with any results you get after reporting this to the right > 
kernel folks.
I reproduced the bug on Fedora 26 x86-64, and filed a bug report here:

https://bugzilla.redhat.com/show_bug.cgi?id=1471967






bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 15 Aug 2017 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 23 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.