From nobody Mon Apr 17 22:38:47 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q0hmX3bXlz45JGt for ; Mon, 17 Apr 2023 22:38:52 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from mail.dawidek.net (mail.dawidek.net [94.130.64.56]) by mx1.freebsd.org (Postfix) with ESMTP id 4Q0hmW6YSGz415q; Mon, 17 Apr 2023 22:38:51 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.250.133] (c-73-241-172-196.hsd1.ca.comcast.net [73.241.172.196]) by mail.dawidek.net (Postfix) with ESMTPSA id 24F6E4F8F8; Tue, 18 Apr 2023 00:38:49 +0200 (CEST) Message-ID: Date: Mon, 17 Apr 2023 15:38:47 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: another crash and going forward with zfs Content-Language: en-US To: Mateusz Guzik Cc: freebsd-current@freebsd.org, Glen Barber References: <48e02888-c49f-ab2b-fc2d-ad6db6f0e10b@dawidek.net> From: Pawel Jakub Dawidek In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Q0hmW6YSGz415q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/18/23 05:14, Mateusz Guzik wrote: > On 4/17/23, Pawel Jakub Dawidek wrote: >> Correct me if I'm wrong, but from my understanding there were zero >> problems with block cloning when it wasn't in use or now disabled. >> >> The reason I've introduced vfs.zfs.bclone_enabled sysctl, was to exactly >> avoid mess like this and give us more time to sort all the problems out >> while making it easy for people to try it. >> >> If there is no plan to revert the whole import, I don't see what value >> removing just block cloning will bring if it is now disabled by default >> and didn't cause any problems when disabled. >> > > The feature definitely was not properly stress tested and what not and > trying to do it keeps running into panics. Given the complexity of the > feature I would expect there are many bug lurking, some of which > possibly related to the on disk format. Not having to deal with any of > this is can be arranged as described above and is imo the most > sensible route given the timeline for 14.0 Block cloning doesn't create, remove or modify any on-disk data until it is in use. Again, if we are not going to revert the whole merge, I see no point in reverting block cloning as until it is enabled, its code is not executed. This allow people who upgraded the pools to do nothing special and it will allow people to test it easily. -- Pawel Jakub Dawidek