From nobody Thu Sep 07 20:07:55 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 4RhVg86Z0Hz4sh32; Thu, 7 Sep 2023 20:08:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 4RhVg84j9Dz4R46; Thu, 7 Sep 2023 20:08:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-3ab3aa9ae33so983599b6e.2; Thu, 07 Sep 2023 13:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694117316; x=1694722116; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=qYhcbEsafebrUYIdq8f68T9hpIi/Uoo+JVfBQEkiuQw=; b=MIHw3rKlwGexVTimGLCebSIIRsUKQJ+tYV68V2W1lhGu3+hqBQ9ePiWL5FrdRJabla 2YRCjwv5GWZWMpzZX2ILTXI8uqSqI76DkjgSie2/EPgiEE4wuXuhCO65zbqD5fLB4wXX 0Andd73hMsi5lHM+ioLaxJ9uydIUSW91m8cs+laMZkpy5rDCV7PX9DK38AYF3zMPJDqa yz3H9hmrsu+6n6mJCHZTixROcLhsROayW8/6EH30fi7uIl3kz/38yTIyO3aqpiNVCV5g dFJRu3Ia1fqH7ED4g+ZWMLk4x8PO4dW8mUhGR/Te3sP1i1ncQ+TThmhrF2+Qc9egRK7I d6eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694117316; x=1694722116; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qYhcbEsafebrUYIdq8f68T9hpIi/Uoo+JVfBQEkiuQw=; b=QHfqVALxlfqh9L07XOIb21AwlBo6pUcpHJGiAhMU606kFs02TKvdVM7+KftreH3hni tbuNXlZxnhv/x8EsrSlF9bp3PNkksoh7SDOQ3Cztrebc0YrviBLQI2cvJkc3X5CUjJ1b o6mtKjjxxPzafiWp3vwHxVYtimsxkZPyADv1i5z5/zewlOT9YO6vJa21BpNICnSgeeqF 8nR4+0hiZ8m46DI+4ciwR65gzGmUbMjJJv4ptE21YruFz9h1VOUKXCf3GpFBV7j+G8om QR2sJU4KAVo937/pvEUch+srswzpzwhS0hG3cHfNMxNBGgvGWNoLh3qeLSFDGNbcGW7B wtYA== X-Gm-Message-State: AOJu0YwFZBg7p71ERpGQv8kCaV10jtYUIbhba9rZFAnZrwZbbQtWgTZs aOla51v5HyzIBqA+irlgkMhDRBVl/fX46A== X-Google-Smtp-Source: AGHT+IG1FSLvSjXyMr8r+ifF0ilm5Q34xaA1h2cXf3b6mEp/AgqG5Qbd7ZptnYpluEz6A6yC2qB3BQ== X-Received: by 2002:a05:6808:21a3:b0:3a1:dd99:8158 with SMTP id be35-20020a05680821a300b003a1dd998158mr826362oib.6.1694117315617; Thu, 07 Sep 2023 13:08:35 -0700 (PDT) Received: from [10.230.45.5] ([38.32.73.2]) by smtp.gmail.com with ESMTPSA id x188-20020a0deec5000000b00592236855cesm51245ywe.61.2023.09.07.13.08.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Sep 2023 13:08:35 -0700 (PDT) Message-ID: <4f4e2b68-57e0-a475-e2bd-1f2b8844ebfe@FreeBSD.org> Date: Thu, 7 Sep 2023 16:07:55 -0400 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 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Mark Millard , Glen Barber , Martin Matuska Cc: Current FreeBSD , FreeBSD-STABLE Mailing List , Pawel Jakub Dawidek References: <7CE2CAAF-8BB0-4422-B194-4A6B0A4BC12C@yahoo.com> <08B7E72B-78F1-4ACA-B09D-E8C34BCE2335@yahoo.com> <20230907184823.GC4090@FreeBSD.org> From: Alexander Motin Subject: Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4RhVg84j9Dz4R46 Thanks, Mark. On 07.09.2023 15:40, Mark Millard wrote: > On Sep 7, 2023, at 11:48, Glen Barber wrote: > >> On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: >>> When I next have time, should I retry based on a more recent >>> vintage of main that includes 969071be938c ? >> >> Yes, please, if you can. > > As stands, I rebooted that machine into my normal > enviroment, so the after-crash-with-dump-info > context is preserved. I'll presume lack of a need > to preserve that context unless I hear otherwise. > (But I'll work on this until later today.) > > Even my normal environment predates the commit in > question by a few commits. So I'll end up doing a > more general round of updates overall. > > Someone can let me know if there is a preference > for debug over non-debug for the next test run. It is not unknown when some bugs disappear once debugging is enabled due to different execution timings, but generally debug may to detect the problem closer to its origin instead of looking on random consequences. I am only starting to look on this report (unless Pawel or somebody beat me on it), and don't have additional requests yet, but if you can repeat the same with debug kernel (in-base ZFS's ZFS_DEBUG setting follows kernel's INVARIANTS), it may give us some additional information. > Looking at "git: 969071be938c - main", the relevant > part seems to be just (white space possibly not > preserved accurately): > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index 9fb5aee6a023..4e4161ef1a7f 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -3076,12 +3076,14 @@ vn_copy_file_range(struct vnode *invp, off_t *inoffp, struct vnode *outvp, > goto out; > > /* > - * If the two vnode are for the same file system, call > + * If the two vnodes are for the same file system type, call > * VOP_COPY_FILE_RANGE(), otherwise call vn_generic_copy_file_range() > - * which can handle copies across multiple file systems. > + * which can handle copies across multiple file system types. > */ > *lenp = len; > - if (invp->v_mount == outvp->v_mount) > + if (invp->v_mount == outvp->v_mount || > + strcmp(invp->v_mount->mnt_vfc->vfc_name, > + outvp->v_mount->mnt_vfc->vfc_name) == 0) > error = VOP_COPY_FILE_RANGE(invp, inoffp, outvp, outoffp, > lenp, flags, incred, outcred, fsize_td); > else > > That looks to call VOP_COPY_FILE_RANGE in more contexts and > vn_generic_copy_file_range in fewer. > > The backtrace I reported involves: VOP_COPY_FILE_RANGE > So it appears this change is unlikely to invalidate my > test result, although failure might happen sooner if > more VOP_COPY_FILE_RANGE calls happen with the newer code. Your logic is likely right, but if you have block cloning requests both within and between datasets, this patch may change the pattern. Though it is obviously not a fix for the issue. I responded to the commit email only because it makes no difference while vfs.zfs.bclone_enabled is 0. > That in turns means that someone may come up with some > other change for me to test by the time I get around to > setting up another test. Let me know if so. -- Alexander Motin