* 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).