From nobody Fri Nov 18 01:38:47 2022 X-Original-To: bugs@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 4NCzvq71M4z4hnbc for ; Fri, 18 Nov 2022 01:38:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NCzvq5xV5z3sXx for ; Fri, 18 Nov 2022 01:38:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668735527; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w+1GUhn7FnrE6PSEodwfe7cEcTGp2M6UM5VaxclZV/c=; b=bF4fgqrBmP84UDrrCMte9xctu6nnxESu3xzOQkxrgfVAtb2sBJstaY6XGYUJzetGbeYqJ2 u7tGDkCVICvgWK91xi3nYn8Gi0FJda2U5jw5CLC0XXZB+EnDCJg/L4IV8PbZES7vczw8B0 cpBRulIRFh9KRwOx47mwq7TuHWN4TeKks842U2dU8whwHoZrECQrwyQKftsxZvr4y7+taJ bKMzReriTlM1QgQVFTRgIVN3OGAnMfcTXFXqoCFMPIJ0L72bcp85tLZshDBzPvbep+/9l4 86Jy9FZZg/nbI9kH5++JrW8rhdRwVD9e7TxtssK6+IwSZ0Gw4bbSLI2g4tX5UA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668735527; a=rsa-sha256; cv=none; b=XoRdsZC9hTMkHJpeYdf85yAzlGnybvUJRpTAwI45yV2RNe96XBD7sBUet3tJcFdQTih97s ow0E5nqOm432x6zLqAaFgRJ4/c9hGJopA87k1aOqlSW40WaOLCHBPOhdcwbaejDf4cYMv4 2cti5IhLefzkS4dnMV3eL5FjJReFXgo5UT9pbu2IPoyVwnWm9ZcDNdrLMKo3oqFt+1uRth q7jHRcRNcARDa8mRKBDIDo4NIf5gmOdSahZ+e1j3h6eKjRynqxcy+rmno/WrlScpipiZly cbx4WJOZoVMj611mBLtg2ALIzQ7n6rVcV7UfmfGYOVfOVntpIupHH97jciTACw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4NCzvq4m1pz13LM for ; Fri, 18 Nov 2022 01:38:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 2AI1cl5f005276 for ; Fri, 18 Nov 2022 01:38:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2AI1clI2005275 for bugs@FreeBSD.org; Fri, 18 Nov 2022 01:38:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 267654] UFS "cylinder checksum failed" on temporary storage or data disk on arm64 vm in Azure Date: Fri, 18 Nov 2022 01:38:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lwhsu@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267654 --- Comment #8 from Li-Wen Hsu --- (In reply to Kirk McKusick from comment #7) > Is it possible to run fsck_ffs on the filesystem? If so, it will fix the = bad checksums and you should then be good to go. Thanks! Running fsck_ffs does fix the issue. I attach the log at https://gist.github.com/lwhsu/76e78a680df5f8107039c1a293ec2e42 > Can you run tunefs on the filesystem? If so, I could easily add an option= to disable cylinder group checksums. Yes we can run tunefs on this filesystem. What's more, all this disk is partitioned and formatted after boot. (refer to the above log) It's weird t= hat this filesystem is newly created by gpart and newfs but doesn't function li= ke da0 (OS disk) and mapped md(4) devices. Is it safe to just disable (checking?) cylinder group checksums? It seems still weird that we need users to manually turn off cylinder group checksums every time after running newfs. --=20 You are receiving this mail because: You are the assignee for the bug.=