Bug 15762
| Summary: | Number of supported hard links is very low - breaks real world software | ||
|---|---|---|---|
| Product: | File System | Reporter: | Sami Liedes (sami.liedes) |
| Component: | btrfs | Assignee: | fs_btrfs (fs_btrfs) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | alan, alex, dsterba, josef, ksee.zelgadis, marco, matthiasgies, zab |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.33.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Sami Liedes
2010-04-11 14:46:44 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 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) 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. 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 That's really great news, thank for the link. Hope to see it merged asap! (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 Closing, if this is still affecting you on a newer kernel please reopen. 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. Given the age of the bug I'd file a new one 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. 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? 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. JFYI, patch to enable extrefs by default has landed in recent btrfs-progs. Thx for the info. Enabling extrefs through btrfstune did the job. Backuppc is up and running. :D |