From nobody Tue Feb 27 11:50:36 2024 X-Original-To: users-jp@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 4TkbR06nbPz5D1dM for ; Tue, 27 Feb 2024 11:50:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4TkbR03PMgz45mZ for ; Tue, 27 Feb 2024 11:50:52 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 41RBoaEJ077961; Tue, 27 Feb 2024 20:50:36 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 27 Feb 2024 20:50:36 +0900 From: Tomoaki AOKI To: Hiroki Sato Cc: shige@iamas.ac.jp, users-jp@freebsd.org Subject: Re: =?UTF-8?B?MTMuMuOBrm1vdW5044GnSW52YWxpZCBmc3R5cGXjgavjgao=?= =?UTF-8?B?44KL?= Message-Id: <20240227205036.419ecc33037c4a67a3a9d444@dec.sakura.ne.jp> In-Reply-To: <20240227.194235.1918132039378729941.hrs@FreeBSD.org> References: <20240227.194235.1918132039378729941.hrs@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion relevant to FreeBSD communities in Japan List-Archive: https://lists.freebsd.org/archives/freebsd-users-jp List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-users-jp@freebsd.org X-BeenThere: freebsd-users-jp@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4TkbR03PMgz45mZ 青木@名古屋です。 On Tue, 27 Feb 2024 19:42:35 +0900 (JST) Hiroki Sato wrote: > 佐藤です。 > > Shigeki Yoshida wrote > in : > > sh> 最近 12.4 から 13.2 にアップグレードしたのですが、2, 3 台目の HDD がマウントできなくなりました。 > sh> > sh> root@shige1:/etc # mount /dev/ada1s1e /mnt > sh> mount: /dev/ada1s1e: Invalid fstype: Invalid argument > sh> > sh> この時 messages には以下のようなメッセージが10回くらい繰り返し書かれています。 > sh> > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_cpg (89) > sh> != 1 > sh> (1) > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_spc > sh> (4096) != > sh> fs->fs_fpg * fs->fs_old_nspf (364544) > sh> Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_ncyl > sh> (38159) ! > sh> = fs->fs_ncg (429) > > 上記のメッセージは、UFS のスーパーブロックに書かれている情報に > 矛盾があることを示しています。13.2 以降では情報のチェックが厳しくなったため、 > 今までマウントできていたものがマウントできなくなることがあります。 > > 表示されている fs_old_cpg や fs_old_spc 等でマウントできなくなる症状は、 > 次の PR でも報告されています。 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264450#c21 > > FreeBSD の古いリリース（9 以前）で作成された UFS1 の一部に、 > 矛盾したパラメータが設定されているケースがあることが分かっています。 > > しかし、これらのパラメータは実際にはほぼ使われておらず、矛盾した値であっても > マウントして読み書きする使い方で支障が生じることはありません。 > PR にも経過が書かれていますが、値を厳密にチェックしても害のほうが大きいため、 > 15-CURRENT では 2/20 でチェックを緩和する変更が入りました。 > 今後の 13, 14 系にも、同じ変更が入ります。 > > ファイルシステムパラメータの値の矛盾を修正すれば良いのですが、 > 手動で直接バイナリデータを変更するくらいしか手段がありません。 > fsck 等のツールでパラメータを自動修正することはできませんし、 > カーネルが行なっているエラーチェックを回避する方法も、残念ながら用意されていません。 > 13, 14 系にチェック緩和の変更が反映されても、現状で厳しいチェックを > 行なっている 13.2R 等は、この問題に対応する Errata Notice が出るまで使えないままです。 > > パラメータに矛盾があるファイルシステムになってしまっていることは > 確かですから、面倒でも新しくファイルシステムを作成し、 > dump + restore 等で中身を移すのが将来的にも安心かと思います。 > > -- Hiroki やっぱりそうでしたか。　パーティションテーブルの問題ではなさそうなので fsckあたりを追っかけて何らかのOPTION等無いか探しかけて手に負えなくなって 断念していました。 件の修正はこれ[1]でしょうか？　stable/13へのMFCを経てのreleng/13.3への MFSは13.3-RELEASEに間に合うのでしょうか？ 自力でsrcから更新できて、このコミットを手動でcherrypickして問題ないなら 待たずに再構築してしまうのも手ですが。 ＃ 私の場合、git cherrypickを使わずcgitの当該コミットのページで ＃ author行から末尾のボーダー直前までをエディタにcopy&pasteした ＃ ものをパッチとして当て、次のsrcの更新時はgit pullの前にgit stash ＃ しておき、更新後git stash applyで戻しています。　MFCされたものが ＃ あればgit stashの前にpatch -Rで切り戻すのですが、たまに見落として ＃ conflictの手修正を迫られます。　ならローカルで独自のbranch切って ＃ 処理しろと言われそうですが、未だgitの仕組みを把握しきれていないので ＃ 手許のcommitログが手違いで本家と矛盾する状況の方が恐いのです。 ＃ n番号がズレたりしたら他の方との話が無茶苦茶になるので。 [1] https://cgit.freebsd.org/src/commit/?id=b241767f8ef38f9ca7c109fe2fccd11ccbfaa4f0 -- 青木 知明 [Tomoaki AOKI]