Date: Fri, 18 Nov 2022 01:38:47 +0000 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 Message-ID: <bug-267654-227-59752qiSCB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-267654-227@https.bugs.freebsd.org/bugzilla/> References: <bug-267654-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267654 --- Comment #8 from Li-Wen Hsu <lwhsu@FreeBSD.org> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-267654-227-59752qiSCB>