以前、FreeBSDではlongnameフィーチャーは使えないという話をした。

FreeBSDで255バイト超のファイル名でファイルは作れないとして、Linuxで作った256バイト以上のファイル名を持つZFSをFreeBSDにインポートした場合、どうなるのだろうか。インポートできなかったり、クラッシュしたり、データセットが壊れるなんてことは流石にないと思うが、分からんってのが正直なところ。サクッと試してみよう。

まずはLinux側でlongnameフィーチャーが有効なデータセットと、長いファイル名を持つファイルを作る。

環境はこんな感じ。Linuxと言いつつProxmox VEです。

# pveversion
pve-manager/9.1.4/5ac30304265fbd8e (running kernel: 6.17.4-2-pve)

# zpool version
zfs-2.3.4-pve1
zfs-kmod-2.3.4-pve1

# zpool status zlongname
  pool: zlongname
 state: ONLINE
config:

        NAME                      STATE     READ WRITE CKSUM
        zlongname                 ONLINE       0     0     0
          zvol/zvm/vm-100-disk-0  ONLINE       0     0     0

errors: No known data errors

データセットの文字コードはUTF-8にした。

# zfs create -o utf8only=on zlongname/longname

UTF-8の場合、日本語1文字はおおむね3～4バイトでエンコードされるので、255バイト=全角85文字となる。255バイトと256バイトのファイル名でファイルを作ってみる。

# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５'
# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a'
touch: cannot touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a': File name too long

256バイトの方はファイル名長すぎィと怒られた。longnameフィーチャーを有効にして再度試してみる。

# zfs set longname=on zlongname/longname
# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６ ７８９~7~１２３４５６７８９~8~１２３４５a'
# ls
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a

今度は当然ながら問題なく作成できた。このプールをFreeBSDに持っていく。

FreeBSD側は以下のような感じ。ashiftの警告が出てるけど本質じゃないのでスルーで。

$ freebsd-version -uk
14.3-RELEASE-p2
14.3-RELEASE-p2

$ zpool status zlongname
  pool: zlongname
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
config:

        NAME                                          STATE     READ WRITE CKSUM
        zlongname                                     ONLINE       0     0     0
          gptid/737d89da-f0e3-6c4d-a86d-426d41479aa8  ONLINE       0     0     0  block size: 512B configured, 4096B native

lsでは普通に255バイト超のファイル名も表示された。ちょっと意外。

$ ls /zlongname/longname/
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a

開こうとするとファイル名長すぎィと怒られた。

$ cat '/zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a'
cat: /zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a: File name too long

256バイトのファイル名でファイルを作ろうとしても、やっぱり長すぎィと怒られた。

$ touch '/zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５b'
touch: /zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５b: File name too long

というわけで、ZFSのlongnameフィーチャーを有効にし256バイト以上のファイル名があるデータセットをFreeBSDに持っていくと、ファイルの存在は確認できるが、ファイル操作は不可というのが現状のようだ。

AinexのAIF-12は、USBを計7ポートを増設可能なPCI Expressカードである。ポートの内訳は下記の通りで、USB 3.0とUSB 2.0の両方のピンヘッダを備えた、なかなかわかっとるじゃないか仕様となっている。

• 外部
  • USB 3.0 Type-A 2ポート
• 内部
  • USB 3.0 Type-A 1ポート
  • USB 3.0 ピンヘッダ（2ポート分）
  • USB 2.0 ピンヘッダ（2ポート分）

値段も3000円ちょいとお手軽価格。

採用チップの情報は公式サイトに書かれておらず、ネットを彷徨っても発見できず。商品画像からμPD系とGL3523が載ってそうな雰囲気はあるものの、不明瞭で確証が持てなかった。

諸事情で内部USB 2.0ピンヘッダが欲しく、ほかに選択肢もなかったのでダメもとで購入した画像がこれ。

ばっちりμPD720201とGL3523ですな。

