r268075 (MFV r267565) undone FreeBSD-specific changes

[Andriy Gapon]

Looking at the following commits:
 r268075 MFV r267565
 r269086
I think that the merge of the illumos change has overridden a FreeBSD-specific
change.  Here is a diff hunk to illustrate the point:

@@ -5198,7 +5205,13 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr)
        len = l2hdr->b_asize;
        cdata = zio_data_buf_alloc(len);
        csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr->b_tmp_cdata,
-           cdata, l2hdr->b_asize, (size_t)(1ULL <<
l2hdr->b_dev->l2ad_vdev->vdev_ashift));
+           cdata, l2hdr->b_asize);
+
+       rounded = P2ROUNDUP(csize, (size_t)SPA_MINBLOCKSIZE);
+       if (rounded > csize) {
+               bzero((char *)cdata + csize, rounded - csize);
+               csize = rounded;
+       }

        if (csize == 0) {

Note that we used to pass 1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift as
minblocksize, but now rounding up is done to a multiple of SPA_MINBLOCKSIZE.
minblocksize parameter to zio_compress_data was a FreeBSD-specific change
introduced in r254591 by Justin.
Passing 1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift as minblocksize in
l2arc_compress_buf was introduced by Steven in r256889.

So, it seems that r256889 is definitely undone now.  I have not checked if there
is any other fallout from removing minblocksize parameter of
zio_compress_data().  Hmm, in fact, it looks like zio_compress_data() in
zio_write_bp_init() has suffered the same fate: whereas previously minblocksize
was set metaslab_class_get_minblocksize(mc), now SPA_MINBLOCKSIZE is used for
rounding up.

I do not have any 4K drives around at the moment, so I can not test what the
practical consequences are.  I guess it's probably just worse performance on 4KB
physical / 512B logical disks because of RMW.  It would lead to I/O errors on
"pure" 4KB disks.

-- 
Andriy Gapon