From nobody Mon Apr 24 17:15:10 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 4Q4sFr2Qkqz476Rc for ; Mon, 24 Apr 2023 17:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4sFq5TcSz4J0L; Mon, 24 Apr 2023 17:15:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=M0yrtyrC; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::c35 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-541f2112f82so1604062eaf.1; Mon, 24 Apr 2023 10:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682356511; x=1684948511; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bh3opW7OlofBJWUpCV5f4vMCQteiXVZJutkR99B8lPQ=; b=M0yrtyrCVH2dvHcwUONIjY2aeU8+mlgXkN2PJZboz/hYgqPYsxMPCFAMeOpkCQgrwg 2O79L4tuRahXslO/CTY9Fvl6GS2SnUfyksZRnJkY6taocjFCA2QVHVEVj1tGORWOIDDp 6eH7wzyfVl5CjSL5UO6KIF1KcCMcjMve/7G2MwiqthejP95LXTY8W57AGy2zD0C1iJ9g mpoZ4V2avzf+cGUqf3ni7vRfAgKDOTDYxgroBWzp8j3nK/l5wfR48t7cLnSDnO1GUuN3 QSLQugvYtO8BQEnP9teCGCwlTiyDltIwN5u1ybcAfwIteW33UhvfwxpEZvLz2OxgAiCq M7Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682356511; x=1684948511; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bh3opW7OlofBJWUpCV5f4vMCQteiXVZJutkR99B8lPQ=; b=cF4ZoJGUITdYgDuYOg1Lu43mjHROS/dKm5WJ733WSLwzI1FWkXBTLGX2y9Yugxp7he tbXCydwA5ChOKBU8X6/6NXqesUv3hzUSX/20a3P0srib2/jGSwYMG7WNrFAbmJiEI2L2 pO51gS/bjxIPvU4whry0R5tagTtBlaAAwdhXGT5BFkG5IN/h9OqbESDVXe/cQ46WSyyW GUatBRF7CNcqn7xb1zPQaGqTmVX4SMLWUyNHbG5CbKG0TXkJfCf2vIvXzXIEU9hIwpTN Ua+lBk/E0Y7zUe5foSuwBO+lFFHrEw31Hp+29za3CJrDfQEpvdtKawCMOJkF6uVnhgtT CNSg== X-Gm-Message-State: AAQBX9eveJLPcV9Z9PcIAXFNNXtQQ2WMPXn8evLeBKokgtYcPUTEi7Uu wwr5W8d8UHCcx+UFo+/IOHkcSmmmMk/9dvIy0i0tIYXS X-Google-Smtp-Source: AKy350az/6wvzNJtGt7kkIYGSck/8stfAlsG4UeRZVXgP8WLznIvQyEFG8F6z2QWtZRdhEJLBaPM/T+6/l7OkTolPXQ= X-Received: by 2002:a4a:a584:0:b0:546:d2db:ff9d with SMTP id d4-20020a4aa584000000b00546d2dbff9dmr5537085oom.1.1682356510719; Mon, 24 Apr 2023 10:15:10 -0700 (PDT) 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 Received: by 2002:ac9:588e:0:b0:4d4:94b:7266 with HTTP; Mon, 24 Apr 2023 10:15:10 -0700 (PDT) In-Reply-To: References: <48e02888-c49f-ab2b-fc2d-ad6db6f0e10b@dawidek.net> From: Mateusz Guzik Date: Mon, 24 Apr 2023 19:15:10 +0200 Message-ID: Subject: Re: another crash and going forward with zfs To: Pawel Jakub Dawidek Cc: freebsd-current@freebsd.org, Glen Barber Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c35:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Q4sFq5TcSz4J0L X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 4/18/23, Pawel Jakub Dawidek wrote: > 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. > Some people will zpool upgrade out of habit or whatever after moving to 14.0, which will then make them unable to go back to 13.x if woes show up. Woes don't even have to be zfs-related. This is a major release, one has to suspect there will be some breakage and it maybe the best way forward for some of the users will be to downgrade (e.g., with boot envinronments). As is they wont be able to do it if they zpool upgrade. If someone *does* zpool upgrade and there is further data corruption due to block cloning (which you really can't rule out given that the feature so far did not survive under load), telephone game is going to turn this into "14.0 corrupts data" and no amount of clarifying about an optional feature is going to help the press. If anything the real question is how come the feature got merged upstream, when: 1. FreeBSD CI for the project is offline 2. There is no Linux support 3. ... basic usage showed numerous bugs Should the feature get whipped into shape, it can be a 14.1 candidate. -- Mateusz Guzik