7

I'm trying to get the total size of what's stored in my home directory. To my surprise, it reports infinity after a few seconds:

/home/user $ du -sh .
Infinity

Huh? I'm pretty sure there are no recursive symlinks, but du should not follow symlinks anyways per default. I've also tried du -shx . so it won't cross device boundaries - with the same result.

I'm pretty sure I don't have infinite disk space or disk usage. ;-)

The target filesystem is a btrfs subvolume with no snapshots. rsync syncs this directory to an external disk just fine every night, it has no problem with this "infinity." However, du reports the same there.

Answers to comments:

There are no mount points within my home directory:

$ mount|grep home
/dev/sda3 on /home type btrfs (rw,relatime,compress=lzo,space_cache,autodefrag)

Using the full path instead of . as parameter shows the same behavior.

There are no files bigger than 200GB:

$ sudo find -size +$((200*1024*1024)) | wc -l
0
Improve this question
3
  • You don't maybe have a glusterfs mount point in a subdirectory? I've seen this happening with glusterfs mount points before
    – replay
    Jan 5, 2014 at 12:16
  • Weird. Do you get the same output with the full path? du -sh /home/hurikhan/.
    – terdon ♦
    Jan 5, 2014 at 12:21
  • 1
    amended my post to answer your questions
    – hurikhan77
    Jan 5, 2014 at 12:34

1 Answer 1

Reset to default
5

I found this bug report where a user had the same issue on a btrfs system. It turned out that the problem came from a specific .xml file whose size was incorrectly reported as 16 exabytes.

In the case of the person who filed the bug, the issue was a filesystem corruption and the problem was solved by moving all files to /tmp (which was a tmpfs), deleting the originals and then copying them back again:

mkdir /tmp/foo &&
cp -rv ~/* /tmp/foo &&
rm -r ~/* &&
mv /tmp/foo/* ~/
Improve this answer
8
  • I've updated my question: There are no such big files.
    – hurikhan77
    Jan 5, 2014 at 12:43
  • 1
    Thanks to your link to the bug report I've narrowed it down to the chromium cache directory using du -shx $(ls -a | tail -n +3) and following the "infinite" path. Interesting: diving into the .cache/chromium/Default/Cache the problem vanished although du -sh Cache reported infinity. I've removed the directory and the problem is gone now.
    – hurikhan77
    Jan 5, 2014 at 13:06
  • Marking your answer as accepted although it seems to be a different bug. At least it helped me tracking it down to the offending path.
    – hurikhan77
    Jan 5, 2014 at 13:07
  • 1
    @hurikhan77 sounds like the same issue. A random file giving problems. It would be interesting to know if moving the cache and moving it back would have fixed it.
    – terdon ♦
    Jan 5, 2014 at 13:08
  • Well, exploring the cache directory itself didn't show the behavior - so it was probably not a file. Maybe a directory node was damaged, I have no idea. After all: btrfs is still experimental and I had a few system crashes in the past and btrfs reports some non-fatal inode issues in btrfsck. But I think those are unrelated as the rsync backup shows the same behavior.
    – hurikhan77
    Jan 5, 2014 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.