maximum zfs string property length bogusly checked
# zfs set richlowe:test=$(perl -e "print 'x'x8192") rpool/cores internal error: Arg list too long # pstack core fef046e5 _lwp_kill (1, 6, 80421b8, fee980de) + 15 fee980ea raise (6, 0, 8042208, fee6fa9a) + 22 fee6faba abort (8042238, fedf1000, 8042238, 80a8570, 80a8970, 400) + f2 fed72b3d zfs_verror (80a8548, 816, feddee20, 804226c) + d5 fed72ee4 zfs_standard_error_fmt (80a8548, 7, feddee20, 8043870, 8042298) + 200 fed72cd4 zfs_standard_error (80a8548, 7, 8043870, fed4ee14) + 28 fed4efda zfs_setprop_error (80a8548, ffffffff, 7, 8043870) + 1d2 fed4f475 zfs_prop_set (8089cc8, 8043ed0, 8043ede, fea83870) + 3c9 0805b6aa set_callback (8089cc8, 8043d88, 7, 0) + 16 08064285 zfs_for_each (1, 8043e1c, 0, 7, 0, 0) + 291 0805b86b zfs_do_set (3, 8043e14, 8079ccc, 801) + 14f 08063823 main (4, 8043e10, 8043e24, 8043dcc) + 283 080554cd _start (4, 8043ec8, 8043ecc, 8043ed0, 8045edf, 0) + 7d
It seems like both of these should have failed, and failed with a pleasing message.
I did not think to check what happens to a pool that has an over-long(?) user property.
Updated by Rich Lowe about 9 years ago
- Status changed from New to Closed
For what it's worth, in my testing we didn't actually (I don't think) go off-by-one and panic when crossing 8K
Also, the manual page needs to be updated, the limit on newer filesystems is 8K for string properties.
I was testing with a userproperty, though. Behaviour may differ for others?