From nobody Mon Nov 27 15:50:39 2023 X-Original-To: freebsd-stable@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 4Sf96P3bk9z5349J for ; Mon, 27 Nov 2023 15:50:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 4Sf96N65Mjz4VfS for ; Mon, 27 Nov 2023 15:50:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-50aab20e828so6256940e87.2 for ; Mon, 27 Nov 2023 07:50:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701100251; x=1701705051; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pqSDyDuOHhNmmhW521XSOLAKDAHSrUmpg0dnU86RS0g=; b=XArQ/rwcx1rXiuHOzOdZW9dNnrFILZzisGLSLX0LCDRVlnHVdHjSom58jpPImS+tyZ EQsTLRmxWgAqiW/OmVqFnxjbjQD7Mw9bCLj/3GZ4S286+CewPincAQhICbHZaZYniPe5 QaMmBCx9K8eYgvZSm8Fr+x4pajT3F9RBoA2PkypBFglJ/1llMFY0NPex6h/1bhu2VqYE 8+YuiS8fYOKMaF5kWuLSsY0IOFOLdzNyLHeSrFWT+VjSNd/hjtUB8rDe8+FtWdP+8gC4 ncc0grqEGLfZOKyZrIQA/TtFal0dwKQTYPGt0+6s9mrKMhikhBpB/kzzrbG1IP3A13rq X15w== X-Gm-Message-State: AOJu0Yz8wfDRJMzMn43ceX+tBQpymPOUiInPl8m/z75GdVmrNZLXLmIL +MhIU+9T3sAcIQplcPURsFCIky1OGDM28K8Z71Tzzt0NC0s= X-Google-Smtp-Source: AGHT+IFn6ZhrvZ8YOVjH2IUfqaO1z99FzoeS3L9xGAJe5CqBk+Um+vqbA0mgsu/QR0Y75i85fyIF56O1/gNkjEAgZrw= X-Received: by 2002:a05:6512:31c4:b0:50b:acab:5452 with SMTP id j4-20020a05651231c400b0050bacab5452mr4657978lfe.41.1701100250661; Mon, 27 Nov 2023 07:50:50 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Mon, 27 Nov 2023 10:50:39 -0500 Message-ID: Subject: Potential ZFS data corruption issue To: freebsd-stable stable Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.62 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.995]; NEURAL_HAM_MEDIUM(-0.63)[-0.626]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.42:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.42:from]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4Sf96N65Mjz4VfS X-Spamd-Bar: -- Dear FreeBSD community, We want to bring your attention to a potential data corruption issue affecting multiple versions of OpenZFS. It was initially reported against OpenZFS 2.2.0 but also affects earlier and later versions. This issue can be reproduced with targeted effort but it has not been observed frequently in real-world scenarios. This issue is not related to block cloning, although it is possible that enabling block cloning increases the probability of encountering the issue. It is unclear if the issue is reproducible on the version of ZFS in FreeBSD 12.4. A short term workaround is available for FreeBSD 14.0 and 13.2 by setting the vfs.zfs.dmu_offset_next_sync sysctl to 0: # echo vfs.zfs.dmu_offset_next_sync=0 >> /etc/sysctl.conf # sysctl vfs.zfs.dmu_offset_next_sync=0 The workaround may result in inaccurate reporting of file holes in sparse files, reintroducing OpenZFS issue 6958[1]. See the ZFS(4) man page for more information on this setting. The workaround does not deterministically prevent the issue but does drastically reduce the likelihood of encountering it. For more information, see OpenZFS issue 15526[2] and OpenZFS pull request 15571[3]. FreeBSD bug report PR 275308[4] is open to track the FreeBSD erratum update which will bring in the fix, after it is committed to OpenZFS. Please check the FreeBSD PR regularly if you are looking for details on the timeline of the FreeBSD erratum update. We want to assure the FreeBSD community that we are actively monitoring the situation. Thank you for your understanding and continued support. [1] https://github.com/openzfs/zfs/issues/6958 [2] https://github.com/openzfs/zfs/issues/15526 [3] https://github.com/openzfs/zfs/pull/15571 [4] https://bugs.freebsd.org/275308