link count limited to 65536

[akorn]

Hi,

it's apparently impossible for an inode on zfsonlinux to have a link count higher than 65536 (attempting to create more results in EMLINK).

ZFS on Solaris appears to have no such limit. nlink_t should be at least u32 (or even u64), shouldn't it? Also, why 65536 and not 65535? I'm amazed.

Andras

Ps. I wonder what would happen if I were to try to mount an fs that has an inode with a higher link count than 64k+1 -- I'll try to find out.

[akorn]

FWIW, the FreeBSD implementation appears to suffer from a similar problem, except it doesn't return EMLINK after the 65536th link, just happily creating new hardlinks with the link count as shown by "ls -li" being 0. Fascinating.

[dajhorn]

The include/sys/zfs_vfsops.h file says:

/*
 * Allow a maximum number of links.  While ZFS does not internally limit
 * this most Linux filesystems do.  It's probably a good idea to limit
 * this to a large value until it is validated that this is safe.
 */
#define ZFS_LINK_MAX            65536

Internally, the link count is a 64-bit integer. Try changing the defined number to 2147483647, which is the maximum size of a 32-bit integer, recompile, and report whether it works.

[akorn]

Will do, thanks.

[behlendorf]

This is an arbitrary limit which is imposed by the zpl_link() function. Internally zfs has no limit but other Linux filesystems do have a limit around this value (ext234, xfs, reiser, udf), other filesystems such as jfs set it at 0xffffffff. Internally, the link count is stored on zfs as a 64-bit value so you could simply remove this limit. However, you may run in to some issues if you move the pool to FreeBSD of Solaris.

If you've got the time to test this I'd be interested in the results, we may be able to relax this limit. Or at the worst make it tunable if the end user is perhaps will to living with a slightly less portable pool.

/*      
 * Allow a maximum number of links.  While ZFS does not internally limit
 * this most Linux filesystems do.  It's probably a good idea to limit
 * this to a large value until it is validated that this is safe.
 */     
#define ZFS_LINK_MAX            65536

static int
zpl_link(struct dentry *old_dentry, struct inode *dir, struct dentry *dentry)
{
        ...
        if (ip->i_nlink >= ZFS_LINK_MAX)
                return -EMLINK;
}

[akorn]

xfs on Linux limits the link count to 2^32-1. (I actually have an inode with a link count of 892415, which I tried to rsync -H to zfsonlinux -- that's how I found the current limit.)

Solaris happily creates hundreds of thousands of links (tested by someone on #openindiana). The vfs layer of FreeBSD seems to be limited to u16, but it ignores this for ZFS (the link counter appears to wrap around but otherwise works as expected; also tested by someone on IRC).

I'll try to remove the ZFS_LINK_MAX check entirely and see what happens.

I'm using the latest .deb packaged version, FWIW.

[behlendorf]

Or better yet, just change ZFS_LINK_MAX to ((0x1 << 31) - 1U). After taking a look at the xfs code it appears it used to be limited to 65536 for the old style inodes and was then updated.

/*
 * The 32 bit link count in the inode theoretically maxes out at UINT_MAX.
 * Since the pathconf interface is signed, we use 2^31 - 1 instead.
 * The old inode format had a 16 bit link count, so its maximum is USHRT_MAX.
 */
#define XFS_MAXLINK             ((1U  31) - 1U)
#define XFS_MAXLINK_1           65535U

[akorn]

I tried this; no issues so far. I have files with link counts of several hundred thousand.