FreeBSDのZFS(raidz1)に使用している3TBのHDDが壊れていて、ファイルシステムがdegradedを出していたので、今回はSSDに交換することにしました。 交換対象のHDDより小さいSSDを使ったらどうなる？って言うより3TBは無くて4TBになり、少々高価なので、試に2TBを入れてみましたが、案の定 too small ....と受け付けてくれません。 （当たり前か、、、）
やむを得ず4TBのSSDを購入して、インストール。 （４TBのHDDって選択もあったのですけど、何故かSSD買ってしまったので、とんだ散財）
ZFSでのHDDの交換については、以前ここに記載したのでそれをそのまま踏襲。 「実に簡単」 resilveringに小一時間掛かって無事終了。 と言っても、故障中も、交換中もサーバーは通常通り動いているので、ユーザーには何の影響もありません。
何か月か前に、誤って消したファイルの復活にもZFSが役立ったし、ほんとにファイルシステムの信頼性が高くて、安心して使用できます。 Sun Microsystems 様に感謝感謝。
久しぶりに写真の整理をしていて、DataServer(FreeBSD)に放り込んでいた写真を、撮影した年代日付毎のフォルダに入れてゆく作業をしていました。
Windows10からFreeBSDの共有フォルダが見えるようにしてある(Samba3)ので、操作はWindows上のexplorerから行っていました。 で、2020,2019,2018と降りて行った際に、間違って整理し終えた2018年のフォルダをうっかり消してしまって、真っ青！ これは、ゴミ箱からの復帰は有り得ませんし、クラウドにもこのファイルは上げていないし、、、。
あ、ひょっとして、ZFSファイルなので、定期的にsnapshotを取っていたのではなかっただろうか？ と、サーバーにアクセスして；
 |
| Crontabの内容（一部） |
# zfs list -r -t snapshot -o name,creation zroot/usr/home
NAME CREATION
zroot/usr/home@zfs-auto-snap_monthly-2020-06-01-00h28 月 6月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-07-01-00h28 水 7月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-08-01-00h28 土 8月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-09-01-00h28 火 9月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-10-01-00h28 木 10月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-11-01-00h28 日 11月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-12-01-00h28 火 12月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2021-01-01-00h28 金 1月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-02-01-00h28 月 2月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-03-01-00h28 月 3月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-04-01-00h28 木 4月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-04-18-00h14 日 4月 18 0:14 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-04-25-00h14 日 4月 25 0:14 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-05-01-00h28 土 5月 1 0:29 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-05-02-00h14 日 5月 2 0:14 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-04-00h07 火 5月 4 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-05-00h07 水 5月 5 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-06-00h07 木 5月 6 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-07-00h07 金 5月 7 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-08-00h07 土 5月 8 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-09-00h07 日 5月 9 0:07 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-05-09-00h14 日 5月 9 0:14 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-14h00 日 5月 9 14:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-15h00 日 5月 9 15:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-16h00 日 5月 9 16:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-17h00 日 5月 9 17:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-18h00 日 5月 9 18:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-19h00 日 5月 9 19:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-20h00 日 5月 9 20:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-21h00 日 5月 9 21:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-22h00 日 5月 9 22:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-23h00 日 5月 9 23:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-10-00h00 月 5月 10 0:00 2021
で、早速作業を始める前の時間のsnapshotを適用
# zfs rollback -r zroot/usr/home@zfs-auto-snap_hourly-2021-05-10-09h00
数分で終了したので、Windowsのexplorerで確認すると、在りました！
あー、良かった。 二時間ほどの作業は無駄になりましたが、無くならなくてよかった。何の気なしに、cron に設定しておいたsnapshotに救われました。
ZFS様様です。 今度HDDからSSDに替えてスピード上げてやろう！
WSJTXは自分のHomeDirectoryのAppDataの下にwsjtxのプログラムディレクトリにALL.TXTという名前で、起動している間の全ての受信データ（左側の窓の内容）が保存されています（
時々、消してやらないと、とんでもなく大きく成長する）。
抽出ソフトは、正規表現の復習にと、perlを使ってみました。 もう20年ほど弄ってないので、苦労しましたが、脳の活性化には良い勉強です。 正規表現が少々甘いこともありますが、全員がプロトコルに従った内容だけを更新しているわけでは無いので、かなりのゴミを含み、RDBに入れてから、ゴミ掃除が必要です。 2019年11月から、主に30/40/80mのデータが64,059,176件（取り切っていないゴミも含めて）入っています。 RDBでないと処理は無理ですね。
これで、自分が欲しい局が、過去に出ていた時間（自分のリグで受信していたにも拘らず更新できなかった、或いは呼んでも答えて貰えなかった）を把握することが出来るようになりました。
ここまで来ると、「SN、黒点数と信号強度の関係は？」とか興味が湧いてきます。 で、SNのデータを探してみるとSILSO に1818年からのデータがありました。 月一度のupdateのようで、今の時点で4月30日までのデータが入手できましたので、これも抽出ツールをperlで組んでRDBに入れてみました（csvファイルと記載がありますが、コンマ区切りではなくセミコロン区切りでした）。
wsjtxlogとsunspotnrの二つのテーブルを結合すれば、その日の特定の局の信号強度と黒点数が表示されるようになり、コンディションの推測など今後の利用が期待できるかもしれません。 （二つのテーブルは粒度が違う、wsjtxlogは分単位、SILSOのデータは日単位、ので少々SQLを細工する必要があり、viewを作ったうえで結合させています）
今のところ、Unixにアクセスしてsql書いて必要なデータを取得しているだけですが、抽出の切り口が絞られてくれば、WEB上でグラフ化することもこれからの課題です。
下は、SQLによるデータ表示例（9G5FIの30mバンドの状況一部）；
countは一時間に何回受信したかの数量（多い方が安定していた？）
max/min/avgは信号強度dBのその時間内の最大・最小・平均の値
SNと信号強度には関連はなさそう、、、。
SNが高いと聞こえている時間が長い？
