From owner-freebsd-current@freebsd.org Tue Jan 26 00:58:07 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B78894F83A8 for ; Tue, 26 Jan 2021 00:58:07 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DPpHy2GPLz4Qqd; Tue, 26 Jan 2021 00:58:06 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x22e.google.com with SMTP id l12so15105497ljc.3; Mon, 25 Jan 2021 16:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1gqkkZp29Rqf00b3L2pHBxxnaLhoc7qAhygMfHf2BKQ=; b=CZo+3C4dUD7kRj80MnvMyel/SLar6lsgP7L0z/N7tkRZrqmhvUbhUQ8q4z2eF1u71p bgGzg+W+fsUj11bIcLxdGGn8YNHIEU6ICpwxWAS/FH2P7qDW7y7YydCnVjOe4pZ9JsuE OYrmCdK9AU00bR+Wa/NLBorReDKNb7Juk+UiA/Kq51mAIaJYQ1+RnYMy7u5KZ5Ev0uoi boIN2w/+9t0wfrn7JVGgCMdgcYSeLLycrt5FSnDZYXY4+dawA7ISbOIMF1AIO3sKckwQ vyq7NdQ8BH8JFrrRIrfvbtsm7wV5Zcdi9vqVSEPPIrmH8I9UFHZmes3n7CMpmnCMzOf9 FDrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1gqkkZp29Rqf00b3L2pHBxxnaLhoc7qAhygMfHf2BKQ=; b=EGRhykiAUXQ3oeTA4dQHWbUgxzVH6TPciJAQs3PW4BTGKWVg78Bv2pNU5wN2eT+wLD 0q6LgI/w9Asmqqm2g8RHxC0Xt9iBRdb6R5/aSVcRoLI4pYGSMzIzBd3UPrJ5Sopgor5q u8HsbX3iRb2+cwxadMeu5/UIfU96VUqjHot5sh31cTFd2zTme1zH4eSBzOHCQANnC0yX nCihnZEi8iaWXEyigXVZLfeLDnX+Xe+ZP04yuJg6KjGg+C6Zx0qgyU/qdpgsmdZMyBwN RzJnWfCDtr45W2MzapqkCDkhiEPU3gELRwmA/31siFMfspzvnklSNutp3Ohjg034fxnj txQg== X-Gm-Message-State: AOAM531clzv25hxPnjb5tCgWu2ivXQNGgvdWg56obgbkiGMDAN4muBfT n8smhU6Kwm0cowENRMgn357xt2HoDCc= X-Google-Smtp-Source: ABdhPJyiG98EFrXbQ6fLlYAZQLKnyUMZ1dmh05IgfIDUfIGyqZJJLyz/Pw+VUswDgm7KB9TiLkvzng== X-Received: by 2002:a2e:b4a7:: with SMTP id q7mr1482665ljm.391.1611622683857; Mon, 25 Jan 2021 16:58:03 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id z6sm2721689ljz.71.2021.01.25.16.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jan 2021 16:58:03 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Tue, 26 Jan 2021 03:58:01 +0300 To: "Poul-Henning Kamp" Cc: freebsd-current@freebsd.org, Kirk McKusick Subject: Re: fsck strange output Message-ID: <20210126035801.4cddd775@rimwks.local> In-Reply-To: <68616.1611607910@critter.freebsd.dk> References: <20210125232933.1ad108d1@rimwks.local> <68616.1611607910@critter.freebsd.dk> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DPpHy2GPLz4Qqd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CZo+3C4d; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::22e as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::22e:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::22e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22e:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 00:58:07 -0000 On Mon, 25 Jan 2021 20:51:50 +0000 "Poul-Henning Kamp" wrote: > > Disk is 100% alive, got same on other HW. > > A disk can be alive and still have individually unreadable sectors, > that is, IMO, the most common failure mode. > > Try: > recoverdisk -v /dev/whatever > > That will attempt to read all sectors on the disk. > This happen on 4 different systems, that: - based on Ryzen zen/zen+ - FreeBSD 13 2 systems have ECC that works and show no errors. At least on 12 and prev on read error - kernel show messages from drivers/geom. recoverdisk -v - show no error. I can reproduce this in VBox after disable "soft update journaling". (I hope that you will not require from me to check VBox HW too :) ) VBOx - no "CANNOT READ BLK": # tunefs -p /dev/ada0p2 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 2% tunefs: space to hold for metadata blocks: (-k) 1600 tunefs: optimization preference: (-o) space tunefs: volume label: (-L) VBOx - "CANNOT READ BLK" is present: # tunefs -p /dev/ada0p2 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 2% tunefs: space to hold for metadata blocks: (-k) 1600 tunefs: optimization preference: (-o) space tunefs: volume label: (-L) 5cc52631b3b88dfc36d8049dc8bece8573c5f9af [PATCH] Rewrite the disk I/O management system in fsck_ffs(8). Other Since this commit this issue started. I check: build system from prev commit - OK, build from this - "CANNOT READ BLK".