パターンを追ってみると、Type-A 3ポートはμPD720201に直結、それ以外はGL3522のハブ経由の模様。まとめると以下のトポロジーになるっぽい。

uPD720201
├ 外部 3.0 Type-A
├ 外部 3.0 Type-A
├ 内部 3.0 Type-A
└ GL3522
　├ 内部 3.0 ピンヘッダ
　├ 内部 3.0 ピンヘッダ
　├ 内部 2.0 ピンヘッダ
　└ 内部 2.0 ピンヘッダ

OpenZFS 2.3.0で、個人的に待望のlongnameフィーチャーがリリースされた。

ZFSにおけるファイル名・ディレクトリ名（以後、まとめてファイル名と表記する）の最大長は、UNIX系の習わし(?)に沿って255 bytesとなっているが、longnameフィーチャーを有効にすると、その制約を打ち破って1023 bytesまで使えるようになる。単純に上限が固定的に引き上げられるといったものではなく、255 bytes超の名前があると機能がアクティブとなり、無くなれば非アクティブになるといった、動的な挙動となっているようだ。

この255バイトという伝統的な値はNAME_MAXマクロに由来し、FreeBSDの場合は/usr/src/sus/sys/syslimits.hで定義されている。厳密にいうと、ZFSでの制約は自身が定義している定数由来なのだが、NAME_MAXを意識した値であろうと思われる。なお、ここで注意が必要なのは、ファイルパスの最大長はPATH_MAXと別に定義されており、FreeBSDの場合は1023バイトとなっている。本記事で取り扱うのは、あくまでファイル名の最大長の方である。

現代的なUNIX系のファイルシステムでは、必ずしもこの制限に縛られることはないようだが、有名どころのFSは大抵255バイトが上限となっている。

255バイトもあって何が不満かと言われれば、ファイル名の文字エンコーディングにUTF-8を採用すると、最大文字数がだいぶ心許ないってこと。UTF-8の場合、日本語の文字は大半が3バイト、場合によっては4バイトで表現されるため、いわゆる全角換算で85～63文字に目減りしちゃうんですな。この問題はとりわけWindowsとファイル共有した時に顕在化しやすい。というのも、Windowsの主要FSの最大長はUTF-16で255文字¹⁾なので、つい長い名前つけちゃって、FreeBSD+Sambaな共有フォルダにコピーしようとして失敗、なんてことが年に数回起きる。これが1023バイトならUTF-8でも341～255文字となり、大変都合がいいわけですよ。

そんなわけで、longnameフィーチャーには大変期待していたのだが、どうもFreeBSD 14.3-RELEASE時点では事実上使えないようだ。

ZFS自体の255バイト制限はなくなったものの、FreeBSDのVFSレイヤーに255バイト制限が残っていて、この影響を受ける模様。実際、PortsからOpenZFS 2.3.0入れて試してみたが255バイト制限は突破できなかった…。SambaはNAME_MAX等の直接的な制限は受けないようだし、Linux+Sambaでは問題なく機能しているようだし、やはりFreeBSD側の制限の可能性が大。

VFSの根っこの部分っぽいし、改善されるのかなー？

正直、longnameは今すぐにも使いたい。というか、256バイト以上のファイル名を含むデータセットをFreeBSDに持ってきた時に変なことにならないんだろうか…？ついにLinuxに鞍替えするときが来たのか!?

こちらのページによれば、Western Digital Ultrastar DC SN640 U.2 NVMe SSDシリーズの初期ファームには、まれにSSDがタイムアウトし、機能不全を引き起こす可能性のあるバグがあるらしい。回復手段はSSDのフォーマットで、言わずもがなデータは失われることになる。あな恐ろし。

配布されている修正版ファームウェアはR1110021, R1410004で、手持ちのSN640はR1110012なので発生する可能性がありそう。というわけで更新してみる。

やり方は上記サイトに書いてある通り。Linux環境ならnvmeコマンドでSSDのFWをダウンロードし、適用し、マシンを再起動する。

