On Monday 12 October 2009, Chris Mason wrote: > On Mon, Oct 12, 2009 at 02:17:11PM -0400, jim owens wrote: > > John Dong wrote: > > >I don't think that's a good counterargument for why this is not a bug. > > > > it is not a "bug". hard links are not a required feature of all > > filesystems nor is a defined large number required for those with > > hard links. > > > > >Can't think of any off the top of my head for Linux, but > > >definitely in OS X Time Machine can easily create 200+ hardlinks. > > > > so 311 is 50% than the app uses... plenty of growth. > > Just to clarify again, the max link count on btrfs is 2^32. The lower > limit is only in place on links to the same file in the same directory. > Hi Chris and all, I've made a quick test and managed to create many more links to the same file in the *same* directory on other filsystems: XFS can do at least 100000, probably more; Reiserfs did 64535; ext3 managed to do 32000; ext4 did 65000. While I agree it might be a bit stupid to create so many hardlinks to the same file on the same directory, this issue can be seen as one of "backward compatibility" with other widely used and established Linux filesystems. Despite it being stupid or not, the fact is that I've seen some crazy stuff along the years working with Unix, so people will expect this kind of things to *not* break when they switch from their old filesystems to shiny new btrfs. The fact being that this limit is way lower than on other filesystems (we're talking 2 orders of magnitude, at best!), I too suggest that the limit should be increased. Not being critical, it might be done when some other features require a format change but, nonetheless, should be done for the sake of avoiding breakage on existing systems. Best regards, and thanks for your hard work. Cláudio -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
