* hard links
@ 2012-04-04 16:38 Arnd Hannemann
2012-04-04 19:33 ` Shyam Prasad N
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Hannemann @ 2012-04-04 16:38 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hard links
2012-04-04 16:38 hard links Arnd Hannemann
@ 2012-04-04 19:33 ` Shyam Prasad N
2012-04-04 19:39 ` Arnd Hannemann
0 siblings, 1 reply; 6+ messages in thread
From: Shyam Prasad N @ 2012-04-04 19:33 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-btrfs
On 04/04/2012 10:08 PM, Arnd Hannemann wrote:
> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hard links
2012-04-04 19:33 ` Shyam Prasad N
@ 2012-04-04 19:39 ` Arnd Hannemann
2012-04-04 19:53 ` Hugo Mills
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Hannemann @ 2012-04-04 19:39 UTC (permalink / raw)
To: nspmangalore; +Cc: linux-btrfs
Hi Shyam,
Am 04.04.2012 21:33, schrieb Shyam Prasad N:
> On 04/04/2012 10:08 PM, Arnd Hannemann wrote:
>> 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?
>>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hard links
2012-04-04 19:39 ` Arnd Hannemann
@ 2012-04-04 19:53 ` Hugo Mills
2012-04-04 20:12 ` Arnd Hannemann
0 siblings, 1 reply; 6+ messages in thread
From: Hugo Mills @ 2012-04-04 19:53 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: nspmangalore, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Wed, Apr 04, 2012 at 09:39:39PM +0200, Arnd Hannemann wrote:
> Am 04.04.2012 21:33, schrieb Shyam Prasad N:
> > On 04/04/2012 10:08 PM, Arnd Hannemann wrote:
> >> 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?
> >>
>
> > 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.
> 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.
--
=== 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.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hard links
2012-04-04 19:53 ` Hugo Mills
@ 2012-04-04 20:12 ` Arnd Hannemann
2012-04-04 20:57 ` Zach Brown
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Hannemann @ 2012-04-04 20:12 UTC (permalink / raw)
To: Hugo Mills, nspmangalore, linux-btrfs
Hi Hugo,
Am 04.04.2012 21:53, schrieb Hugo Mills:
> On Wed, Apr 04, 2012 at 09:39:39PM +0200, Arnd Hannemann wrote:
>> Am 04.04.2012 21:33, schrieb Shyam Prasad N:
>>> On 04/04/2012 10:08 PM, Arnd Hannemann wrote:
>>>> 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?
>>>>
>>
>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hard links
2012-04-04 20:12 ` Arnd Hannemann
@ 2012-04-04 20:57 ` Zach Brown
0 siblings, 0 replies; 6+ messages in thread
From: Zach Brown @ 2012-04-04 20:57 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: Hugo Mills, nspmangalore, linux-btrfs
> 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.
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-04 20:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-04 16:38 hard links Arnd Hannemann
2012-04-04 19:33 ` Shyam Prasad N
2012-04-04 19:39 ` Arnd Hannemann
2012-04-04 19:53 ` Hugo Mills
2012-04-04 20:12 ` Arnd Hannemann
2012-04-04 20:57 ` Zach Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).