[pve-devel] zfs max record size tunable

[Wolf Noble <loiosh@wolfspaw.com>]

hi all!

i recently was playing with the ZOL module parameters, while tuning compression algos for my filer, and ran into a scenario that would be valuable knowledge here as well (i think)

not to go down the rabbit hole of why one might or might not want to do this too far, but TLDR: recordsize controls the chunk size of data handed to whatever compression algorithm is in use for that fs/vol, and it can increase the compression attained in some cases (and many relevant to pxm imo, but… tangent… :) )

if you increase the max record size on a host (default is 1Mb, max is 16mb)  via the kernel module tunable, it’s set ba k to default on reboot… now, vols/fs with larger recordsize than kernel module has configured is fine. no problems occur.

BUT. if you try to create a file system/vol with a larger recordsize than the module (currently) allows, zfs complains.

this is especially problematic when using zfs replication… if you try to send a fs/vol/snapshot which has a recordsize larger than target host supports, the send fails oddly.

i can see both sides of bug/feature mindset… but what i figured was relevant here contextually is that it might be worth adding some logic to evaluate the recordsize and the relevant module tuning and make some noise if the user tries to do something that won’t work and won’t be obvious why..

if this does not feel relevant here, mea culpa.

im really a fan of the way pxm works… y’all have done a really nice job stitching a lot of complicated things together well.

thank you for making my life as an admin of infra easier.
i really appreciate it.



UNRELATED FEEDBACK:

i would love it if there was a stream of “command line executions performed on your behalf in response to you driving the UI” that the user could observe (the ui is almost doing this already, just not quite as verbosely ((or durably)) as i had in mind… i was thinking of sort-of… “admin by osmosis mode” wherein a novice user could educate themselves by performing ops and observing the cmdline log file essentially…

the reason behind this stems from things like:

i need to take node X out for maintenance… i want to evacuate all the vms 

or 

i need to upgrade node X’s storage… evacuate all vms and destroy all ceph OSDs on it…

that’s not really easy to do via the existing UI, and seeing the exact cmds pxm is doing for me under the covers would help scripting something sane… 

alternatively, adding some entire-host scoped one-click UI features would help alleviate this scenario too… so… if that’s something in the works… great

❤️🤡🐺W


[= The contents of this message have been written, read, processed, erased, sorted, sniffed, compressed, rewritten, misspelled, overcompensated, lost, found, and most importantly delivered entirely with recycled electrons =]