Re: current status of zfs block_cloning on CURRENT?
On Tue, Apr 25, 2023 at 12:35:29AM -0700, Mark Millard wrote: > Warner Losh wrote on > Date: Tue, 25 Apr 2023 04:30:26 UTC : > > > On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: > > > > > Charlie Li wrote: > > > > Pete Wright wrote: > > > >> i've seen a few threads about the block_cloning feature causing data > > > >> corruption issues on CURRENT and have been keen to avoid enabling it > > > >> until the dust settles. i was under the impression that we either > > > >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool > > > >> upgrade" on a pool today it reported block_cloning was enabled. this > > > >> is on a system i rebuilt yesterday. > > > >> > > > > The dust has settled. > > > Barely... > > > >> i was hoping to get some clarity on the effect of having this feature > > > >> enabled, is this enough to trigger the data corruption bug or does > > > >> something on the zfs filesystem itself have to be enabled to trigger > > > >> this? > > > >> > > > > The initial problem with block_cloning [0][1] was fixed in commits > > > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > > > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > > > > problem [2][3] was fixed in commit > > > > 63ee747febbf024be0aace61161241b53245449e. All were committed between > > > > 15-17 April. > > > > > > > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > > > [1] https://github.com/openzfs/zfs/pull/14739 > > > > [2] https://github.com/openzfs/zfs/issues/14753 > > > > [3] https://github.com/openzfs/zfs/pull/14761 > > > > > > > Given mjg@'s thread reporting further crashes/panics, you may want to > > > keep the sysctl disabled if you upgraded the pool already. > > > > > > > I thought the plan was to keep it disabled until after 14. And even then, > > when it comes back in, it will be a new feature It should never be enabled. > > > https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html > > had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled > to allow the feature to be actually in use in 14, with a default that > would not have it in use. (Any cases of previously enable but not "in > use" here is wording simplification as I understand: special handling > if active from a previous pool upgrade and later activity so that > it cleans itself up, or something like that.) ah ok thanks for that insight. on my system where i did upgrade the pool i have this sysctl: $ sysctl vfs.zfs.bclone_enabled vfs.zfs.bclone_enabled: 0 which seems to jive with the statement above. thanks! -p -- Pete Wright p...@nomadlogic.org
Re: current status of zfs block_cloning on CURRENT?
On 4/24/23 21:30, Warner Losh wrote: On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: Charlie Li wrote: > Pete Wright wrote: >> i've seen a few threads about the block_cloning feature causing data >> corruption issues on CURRENT and have been keen to avoid enabling it >> until the dust settles. i was under the impression that we either >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool >> upgrade" on a pool today it reported block_cloning was enabled. this >> is on a system i rebuilt yesterday. >> > The dust has settled. Barely... >> i was hoping to get some clarity on the effect of having this feature >> enabled, is this enough to trigger the data corruption bug or does >> something on the zfs filesystem itself have to be enabled to trigger >> this? >> > The initial problem with block_cloning [0][1] was fixed in commits > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > problem [2][3] was fixed in commit > 63ee747febbf024be0aace61161241b53245449e. All were committed between > 15-17 April. > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > [1] https://github.com/openzfs/zfs/pull/14739 > [2] https://github.com/openzfs/zfs/issues/14753 > [3] https://github.com/openzfs/zfs/pull/14761 > Given mjg@'s thread reporting further crashes/panics, you may want to keep the sysctl disabled if you upgraded the pool already. I thought the plan was to keep it disabled until after 14. And even then, when it comes back in, it will be a new feature It should never be enabled. that was my reading of things too - thanks for the tip on disabling the sysctl knob Charlie, I'll do that. if this is really intended to be live i'd like to suggest we update zpool-features(7) at the least so others aren't caught by surprise. i'd propose a PR myself, but I'm not %100 clear on what its intent is. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: current status of zfs block_cloning on CURRENT?
Warner Losh wrote on Date: Tue, 25 Apr 2023 04:30:26 UTC : > On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: > > > Charlie Li wrote: > > > Pete Wright wrote: > > >> i've seen a few threads about the block_cloning feature causing data > > >> corruption issues on CURRENT and have been keen to avoid enabling it > > >> until the dust settles. i was under the impression that we either > > >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool > > >> upgrade" on a pool today it reported block_cloning was enabled. this > > >> is on a system i rebuilt yesterday. > > >> > > > The dust has settled. > > Barely... > > >> i was hoping to get some clarity on the effect of having this feature > > >> enabled, is this enough to trigger the data corruption bug or does > > >> something on the zfs filesystem itself have to be enabled to trigger > > >> this? > > >> > > > The initial problem with block_cloning [0][1] was fixed in commits > > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > > > problem [2][3] was fixed in commit > > > 63ee747febbf024be0aace61161241b53245449e. All were committed between > > > 15-17 April. > > > > > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > > [1] https://github.com/openzfs/zfs/pull/14739 > > > [2] https://github.com/openzfs/zfs/issues/14753 > > > [3] https://github.com/openzfs/zfs/pull/14761 > > > > > Given mjg@'s thread reporting further crashes/panics, you may want to > > keep the sysctl disabled if you upgraded the pool already. > > > > I thought the plan was to keep it disabled until after 14. And even then, > when it comes back in, it will be a new feature It should never be enabled. https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled to allow the feature to be actually in use in 14, with a default that would not have it in use. (Any cases of previously enable but not "in use" here is wording simplification as I understand: special handling if active from a previous pool upgrade and later activity so that it cleans itself up, or something like that.) Presuming no ability to have the feature actually in use ( so no ability to set vfs.zfs.bclone_enabled ), there also is then the question of reverting the block_cloning related code in the source vs. just blocking its (non-cleanup) activity. Also, there are folks that ended up with block_cloning enabled and a question is what is intended for 14.0-RELEASE for them: Require them to create a new pool that is not upgraded but has the content transfered? Allow them to use the pools in 14.0-RELELASE? I think all 3 of those are showing up in the exchanges that are happening. Sometimes it can be unclear for one or more of those what the status intended is --but they are not fully independent issues. (My wording is likely a simplification in various ways.) === Mark Millard marklmi at yahoo.com
Re: current status of zfs block_cloning on CURRENT?
On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: > Charlie Li wrote: > > Pete Wright wrote: > >> i've seen a few threads about the block_cloning feature causing data > >> corruption issues on CURRENT and have been keen to avoid enabling it > >> until the dust settles. i was under the impression that we either > >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool > >> upgrade" on a pool today it reported block_cloning was enabled. this > >> is on a system i rebuilt yesterday. > >> > > The dust has settled. > Barely... > >> i was hoping to get some clarity on the effect of having this feature > >> enabled, is this enough to trigger the data corruption bug or does > >> something on the zfs filesystem itself have to be enabled to trigger > >> this? > >> > > The initial problem with block_cloning [0][1] was fixed in commits > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > > problem [2][3] was fixed in commit > > 63ee747febbf024be0aace61161241b53245449e. All were committed between > > 15-17 April. > > > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > [1] https://github.com/openzfs/zfs/pull/14739 > > [2] https://github.com/openzfs/zfs/issues/14753 > > [3] https://github.com/openzfs/zfs/pull/14761 > > > Given mjg@'s thread reporting further crashes/panics, you may want to > keep the sysctl disabled if you upgraded the pool already. > I thought the plan was to keep it disabled until after 14. And even then, when it comes back in, it will be a new feature It should never be enabled. Warner
Re: current status of zfs block_cloning on CURRENT?
Charlie Li wrote: Pete Wright wrote: i've seen a few threads about the block_cloning feature causing data corruption issues on CURRENT and have been keen to avoid enabling it until the dust settles. i was under the impression that we either reverted or disabled block_cloning on CURRENT, but when i ran "zpool upgrade" on a pool today it reported block_cloning was enabled. this is on a system i rebuilt yesterday. The dust has settled. Barely... i was hoping to get some clarity on the effect of having this feature enabled, is this enough to trigger the data corruption bug or does something on the zfs filesystem itself have to be enabled to trigger this? The initial problem with block_cloning [0][1] was fixed in commits e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption problem [2][3] was fixed in commit 63ee747febbf024be0aace61161241b53245449e. All were committed between 15-17 April. [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 [1] https://github.com/openzfs/zfs/pull/14739 [2] https://github.com/openzfs/zfs/issues/14753 [3] https://github.com/openzfs/zfs/pull/14761 Given mjg@'s thread reporting further crashes/panics, you may want to keep the sysctl disabled if you upgraded the pool already. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: current status of zfs block_cloning on CURRENT?
Pete Wright wrote: i've seen a few threads about the block_cloning feature causing data corruption issues on CURRENT and have been keen to avoid enabling it until the dust settles. i was under the impression that we either reverted or disabled block_cloning on CURRENT, but when i ran "zpool upgrade" on a pool today it reported block_cloning was enabled. this is on a system i rebuilt yesterday. The dust has settled. i was hoping to get some clarity on the effect of having this feature enabled, is this enough to trigger the data corruption bug or does something on the zfs filesystem itself have to be enabled to trigger this? The initial problem with block_cloning [0][1] was fixed in commits e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption problem [2][3] was fixed in commit 63ee747febbf024be0aace61161241b53245449e. All were committed between 15-17 April. [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 [1] https://github.com/openzfs/zfs/pull/14739 [2] https://github.com/openzfs/zfs/issues/14753 [3] https://github.com/openzfs/zfs/pull/14761 -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
