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
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.htmlHi Arnd, What do you mean by ''used all available inode space''? What did you do exactly? Thanks, Shyam -- 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 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 -- 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
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.
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 -- 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
> 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 -- 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