From nobody Mon Feb 26 15:06:29 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 4Tk3qP59yyz5BYfs for ; Mon, 26 Feb 2024 15:06:41 +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 4Tk3qN6BJwz4H8C for ; Mon, 26 Feb 2024 15:06:40 +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 41QF6Tm2000199; Tue, 27 Feb 2024 00:06:29 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 27 Feb 2024 00:06:29 +0900 From: Tomoaki AOKI To: Shigeki Yoshida Cc: users-jp@freebsd.org Subject: Re: =?UTF-8?B?MTMuMuOBrm1vdW5044GnSW52YWxpZCBmc3R5cGXjgavjgao=?= =?UTF-8?B?44KL?= Message-Id: <20240227000629.8e07ba77a784aeafa10b6a58@dec.sakura.ne.jp> In-Reply-To: References: 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: 4Tk3qN6BJwz4H8C 青木@名古屋です。 On Mon, 26 Feb 2024 18:15:37 +0900 Shigeki Yoshida wrote: > 吉田と申します。こちらに書くのは初めてな気がします。 > > 最近 12.4 から 13.2 にアップグレードしたのですが、2, 3 台目の HDD がマウントできなくなりました。 > > root@shige1:/etc # mount /dev/ada1s1e /mnt > mount: /dev/ada1s1e: Invalid fstype: Invalid argument > > この時 messages には以下のようなメッセージが10回くらい繰り返し書かれています。 > > Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_cpg (89) > != 1 > (1) > Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_spc > (4096) != > fs->fs_fpg * fs->fs_old_nspf (364544) > Feb 26 17:38:56 shige1 kernel: UFS1 superblock failed: fs->fs_old_ncyl > (38159) ! > = fs->fs_ncg (429) どうやらその昔、LBAによるディスク管理草創期に当たり前に 目にしたトラブルの臭いがプンプンすると思って計算してみる と、/usr/src/sys/ufs/ffs/fs.h [1]にある定義からして 　struct fs { （中略） u_int32_t fs_ncg; /* number of cylinder groups */ （中略） /* sizes determined by number of cylinder groups and their sizes */ int32_t fs_old_csaddr; /* blk addr of cyl grp summary area */ int32_t fs_cssize; /*　size of cyl grp summary area */ int32_t fs_cgsize; /* cylinder group size */ int32_t fs_spare2; /* old fs_ntrak */ int32_t fs_old_nsect; /* sectors per track */ int32_t fs_old_spc; /* sectors per cylinder */ int32_t fs_old_ncyl; /* cylinders in filesystem */ int32_t fs_old_cpg; /* cylinders per group */ u_int32_t fs_ipg; /* inodes per group */ int32_t fs_fpg; /* blocks per group * fs_frag */ （中略） }; となっているので、 superblockに記録されているシリンダグループ毎のシリンダ数89と シリンダ毎のセクタ数4096を乗じたものが 　89*4096=364544 で13.2が認識しているシリンダグループ毎のシリンダ数1とシリンダ毎の セクタ数364544を乗じたものと一致し、 superblockに記録されているファイルシステム内のシリンダ数38159を シリンダグループ毎のシリンダ数89で除した 　38159/89=428.75(小数点第2位以下四捨五入） をさらに四捨五入して整数化したシリンダグループ数が429で 13.2が認識しているシリンダグループ数429と一致しますので、 当時使っていたOS/2やDOSでIDEコントローラなりSCSIホストアダプタを 別メーカーのものに交換した際にさんざん目にしたコントローラがLBAから 偽装したCHSとOS側で換算したCHSの不一致でのアクセス不能の原因と ものの見事に一致してしまっています。 ＃ 極力旧来のCHSの規格に違反しないように換算するか単純明快に ＃ シリンダグループ内のシリンダ数を1にしてしまうかのポリシーの ＃ 違いです。　当時はIDEコントローラやSCSIホストアダプタの拡張 ＃ BIOS設定でOS側の期待するCHS値を矯正できればよし、できなければ ＃ 新しいコントローラに買い替えを強いられるという状況でした。 すみません。　解決策に辿り着けていませんが、問題切り分けの ご参考にでもなれば。 ところで、disklabelをお使いですが、現在はgpartをお使いになった方が 対応策を考えられる方がいくらかでも増えるのではないでしょうか？ [1] https://cgit.freebsd.org/src/tree/sys/ufs/ffs/fs.h?h=releng/13.2 > > この PC は 2.2.x のころ (1997年ころ) から稼働していて、1台目の HDD (/ や /usr があるやつ) は 2002 > 年頃に入れ替えてそのまま使っていて、2, 3 台目の HDD は 2007 年頃から使っています。 > > これまでは毎回の OS のアップグレードの際には何も問題なかったのですが、今回 13.2 にしたら mount で不具合が出てしまいました。 > > テストで別 PC に 12.4 と 13.2 を入れて、それぞれで 2, 3 台目の HDD をつないで mount してみたら、同じく 12.4 > では問題なく、13.2 では同様の不具合が出ました。 > > いずれも古い時代のパーティションやファイルシステムのままで (MBR & freebsd-ufs)、disklabel > の表示では以下のようになっています。 > > root@shige1:/var/log # disklabel ada0s1 ← 1 台目の HDD > # /dev/ada0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 1048576 0 4.2BSD 0 0 0 > b: 2097152 1048576 swap > c: 156344517 0 unused 0 0 # "raw" part, don't > edit > d: 153198789 3145728 4.2BSD 0 0 0 > > root@shige1:/var/log # disklabel ada1s1 ← 2 台目の HDD > # /dev/ada1s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 156296322 0 unused 0 0 # "raw" part, don't > edit > e: 156296322 0 4.2BSD 2048 16384 89 > > root@shige1:/var/log # disklabel ada2s1 ← 3 台目の HDD > # /dev/ada2s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 398283417 0 unused 0 0 # "raw" part, don't > edit > e: 398283417 0 4.2BSD 2048 16384 89 > > 1台目と2,3台目では fsize, bsize, bps/cpg > の値が違うのが原因なのかもしれませんが、こういう症状は初めてで、どうしたらいいのかがわかりません。 > > ネットで同じような不具合の情報がないか探してみたのですが、なかなか見つけられず、今回皆さんにおたずねする次第です。 > > 別 PC の 12.4 の方で中身は吸い出せるので、最悪はバックアップを取っておいて、元 PC > で新たにファイルシステムを作り直してそこに戻せばいいのでしょうが、かなり手間がかかるので何か解決策がないかと思っています。 > > よろしくお願いします。 > > -- > 吉田茂樹 (shige@iamas.ac.jp) -- 青木 知明 [Tomoaki AOKI]