nvme fw-download /dev/nvme0 --fw=FW.vpkg
nvme fw-commit /dev/nvme0 -a 1

こんな感じでR1110021に更新されていることが分かる。

# nvme list | grep WUS4
/dev/nvme2n1    /dev/ng2n1    A06F8XYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021
/dev/nvme1n1    /dev/ng1n1    A066EXYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021
/dev/nvme0n1    /dev/ng0n1    A0647XYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021

なお、このSN640たちは例によって中古で、いずれも2PB以上読み書きされている。データシート上の寿命は11210TBW（4kランダムライト時）であるから、S.M.A.R.T.が示すとおりまだまだ余裕がありそう。

CrystalDiskMarkとCrystalDiskInfoの結果は以下の通り。PCIeパススルーでVMで測定したものなので、値は参考程度に。

------------------------------------------------------------------------------ CrystalDiskMark 9.0.1 x64 (C) 2007-2025 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 2794.207 MB/s [ 2664.8 IOPS] < 2999.14 us> SEQ 128KiB (Q= 32, T= 1): 3284.428 MB/s [ 25058.2 IOPS] < 1272.22 us> RND 4KiB (Q= 32, T=16): 600.710 MB/s [ 146657.7 IOPS] < 615.42 us> RND 4KiB (Q= 1, T= 1): 38.750 MB/s [ 9460.4 IOPS] < 105.45 us> [Write] SEQ 1MiB (Q= 8, T= 1): 2009.656 MB/s [ 1916.6 IOPS] < 4162.21 us> SEQ 128KiB (Q= 32, T= 1): 2015.298 MB/s [ 15375.5 IOPS] < 2077.10 us> RND 4KiB (Q= 32, T=16): 523.224 MB/s [ 127740.2 IOPS] < 237.16 us> RND 4KiB (Q= 1, T= 1): 140.593 MB/s [ 34324.5 IOPS] < 28.90 us> Profile: Default Test: 1 GiB (x3) [E: 0% (0/7154GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2025/06/22 13:52:58 OS: Windows 10 Pro 21H2 [10.0 Build 19044] (x64) Comment: WD SN640 7.68TB (WUS4BB076D7P3E3) on VM

シーケンシャルは概ねデータシートどおりだが、ランダムのIOPSが1/2～1/3と振るわないのはパススルーの影響なのかしら？

• Western Digital SN640 firmware updates R1110021 and R1410004 - Thomas-Krenn-Wiki-en
• thomas-krenn/SN640-FW-Update

数年前のある日、突然Nextcloudのクライアントが「ファイルの更新日時が不正」というエラーを吐いてファイルの同期ができなくなった。確認してみると、大量のファイルの更新日時(mtime)が1970年1月1日になってるやんけえええええええ！！！！

どこをどうみてもUNIXエポックです、本当にありがとうございました。デスクトップクライアントv3.4.0でのやらかしらしい？

同期を再開させるだけなら、touchでmtimeを現在日時に更新してやればよい。でもワタクシはファイル探すときに結構mtime使うんですよね、なので極力元に戻したい。幸い、作成日時(ctime)とアクセス日時(atime)のいずれかは無事なようなので、それらからmtimeの復元を試みる。公式でmtime correction tool kitという、名前のとおりの復旧ツールが用意されているが、こちらはLinux環境向けでFreeBSDでそのまま使うことはできない²⁾ので、これらを参考に手動で直す。

まずは、mtimeが1970/1/1になったファイルを抽出する。Nextcloudのデータフォルダは/mnt/nextcloud/dataとする。

findで「mtimeがUNIX時間の0である」と指定する方法がわからなかったので、「mtimeが40年前（2024年9月時点で1984年9月）より新しい」とした。単位は分であることに注意。で、該当するファイルの作成日時(birthtime)、作成日時(ctime)、更新日時(mtime), 最終アクセス日時(atime), ファイル名をファイルに書き出す。

# cd /mnt/nextcloud/data
# find . -mmin +21024000 -print0 | xargs -0 stat -f "%SB,%Sc,%Sm,%Sa,\"%N\"" -t "%s" > /tmp/epoch_time_file_list.csv

CSVをExcelで開き、諸々整形する。UNIX時間→Excel日時の変換数式は=(UNIX時間のセル+32400)/86400+25569で、セル書式をyyyy/mm/dd hh:mm:ssとすればよい。

とりあえず、各種タイムスタンプの中で最も新しい値をmtimeとして採用することにした。どうもNextcloudに突っ込んだ時点でmtime以外の情報は消失しているような気がする³⁾ので、こんなに頑張っても仕方ないと思いつつ、現在日時にするのはなんか嫌なので。

Excelからタイムスタンプ,ファイルパスのCSVを書き出し、以下のようなスクリプトに食わせればmtime, atimeがそれなりに復旧できる。

#!/usr/local/bin/bash

while IFS=, read datetime file
do
    touch -t $datetime "$file"
done < $1

それにしてもだなー、Nextcloudがmtimeしか保持してないっぽいのは結構衝撃。デバイス間の同期が楽で、意識することなく履歴付きバックアップにもなるなーと思って建てたけど、自分の用途には合わないかなぁ…便利なんだけどさー。zipなんかも更新日時しか保持しないし、アクセス日時はともかく、みんな作成日時とか気にしないのかしら…？

他のクラウドストレージはどうなんだろう、と気になってたらDropboxとGoogle Driveを調べてる方がいた。子曰く、どちらも基本的に同期クライアントを使った場合は更新日時は保持されるとのこと。デスヨネー。

結局、ファイル属性含めて保持しておきたいなら、ローカルストレージかSMBでせっせとバックアップするしかないのかねぇ。理想の形はMacのTimeMachine。設定したら知らぬ間にバックアップがとられてて、イザって時に大助かりというやつ。WindowsもVSS（復元ポイント）で似たようなことはできるが、如何せんUIがダメダメすぎる。TimeMachine並にイケててリッチにしろとは言わないが、ファイル/フォルダのプロパティに押し込まれててアクセス性が最悪すぎる。

かといってOneDriveは仕様が素晴らしすぎて全く使う気になれないし。

Windowsのバックアップソリューション、もっとなんとかならんものか。

• Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server - 📱 Desktop & mobile clients - Nextcloud community
• GitHub - nextcloud-gmbh/mtime_fixer_tool_kit: Tool kit to fix the mtime issue on the server state
• 多分すごく分かり易い！UNIXTIMEをエクセルで扱う方法 - まるノート
• 【備忘録】ファイルの更新日時を維持したまま、オンラインストレージに預けたり取り出したりしたい！｜犬川さと

作業メモ。

コメント元のIPアドレスをコメント数に並べ替え。

SELECT COUNT(ip), ip FROM comments GROUP BY ip ORDER BY count(ip);

IPアドレスと一致するコメントを削除。

DELETE FROM comments WHERE ip='x.y.z.w';

[url=httpを含むコメントを削除。

DELETE FROM comments WHERE text LIKE '%[url=http%';

<a href=“httpを含むコメントを削除。

DELETE FROM comments WHERE text LIKE '%<a href="http%';

2024年5月30日、口唇ヘルペスが再びやってきた。5年半ぶり、5度目の来訪である。前回は2019年4月16日で、更に前の発症歴と照らすと4～5年周期で来るようだ。

午前中あたりから上口唇白唇部に違和感があり、午後から罹ったことは分かるであろうチクチク感と経度の水膨れが見られ、再発を確信。すぐさまドラッグストアに駆け込んで、今回はアラセナSクリームを買ってみた。

塗り始めて3日目だが、何となくヘルペシアより効きが良いような…？まぁ、元の症状が従来より軽めな気もするけど。

今回は発症の原因になりそうなことは無いんだけどなー。病気も髭剃りもしてないし。しいて言えば仕事でお疲れモードだったことくらい？

以下、症状の変化の記録。

朝食用のパンを自分で焼くようになって1年ほどになる。

市販のパンは毎日食べるには甘すぎぃ!!って所から始めた自作なんだけれども、最初はフライパンでお手軽に作る方向だったのに、オーブンを使った普通のパン→天然酵母を使ったパン→型買って食パン→クリームパンを作ってみたり、小麦粉の種類を様々試してみたりと、生来の凝り性が災いし着々と沼っているのである。

最近はハード系のパンや黒パン欲が出ているのだが、色々と面倒なんですな。材料がちょっと違ったり、フランスパンにはフランスパンの型が必要だったり、ライ麦粉は良いお値段だし。

そんな中、嫁が「シティ・ローフ：家庭で焼けるソ連風の朝食パン」なるものを見つけてきた。前発酵があり少し面倒ではあるものの、材料・手順ともにシンプル。なのにこれがなかなかどうして超美味しいじゃありませんか。

シティ・ローフが作れなくなると、うちのQoLが激下がりなので、レシピを転載させていただく。

前発酵生地用

生地用

前発酵生地のおかげか、分量や材料には結構寛容に思う。うちでは強力粉の一部を全粒粉に置き換えたり、砂糖を半量にしているが失敗知らず。

前発酵生地

1. 材料を混ぜる

　* はじめに水っぽさがなくなるまで指先で混ぜると、手のひらがベタベタしなくて済む

1. 生地がまとまり滑らかになるまで、手のひらで数分こねる
2. 生地ができたらボウルの底に広げ、乾かないように濡れ布巾やラップをかぶせ2時間程度発酵させる

　* 元レシピによれば「大きく膨らんでから少し縮み始めたら出来上がり」だそうだが、ここまで行かなくても問題なさそう

生地

1. できあがった前発酵生地に、砂糖、塩を溶いた水を加える
2. 更に強力粉、室温に戻したバターを加える
3. 生地が一体化するまで10分程度こねる
   • ここでも、はじめに指先で混ぜておくと、手がベタベタせずに済む
4. 生地が滑らかになったら生地を丸め、薄く油を塗ったボウルに入れる
   • 生地捏ねで使ったボウルでOK
5. 乾燥しないように1.5時間ほど発酵させる。大きさが倍になったら完了

焼成

1. 膨らんだ生地を作業台に置き、拳で空気を抜く
2. 三等分に丸め、乾燥しないように10分ほど休ませる
3. 1つの塊を厚さ1cmほどに伸ばす
4. 祝儀袋を折る要領で、左右を三つ折りにする
5. さらに上下を閉じるように二つ折りし、餃子の皮を閉じる要領で開いてる面を閉じる
6. レモンのような形に成形する
   • ピロシキのような形、と言った方が分かりやすいかも。
7. クッキングシートを引いた天板に置き、乾かないように45分ほど発酵させる
   • かなり膨らむので間隔は十分に空ける
8. 220℃に予熱したオーブンで15～20分焼く
   • 焼き時間はオーブン依存とはいえ、20分はやり過ぎな気がする。まずは13～16分くらいで様子を見るのが良いと思う。13分だとソフトフランスのような焼き上がりになる。

こちらに書いた通り、DIGA DMR-EX250V（2006年5月15日発売）の内蔵HDDはWD2500BB-14RDA0で今となっては希少なIDEドライブである。製造から18年ほどが経ち、いつ壊れてもおかしくない状態と言えよう。SATA→IDE変換アダプタを使い入手の容易なSATA HDD、可能ならSSDに換装できないかとアレコレ試してみたものの、どうやってもF99エラーになってしまい成功していない。とりあえず備忘録がてら現状を書いておく。

準備したもの：

• HDD
  • WD5000AVCS-142DY1 （WD AV-GP SATA 500GB。SATA世代のDIGA修理用として売られてたやつ）
• SATA→IDE変換アダプタ
  • YFFSFDC SATA-IDE 変換 PCBボードアダプタ
  • スゴイアダプタ SATA-IDE変換アダプター マスタースレーブCS切替対応 SATA-TR150VH Ver.3
  • 玄人志向 SATAD-IDE

SATA→IDE変換アダプタの詳細：

手順：

1. 元のHDD WD2500BB-14RDA0をPCに繋ぎ、Linuxのddでセクタダンプ
   • PCの都合でIDE→SATA変換アダプターを経由しているが、影響はないハズ
2. 上記イメージを同様に換装先のHDD WD5000AVCS-142DY1へ書き込み
3. SATA→IDE変換アダプタ経由でWD5000AVCS-142DY1をDMR-EX250Vに接続
   • ジャンパはCS。CSが無ければ色々試す。

3つの変換アダプタを試してみたものの、レコーダーの電源投入後、HDDがスピンアップしアクセス音がして直ぐにF99エラーで電源が落ちてしまう。SATAD-IDEでは一瞬U99が出てからF99になるが、他のアダプタでは気に留めなかっただけで同じかもしれない。

元のHDDで起動後、換装先HDDにホットスワップする荒業もやってみたが、レコーダーがフリーズしてダメだった。

なんとなく、SATA→IDE変換器がキモのような気がしている。

• 価格.comに元と同型番HDDへのセクタコピーによる換装報告があるので、換装自体はできると思われる。

  • HDDの交換を行なうべく、同型式のHDD（WD2500BB）を入手してそのまま換装しましたが、
    「F99」のエラーメッセージが出るだけでうまくいきません。
    困っていたところ、「DMR-XW30」の掲示板で交換成功のスレを発見。
    http://bbs.kakaku.com/bbs/20274010287/SortID=11388303/
    （中略）
    コピーが始まってしばらくすると、READエラーが発生。
    （うっかりしてコピー元のHDDに録画データを残したままであったためか？？）
    おそらく数十MB程度しかコピーされていないようでしたが、試しにレコーダーに取付けて、
    電源を入れると、HDフォーマットが自動で始まりました。
    その後、録画・再生を確認して、無事OKとなりました。

  • 上記リンク先のDMR-XW30（2006年9月1日発売）の例では、SAMSUNG HD400LDから日立のHDDにセクタコピーで換装できており、世代的にも行けそうな気はしている。ただし、HDDがAVコマンド（Streaming Feature Set）に対応してる必要はある気がする。
• 1世代前のDMR-EX200V（2005年11月10日発売）はセクタコピー不要で行けるっぽい。リンク先ではHA250JCからHDT725032VLAT80に換装している。
• DMR-XW300（2007年11月1日発売）はhttps://aucview.aucfan.com/yahoo/j419340315/

• Question - SATA to PATA adapter jumper settings: Master / Slave / Cable Select / ACD - What does ACD do? | AnandTech Forums: Technology, Hardware, Software, and Deals

PanasonicのVHS/DVD/HDD/SDカード対応の4 in 1レコーダー、DMR-EX250Vのパーツメモ。

いずれも105℃品。

RJGとRJXはデータシートが見つからず詳細不明だが、低ESR系統と思われる。うちの個体はRJXが軒並み憤死。検索してみると同時期の製品でRJG, RJFの憤死報告が見つかるので、ELNAは全交換しといた方がよさそう。

二次側の整流コンデンサーと思しきRJX 16V 1500uFはSUNCON ME-WGで置き換えてみたけど、結構発熱するので通常品を使うのはマズそう。

• リモコンの型番
  • EUR7658Y70
• HDDの型番
  • Western Digital WD2500BB-14RDA0
  • 3.5インチ, 7200RPM, 250GB IDE。AVコマンド対応品らしい
• VHSメカの角ベルトサイズ（実測）
  • 直径90mm, 幅2mm

• パナソニック DVDレコーダー DIGA DMR-XW31の修理 - burroの日記
• Panasonic DMR-EX250V 電源が入らない　修理 - YouTube