Bug 15762 - Number of supported hard links is very low - breaks real world software
Number of supported hard links is very low - breaks real world software
Status: RESOLVED CODE_FIX
Product: File System
Classification: Unclassified
Component: btrfs
All Linux
: P1 normal
Assigned To: fs_btrfs@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-11 14:46 UTC by Sami Liedes
Modified: 2013-11-19 21:34 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.33.2
Tree: Mainline
Regression: No


Attachments

Description Sami Liedes 2010-04-11 14:46:44 UTC
While extracting a tar backup of a filesystem with a backuppc backup directory, I got errors telling me that the maximum number of hard links have been exceeded.

The backuppc directory structure is basically a pool of files named by their hashes, and the trees of the backed up directories with files as hard links to the pool.

The errors look like this:

tar: backuppc/pc/lap/2/f%2f/fhome/fsliedes/frec/fdbus-1.2.16/fdoc/fapi/fman/fman3dbus/fDBUS_MESSAGE_TYPE_INVALID.3dbus: Cannot hard link to `backuppc/cpool/4/4/d/44d6df5c255c9393cf647ecce2d1c8ba': Too many links

tar: backuppc/pc/lap/2/f%2f/fhome/fsliedes/frec/fdbus-1.2.16/fdoc/fapi/fman/fman3dbus/fDBUS_TYPE_SIGNATURE.3dbus: Cannot hard link to `backuppc/cpool/4/4/d/44d6df5c255c9393cf647ecce2d1c8ba': Too many links

tar: backuppc/pc/lap/2/f%2f/fhome/fsliedes/frec/fdbus-1.2.16/fdoc/fapi/fman/fman3dbus/fDBUS_ERROR_FILE_NOT_FOUND.3dbus: Cannot hard link to `backuppc/cpool/4/4/d/44d6df5c255c9393cf647ecce2d1c8ba': Too many links
Comment 1 Sami Liedes 2010-07-24 19:56:15 UTC
Hi,

As this bug apparently needs a disk format change (per other threads, see e.g. [1] and [2]), do you think it would be fixed before 1.0?

I'd imagine fixing it after the format is finalized would be even harder.

This is obviously a real-world test case. I've tried backuppc with several different filesystems to figure out what's the fastest one for the application, and btrfs just cannot handle the thing at all.


[1] http://comments.gmane.org/gmane.comp.file-systems.btrfs/4589
[2] http://thread.gmane.org/gmane.comp.file-systems.btrfs/3427
Comment 2 Alessandro Polverini 2010-07-27 05:57:20 UTC
I suffer the same problem: I needed to upgrade a filesystem used for backup (using backuppc) and I was unable to rsync the data on the new partition with the error:
rsync: link "xxxx" => yyyy failed: Too many links (31)
Comment 3 Alessandro Polverini 2010-07-27 06:19:52 UTC
I would like to add that 31 is such a ridiculous low number for maximum hard links and I'm very disappointed I can't use btrfs on a real world scenario on my first take on it.
Comment 4 Marco Aicardi 2010-07-27 07:16:31 UTC
I have the same problem too, while for me the number of links is sligthly higher (around 100 in my tests but it changed at every different test).

I've read on another thread that Zheng says that to fix this bug is necessary to make disk format changes.

The currenty hard-links limit is ridiculous, please fix it as long as btrfs is still in development!!!

Marco
Comment 5 Alan 2012-07-11 15:11:03 UTC
http://lwn.net/Articles/498226/
Comment 6 Alessandro Polverini 2012-07-11 15:56:50 UTC
That's really great news, thank for the link.

Hope to see it merged asap!
Comment 7 Zach Brown 2013-02-04 21:04:25 UTC
(In reply to comment #5)
> http://lwn.net/Articles/498226/

Mark's extended inode ref patches which increase the limit of hard link targets to an inode have been merged upstream and were first available in v3.7-rc1.

$ git log --oneline v3.7-rc1 fs/btrfs/ | grep "extended inode"
d24bec3 btrfs: extended inode ref iteration
f186373 btrfs: extended inode refs
Comment 8 Josef Bacik 2013-04-30 15:54:32 UTC
Closing, if this is still affecting you on a newer kernel please reopen.
Comment 9 Matthias Gies 2013-11-13 17:15:01 UTC
Please reopen this Bug.

It still affects me on a freshly installes Ubuntu 13.10 (GNU/Linux 3.11.0-13-generic x86_64).

I was trying to copy my backuppc pool from the previous ext4 filesystem to a disk with btrfs. The btrfs filesystem was freshly created with the mentioned kernel on a single 2TB disk.

I ran the following command:
rsync -caHAX --del /home-raid/backuppc/ /home-btrfs/

It exited with an error stating that there were too many hardlinks.
Comment 10 Alan 2013-11-13 17:48:28 UTC
Given the age of the bug I'd file a new one
Comment 11 David Sterba 2013-11-13 18:30:31 UTC
The extended refs are available for a long time, you have to turn them on during mkfs time or via btrfstune for an unmoutned filestem. It will be possible to turn them on with a mounted filesytem as well, there's a patchset pending.

mkfs -O extref
btrfstune -r

HTH, no need to reopen a new bug IMHO.
Comment 12 Matthias Gies 2013-11-14 07:09:42 UTC
Thanks for the hint, I'll try this one.

One question though: For what reason is this only optional and has to be triggered manually when creating the fs? Is there any downside, why one would not want extended refs enabled?
Comment 13 David Sterba 2013-11-14 12:23:34 UTC
The downside is backward compatibility with kernels < 3.7, the fs would not mount. But, it's 3.12 time and extrefs should be on by default.
Comment 14 David Sterba 2013-11-19 18:30:47 UTC
JFYI, patch to enable extrefs by default has landed in recent btrfs-progs.
Comment 15 Matthias Gies 2013-11-19 21:34:03 UTC
Thx for the info.

Enabling extrefs through btrfstune did the job. Backuppc is up and running. :D

Note You need to log in before you can comment on or make changes to this bug.