hard links
Hi,
today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an _equal length_ filename fails:
arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many links
Is this expected behavior?
There should be no reason to let this particular case fail?
Best regards,
Arnd
Quoted 12 lines · Arnd Hannemann
Hi,
today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an
_equallength_filename fails:arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many linksIs this expected behavior?
There should be no reason to let this particular case fail?
Quoted 6 lines
Best regards,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd,
What do you mean by 'used all available inode space'? What did you do exactly?
Thanks,
Shyam
Hi Shyam,
Am 04.04.2012 21:33, schrieb Shyam Prasad N:
Quoted 7 lines · Arnd Hannemann
Quoted 6 lines
Hi,
today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an
_equallength_filename fails:
Quoted 8 lines
Quoted 6 lines
arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many linksIs this expected behavior?
There should be no reason to let this particular case fail?What do you mean by 'used all available inode space'? What did you do exactly?
I created hard links of a file in the same directory until no additional one can be created.
Eg.:
touch a
for i in {1..1000}; do ln a $i; done;
Best regards
Arnd
Quoted 17 lines · Arnd Hannemann
Am 04.04.2012 21:33, schrieb Shyam Prasad N:
Quoted 15 lines · Arnd Hannemann
Quoted 6 lines
Hi,
today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an
_equallength_filename fails:Quoted 6 lines
arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many linksIs this expected behavior?
There should be no reason to let this particular case fail?What do you mean by 'used all available inode space'? What did you do exactly?
There's no inode limit specifically. The limit is on the number of
hardlinks to the same file stored in the same directory (and it's very small). This is a known limitation of btrfs. Someone's working on a fix (can't remember who, off-hand), but it's not been published yet.
Quoted 6 lines
I created hard links of a file in the same directory until no additional one can be created.
Eg.:
touch a
for i in {1..1000}; do ln a $i; done;
This is a little odd, but I don't really know what the internals of
mv try to do...
Hugo.
Signature · 4 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Nothing right in my left brain. Nothing left in ---
my right brain. Hi Hugo,
Am 04.04.2012 21:53, schrieb Hugo Mills:
Quoted 16 lines · Arnd Hannemann
Quoted 15 lines
Am 04.04.2012 21:33, schrieb Shyam Prasad N:
Quoted 13 lines · Arnd Hannemann
Quoted 12 lines
Hi,
today I experimented with hard links on btrfs and by this used all available inode space of a file. Interestingly if this happens even a rename of such an filename to an
_equallength_filename fails:arnd@kallisto:/mnt/btrfs/tmp$ mv a b mv: cannot move `a' to `b': Too many linksIs this expected behavior?
There should be no reason to let this particular case fail?
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
What do you mean by 'used all available inode space'? What did you do exactly?
There's no inode limit specifically. The limit is on the number of
hardlinks to the same file stored in the same directory (and it's very small). This is a known limitation of btrfs. Someone's working on a fix (can't remember who, off-hand), but it's not been published yet.
Sorry maybe I was unclear. I didn't want to say I used up all inodes. I wanted to express that I filled up the space of a particular inode. My understanding is that the limit on the number of hardlinks to the same file stored in the same directory, is, because the names of the hardlinks are stored within the same inode. As such the number of hardlinks is naturally limited by the size of the inode (and dependent on the length of the filenames). Correct?
It's not a big deal, but with my original posting I just tried to point out that btrfs fails an operation while the above constraint is not violated. The size needed to store the filename "a" is exactly the same as the size needed to store the filename "b".
Therefore, I would assume the operation mv "a" "b" to just work.
I hope I did clarify my point?
Best regards
Arnd
Quoted 6 lines
My understanding is that the limit on the number of hardlinks to the same file stored in the same directory, is, because the names of the hardlinks are stored within the same inode. As such the number of hardlinks is naturally limited by the size of the inode (and dependent on the length of the filenames). Correct?
Correct enough :). Yes, there is a limited amount of space associated with an inode that tracks hard links and the name of the link consumes that space.
The details are a little different. The backrefs to a given inode are stored in one item in the tree whose size is limited by the block size of the leaves in the tree.
Quoted 5 lines
It's not a big deal, but with my original posting I just tried to point out that btrfs fails an operation while the above constraint is not violated. The size needed to store the filename "a" is exactly the same as the size needed to store the filename "b". Therefore, I would assume the operation mv "a" "b" to just work.
Huh, indeed.
I'd hope that the current behaviour could be fixed. In flipping through the code it certainly looks like it adds the new backref for the new name before it unlinks the old name and removes the old backref.
- z