Date: Tue, 14 Jul 2020 22:26:01 -0400 From: Allan Jude <allanjude@freebsd.org> To: status-updates@freebsdfoundation.org, freebsd-fs <freebsd-fs@freebsd.org>, openzfs-developer <developer@open-zfs.org> Subject: Re: ZSTD Project Weekly Status Update Message-ID: <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> In-Reply-To: <bebcc0bb-7590-a04b-09ae-fa04e22d27dc@freebsd.org> References: <7b8842ad-d520-c575-22ee-2cd77244f2c6@freebsd.org> <708ec9f2-3c5c-6452-f6e6-bfb11a7f7eb2@freebsd.org> <bebcc0bb-7590-a04b-09ae-fa04e22d27dc@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --11rZcGtLSc3Dz7SCZJTTfFXDO0W11n4If Content-Type: multipart/mixed; boundary="66UlQ09ydSSLlog0hd3djPINvizOVW1Iw"; protected-headers="v1" From: Allan Jude <allanjude@freebsd.org> To: status-updates@freebsdfoundation.org, freebsd-fs <freebsd-fs@freebsd.org>, openzfs-developer <developer@open-zfs.org> Message-ID: <528ca743-7889-d1fd-ca95-a17cd430725b@freebsd.org> Subject: Re: ZSTD Project Weekly Status Update References: <7b8842ad-d520-c575-22ee-2cd77244f2c6@freebsd.org> <708ec9f2-3c5c-6452-f6e6-bfb11a7f7eb2@freebsd.org> <bebcc0bb-7590-a04b-09ae-fa04e22d27dc@freebsd.org> In-Reply-To: <bebcc0bb-7590-a04b-09ae-fa04e22d27dc@freebsd.org> --66UlQ09ydSSLlog0hd3djPINvizOVW1Iw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable In my continuing effort to complete the integration of ZSTD into OpenZFS, here is my fourth weekly status report: https://github.com/allanjude/zfs/commit/b0b1270d4e7835ecff413208301375e3d= e2a4153 - Create a new test case to make sure that the ZSTD header we write along with the data is correct. Verify that the physical size of the compressed data is less than the psize for the block pointer, and verify that the level matches. It uses a random level between 1 and 19 and then verifies with zdb that the block was compressed with that level. I am still working on a solution for setting the zstd feature flag to 'active' as soon as it is set, rather than only once a block is born. As well as fixing up compatibility around zfs send/recv with the embedded block points flag. This project is sponsored by the FreeBSD Foundation. On 2020-07-06 20:07, Allan Jude wrote: > In my continuing effort to complete the integration of ZSTD into > OpenZFS, here is my third weekly status report: >=20 > https://github.com/allanjude/zfs/commit/87bb538bdbc4bb8848ed5791b7b0de8= 4a026ebbe > - Completed the rewrite of the way the compression property is handled,= > moving away from the initial approach of storing the compression > property (enum zio_compress) and the level (uint64_t) separately. >=20 > Previously we exposed the list of compression algorithms and levels to > userland as the corresponding value from the enum in the lower 7 bits, > and the level in the remaining upper bits. Then, as part of the propert= y > GET and SET IOCTLs, we read the separate compression=3D and > compress_level=3D properties from the ZAP and returned the combined val= ue, > or split the combined value into those two separate properties. This > worked but caused a lot of headache around property inheritance. >=20 > Instead I've changed to doing the combine/split when reading/writing > from the dataset properties ZAP, via the compression_changed_cb() > function. So the properties ZAP contains the combined value (lower 7 > bits are the compression algorithm, as defined in the enum zio_compress= , > and the upper bits are the compression level). Elsewhere in ZFS we keep= > the two values separate (os_compress and os_complevel, and related > variables in all of the different parts of ZFS). >=20 > So now, inheritance of the property is handled correctly, and avoids > issues where a dataset with compression=3Dzstd-12, would say 'inherited= > from' a dataset with zstd at some other compression level (since both > actually just had compression=3Dzstd, but different compress_level=3D v= alues). >=20 >=20 > I have also further extended zdb to inspect the compression settings > when looking at an object: > https://github.com/allanjude/zfs/commit/3fef3c83b8ce90149110ed989bd9fd3= e289798e0 >=20 >=20 > I am still working on a solution for setting the zstd feature flag to > 'active' as soon as it is set, rather than only once a block is born. >=20 >=20 > Additionally, I am investigating how to best handle the fact that > embedded block pointers compressed with ZSTD will make 'zfs send -e' > streams backwards incompatible, without a way for the user to opt-out o= f > sending a stream that contains zstd compressed blocks that the receivin= g > side may not be able to read. The same can be said for 'zfs send -c' as= > well. I am open to ideas on how best to handle this. I have thought > about only sending ZSTD compressed blocks if the user specifies the -Z > (--zstd) flag, but this can lead to confusion where using -c without -Z= > would have to either error out, or send the ZSTD compressed blocks > uncompressed. >=20 >=20 > This project is sponsored by the FreeBSD Foundation. >=20 --=20 Allan Jude --66UlQ09ydSSLlog0hd3djPINvizOVW1Iw-- --11rZcGtLSc3Dz7SCZJTTfFXDO0W11n4If Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJfDmk9AAoJEBmVNT4SmAt+2/wP/RjlyPLcqL7mOplPW54P2uuN q6xgpWvk2odbZz6LOuG4qvo45+WU27rOJpDc1M/U8vs++kYHNfPt/CO9IjHkgMod o7FPPri+evJhnxpoIuK7c7wKfgUvyyzzxgT1MRfVjH0G3f/323Z22Bu5tXYPaN5d PnhCRQlcZyiaXwYneh1eTBFcXh1g3v0mUdm4o0gSrpAJCWCUDyx/6J5AKlZQRAnW kAUXOHrQ7vmA8uZeo6A4hkLiVKszLpTEeDuSxyTWpEXboUUyQYyTGvGAkc1xfLFO DGTMO66hjIfmdkmJAd4Pq8hx4GorX2gZWx21nWxpaqHdDnSj5fLCP55+zrL3FqEt E8IOUzxV9IbRW2IQAuPU2a2/BUEe7oOsaiIpDflb+qi0TGsn9rAGHvBLdKvwmK/f 1Gudt64woGHAVYd2ikCV0NdmwWxTw0r3YULbC7FhGRGMsWMBzWrh4QzkUNkcnVT1 MAV+NjewPXAKe+BIOEQJnxR3xT+/SCh0ZRkZ3dI9jgLPRpgyURzGDXkDajP9IB56 /3KV4vtpZwT3MplCpEKi9qpi7pfPqOCbAzZKFRt9tECnJ0Qv7cP0rb3JxtLEqhgv /Hopl/cjoum2EpLoSl60OlQnUfRStGRIRc/mp/5k/yYm9oR2EE+DUh4ojSGEhqZY eJyDc+7hMFnwh66N9K4U =ge0w -----END PGP SIGNATURE----- --11rZcGtLSc3Dz7SCZJTTfFXDO0W11n4If--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528ca743-7889-d1fd-ca95-a17cd430725b>