ラベル ZFS の投稿を表示しています。 すべての投稿を表示
ラベル ZFS の投稿を表示しています。 すべての投稿を表示

2022年5月28日土曜日

サーバーの復帰(続き)

立ち上がりそうなことは確認できたので、システムディスクをM.2 のSSDに替え、最新のFreeBSDを(uname -r: 13.0-RELEASE)M.2 SSDにインストールして、今まで使っていた zfs が立ち上がり、今までのファイルが読めることを確認したので、Xをインストールして、Windowマシンからremoteで幾つでも窓開けて作業できるようにして、まづ第一段階の復帰は終了。 

ここまでは、あまり問題なくすんなり進んで一安心。 特にZFSが完全に読めるので、snapshotなり、以前作っておいてzfsに保存していたusr/local等のバックアップが利用できたので大変に助かった。

で、postgresql, apache24,samba4等いつも使っていたものについても、それぞれ復帰を試みる。

apache24: portから最新のものをインストール(時に大きく変わることは無いはずなので問題は無いはず)。 しかし、http.confで引っ掛かる! バックアップから/usr/local/www/等関係のありそうなものをコピーしてきて、立ち上げ直すと無事にデータロガーも含めて動作した。

samba4: portから最新のものをインストール。これもsmb4.confが必要なので、/usr/local/etc/のバックアップからsmb4.confをコピーしてきて立ち上げ直すと無事動作。 Windowsマシンから、サーバー上のディレクトリが読めるようになって、よかったよかった。

postgresql: これもversion 12を使っていたので、取り敢えずversion 12をインストールしてDBのバックアップをとり、それから最新の、、と思ったけれど一つ手前のversion 14をインストールし直し、先に取ったバックアップファイルからDBを復元。

ここまでで、すべてOK! とはゆかず、、、。

自宅環境の温湿度などを表示させていたWEBサーバーのアプリが、JpGraphを使ってグラフを表示させていたが、php 7.2までしかサポートしていなかった。  

phpも8.0.19にバージョンアップしてしまったので、グラフ表示に別のプログラムを使用することにしました。 Canvas.JSが良さそうなので、一週間ほどいじくりまわして何とか、らしきものが表示できるように出来ました。 そのうち、もう少し機能を理解して改善してゆきたい。 Javascriptを使ったサーバーサイドプログラム?なので、まだ十分には理解できていないかも、、、。

 

停電は川崎市の水道局が工事中に、東電の設備を壊してしまったことによるらしいのですが、お陰で久しぶりにUnix環境のプログラム作成をすることになりました。 Emacsも久しぶりで、使えるようになるのに少々時間が掛かりましたが、今はWindows上でやたらctrl-Cして困ってます。

 

教訓

  • オープンソースのプログラムは定期的にアップデートしていないと、古いシステムのままで動かし続けるのは 複数の自作アプリが組み合わさったりしているので、難しい(個々のプログラムのサポート体制が異なる)
  • ZFSは安定していて、最近open zfsに変更になった様に理解していたが、問題なく使用できて大変助かった(十分信頼に足るシステムのように思う) 。 zfstoolsを利用して、15分毎にsnapshotを取っているので、急な停電でもZFSが壊れていなければ、停電15分前には戻れる。
  • /etc/ 、/usr/local/etc/ 下の自分の設定ファイル、DBのデータ ファイル www下のファイルなどは必ずバックアップを取っておく事。 これで、昨日の状態が復元できる!
  • 年齢も年齢なので、老いの予防に時々システムのアップグレードなどで頭の体操をした方が、良いのでしょうね。 運動などして筋肉強化には務めていますが、頭の体操は、あんまりしていないので、、、。
  •  ZFSを起動システムにしていないので、システムの入れ替えとは独立してファイルを移行できるのですが、設定ファイルのバックアップが自動では取れないことになるので/usr/local/etcはzfs上にマウントし、/etcは別途定期的にzfs上にbackup fileを作るようにしておくことにします。

 

後から継接ぎでzfs のmountpointを追加したので綺麗くないですが、今のdf




2022年5月14日土曜日

サーバーの復帰

昨晩の突然の停電で、サーバーが停止、立ち上がらなくなってしまいました。 2年近く弄っていないので、ディレクトリ構成とかZFSがどうなっているのかすっか忘れてしまっていて、このブログの過去記事をたどって復活させました。 

まず、起動ディスクは?  

  •  過去ログ見るとluaか何かの原因でZFSから起動しないために、HDDから起動させたのちにzpool importでファイルをマウントしているようなので、まづ、起動ディスクを探す。  
    • 立ち上がる時に<DEL>キーで、biosから見えるDiskを探い、取り敢えず片っ端から起動させてみる。  
    • ー>一つだけFreeBSDが起動するディスクが見つかる。 
  • FreeBSDを起動させて、dfしてみると、当然/以外はなにもないので、zpool importで認識されるzfsを表示させてみる。  
    •  ー>zrootという名前のzfsファイルシステムが見つかった これをimportする  
    •  ー>zpool import zroot こうすると、元々のhdd上の/以下にzrootのファイルシステムがマウントされる。 

被るファイルの内容が出てくると思われるが、取り敢えず動いて復帰できたので良しとする。

ブート領域を含めて修復して、再起動の手間を省くようにしないと、、、、。 

久し振りの*nixはコマンド名とか思い出すのに時間が掛かり、なかなか大変。 時々は*nixしてリハビリしていないと、あきませんな~。

 

2021年5月30日日曜日

FreeBSDサーバーのHDDが壊れている!

FreeBSDのZFS(raidz1)に使用している3TBのHDDが壊れていて、ファイルシステムがdegradedを出していたので、今回はSSDに交換することにしました。 交換対象のHDDより小さいSSDを使ったらどうなる?って言うより3TBは無くて4TBになり、少々高価なので、試に2TBを入れてみましたが、案の定 too small ....と受け付けてくれません。 (当たり前か、、、)

やむを得ず4TBのSSDを購入して、インストール。 (4TBのHDDって選択もあったのですけど、何故かSSD買ってしまったので、とんだ散財)

ZFSでのHDDの交換については、以前ここに記載したのでそれをそのまま踏襲。 「実に簡単」 resilveringに小一時間掛かって無事終了。 と言っても、故障中も、交換中もサーバーは通常通り動いているので、ユーザーには何の影響もありません。

何か月か前に、誤って消したファイルの復活にもZFSが役立ったし、ほんとにファイルシステムの信頼性が高くて、安心して使用できます。 Sun Microsystems 様に感謝感謝。




2021年5月10日月曜日

ZFS に救われた! FreeBSD data server

 久しぶりに写真の整理をしていて、DataServer(FreeBSD)に放り込んでいた写真を、撮影した年代日付毎のフォルダに入れてゆく作業をしていました。 

Windows10からFreeBSDの共有フォルダが見えるようにしてある(Samba3)ので、操作はWindows上のexplorerから行っていました。 で、2020,2019,2018と降りて行った際に、間違って整理し終えた2018年のフォルダをうっかり消してしまって、真っ青! これは、ゴミ箱からの復帰は有り得ませんし、クラウドにもこのファイルは上げていないし、、、。 

あ、ひょっとして、ZFSファイルなので、定期的にsnapshotを取っていたのではなかっただろうか? と、サーバーにアクセスして;

Crontabの内容(一部)
zfs list -r -t snapshot -o name,creation zroot/home (Windowsとの共有は/usr/homeの下にあるので)としたらやったね! 在りました。 月単位、週単位、日単位、時間単位の4段階でsnapshotを自動作成していました。 cronに設定したら、後は自動なので忘れちゃうのが問題かな?

# 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に替えてスピード上げてやろう! 


 

2020年7月7日火曜日

zfsの不調HDDを交換

zpool status でhddが一台不調なのを見つけ、交換しました。
手順は;
  1.   問題のHDDをoffline
  2.   問題のHDDの電源を切り、取り出す。
  3.   新しいHDDを挿入(この時tail -f /var/log/messages等して、挿入したHDDの名前を確認)
  4.   zpool replace <pool> <取り出したdevice> <新しいdevice>

で、そのうちデータの複製が完了します。
着脱可能な3台収納のHDDケースを使っていますが、埃の溜まり方が半端ない! 時々offlineして、埃を取ってやる必要がありそうです。 (商用のサーバーはどうしているのかな? サーバールームだから、埃は無いか?)

HDDのトラブルは結構多い!

tail -f /var/log/messages
Jul  6 15:24:31 <xxx> kernel: ada3 at ahcich4 bus 0 scbus4 target 0 lun 0
Jul  6 15:24:31 <xxx> kernel: ada3: <ST3000DM007-1WY10G 0001> ACS-3 ATA SATA 3.x device
Jul  6 15:24:31 <xxx> kernel: ada3: Serial Number ZFN3CG9W
Jul  6 15:24:31 <xxx> kernel: ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
Jul  6 15:24:31 <xxx> kernel: ada3: Command Queueing enabled
Jul  6 15:24:31 <xxx> kernel: ada3: 2861588MB (5860533168 512 byte sectors)
Jul  6 15:24:31 <xxx> kernel: ada3: quirks=0x1<4K>
Jul  6 15:24:31 <xxx> kernel: ada3: Serial Number ZFN3CG9W
Jul  6 15:24:31 <xxx> kernel: ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
Jul  6 15:24:31 <xxx> kernel: ada3: Command Queueing enabled
Jul  6 15:24:31 <xxx> kernel: ada3: 2861588MB (5860533168 512 byte sectors)
Jul  6 15:24:31 <xxx> kernel: ada3: quirks=0x1<4K>
Jul  6 15:27:06 <xxx> ZFS[57380]: vdev state changed, pool_guid=$10144449840837033772 vdev_guid=$10616007156599679386



# zpool replace zroot 4351727843915028191 ada3
Make sure to wait until resilver is done before rebooting.

If you boot from pool 'zroot', you may need to update
boot code on newly attached disk 'ada3'.

Assuming you use GPT partitioning and 'da0' is your new boot disk
you may use the following command:

 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
#

2018年10月30日火曜日

FreeBSDサーバーが再起動できない!

IBMがRedHatを買収!というニュースで「JBossはどうなるのかな?」とふと思い、FreeBSDサーバーで動いている、Freeのアプリケーションサーバー、Wildflyをportsで探してみると、ちゃんとWildfly14というのが出ていたので、早速インポートして、立ち上げてみるけど、アクセスすると、前から入っているWildfly11が出てくる!?  
やむを得ず再起動!  ありゃ?サーバーが立ち上がってこない!! モニターつけて調べてみると、ブートしてこない。 かなりややこしそうなので、翌朝から作業することにして、今日はサーバーは停止。

朝から、モニター繋いでキーボード繋いで、LiveCDで調べてみるとzpoolもちゃんと見えるし、どこも悪くなさそう。 gpart bootcode -b/boot/pmbr -p /boot/gptzfsboot -i 1 ada? として、ブートコードを書き直して、再起動してみるが起動しない。 DVDからは起動できるので、余っているHDDを繋いで11.2Rを新規インストールして、HDDから立ち上げようとするが、やはりダメ。 (Windows7のHDDは認識して、立ち上がるみたいですが、、) 要するにHDDから起動できない? そんな馬鹿な!
今まで、何も問題なく起動できていたが、これでは手も足も出ない。 カーソルが、ブートコードを何回か読みに行って、失敗してbios設定メニューに戻ってくるのが確認できるが、これ以上ができない。 
しようが無いのでamazonで中古の同じMB(Asus H87M Plus)を注文。 中古のMBはちょっと心配ですが、これでうまくゆくか確認してから、次の手を考えることにします。 LiveCDでzfsのファイルにはアクセスできることを確認しているので、少し気は楽です。

2018年6月23日土曜日

OMG!の続きの続き

新しいLGA2066のMBはCPUクーラーが入手できずに依然として作業台の上でお休み中。
サーバーのHDDをoffline/onlineで一時アクセスは正常に戻るのですが、1日ほどすると再度一台目のアクセスランプがつきっぱなしになりI/Oが極端に遅くなります。 zpool statusしても、特にHDDの状態が悪いわけでもないように思われますが、取り敢えずHDDを替えてみて様子を見ることにしました。 Seagateの3TB(ST3000DM001)を使っていたので、同じものを探してみましたが既になく、ST3000DM007を購入。 大分薄くなっています。
で、下のプロセスでresilvering。数時間かかってreplaceしましたが、今度は何ともありません。 いったい何がおかしかったんでしょう?HDD?

1) tail -f /var/log/messages でシステムログを見ながら、新しいHDDを挿入して、電源を入れて、HDDに割り振られた番号(名前)を確認。
2) zpool replace を実行して新しいHDDに置き換える。
3) zfs boot しているので、置き換えが完了後、用心のため gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 をしておく。 (この、の所が今一よくわかっていません。 ada0,ada1,ada2と3台あるので、片っ端からgpartを実行してみましたが、no such geom: ada?と出て、一台だけにしか書き込みはできませんでした。)

=================================================
root@tyd # zpool status
  pool: zroot
 state: DEGRADED
status: One or more devices has been removed by the administrator.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Online the device using 'zpool online' or replace the device with
    'zpool replace'.
  scan: resilvered 468K in 0h0m with 0 errors on Fri Jun 15 12:05:25 2018
config:

    NAME                                            STATE     READ WRITE CKSUM
    zroot                                           DEGRADED     0     0     0
      raidz1-0                                      DEGRADED     0     0     0
        3945605936303358747                         REMOVED      0     0     0  was /dev/gptid/e259f7a8-c5b2-11e3-b83d-e03f49b2dc0a
        gptid/e38e6197-c5b2-11e3-b83d-e03f49b2dc0a  ONLINE       0     0     0
        ada0                                        ONLINE       0     0     0

errors: No known data errors

root@tyd # zpool replace zroot gptid/e259f7a8-c5b2-11e3-b83d-e03f49b2dc0a ada1
root@tyd # zpool status
  pool: zroot
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Jun 21 11:03:10 2018
    55.7G scanned out of 2.03T at 143M/s, 4h0m to go
        18.6G resilvered, 2.68% done
config:

    NAME                                            STATE     READ WRITE CKSUM
    zroot                                           DEGRADED     0     0     0
      raidz1-0                                      DEGRADED     0     0     0
        replacing-0                                 REMOVED      0     0     0
          3945605936303358747                       REMOVED      0     0     0  was /dev/gptid/e259f7a8-c5b2-11e3-b83d-e03f49b2dc0a
          ada1                                      ONLINE       0     0     0
        gptid/e38e6197-c5b2-11e3-b83d-e03f49b2dc0a  ONLINE       0     0     0
        ada0                                        ONLINE       0     0     0

errors: No known data errors


root@tyd # zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
    still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
    the pool may no longer be accessible by software that does not support
    the features. See zpool-features(7) for details.
  scan: resilvered 692G in 12h5m with 0 errors on Thu Jun 21 23:08:29 2018
config:

    NAME                                            STATE     READ WRITE CKSUM
    zroot                                           ONLINE       0     0     0
      raidz1-0                                      ONLINE       0     0     0
        ada1                                        ONLINE       0     0     0
        gptid/e38e6197-c5b2-11e3-b83d-e03f49b2dc0a  ONLINE       0     0     0
        ada0                                        ONLINE       0     0     0

errors: No known data errors
root@tyd # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

2016年8月30日火曜日

FreeBSD 10.0Stable とZFS

Windows10の8月のupgradeでXlaunch(Xwindow)が使えるようになったので、FreeBSDサーバのzfsをチェックしてみるとディスクが2台しか動いて居らずdegradedになっている! どのディスクが動いていないのか、見当をつけて電源を落としてみると3台目がおかしいようだ。 で、WEBで注文して早速交換! うん? 勝手にはやってくれない、、、。 WEBをググってもこれという記事が出てこないし、おまけに最初の設定をメモってないのでどうなっているのかもわからない(自分のページ見てもスンナリ「ZFSを入れた」としかなくて、頭からZFSでブートしているのか??)
新しいディスクを入れて、色々試行錯誤して何とか動くところ(現在resilvering 中)まで来たので、今後の為に記録を残しておきます。  交換したディスクが逝かれているのかは不明。



手順:
zpool statusでダメなディスクをoffline.
ディスクを交換
その後、右の様にunavailとなっているディスクを新しいディスクで置き換える(zpool replace)

通常使っているada1といった名前が出て来ずに/dev/gptid/e..... と長ったらしい名前が出てくるので、これを使ってよいのか迷う。 それと、新しいディスクはad6がada2にリアサインされている(ls /dev/* で確認)のでどちらを使うのか迷うが、どうもada2で良かったようです。  どうもzrootからbootしている様なので、boot codeを ada2にも書き込まなければならないようです(書き込まなかったらどうなる?) gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2 って事かな?

3時間ほど掛かってresilveringが終了してraidz1-0にada2が正常に追加されました。
で、gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2ってやってみましたが、
gpart: No such geom ada2でダメ。 ad8でやってみても同じでした。


うーん、良く分かっていない、、、、。



2014年4月16日水曜日

やはり1台じゃ不安、、、

昔からの8IPのネットワークを止めて、1IPのネットワークに契約し直した結果として独自ドメインもメールサーバも必要なく(自宅内のメールを全てgoogleに移行させ)なったので、それまで稼働していたサーバを止めて、バラして先週水曜にパーツとして売却してきた(収入はまだ未確定)が、週末のトラブルのような事態にはやはり独立して動くマシンが必要だと痛感。
で、2Uでi7でもう一台作る事にして作業開始。 これをデータサーバ、DHCPサーバとして使うことにして3TBのディスクを3台ZFSのraidz1で構成することにして、通常使っているPCはWindows8.1にすることにした。 今までの構成とは逆でFreeBSDは従、Windowsが主となることに、、、。
で、root-on-zfsが使える事になっているFreeBSD 10.0Rをインストールしてみたが、起動しなくなる! おい、どうなってる?とググってみるとありますねー。

"Partitions not seen. When using GPT, FreeBSD will create a protective MBR. This MBR has one partition entry covering the whole disk. FreeBSD marks this partition active. This causes at least some UEFI implementations to ignore the GPT. To fix this the partition needs to be marked inactive."

I had the same problem using GPT partitions on an Asus z87-ws motherboard with FreeBSD 10-RCx. I had to enable/disable the active flag after sysinstall ends to make it work.

gpart set -a active adaX

今日帰ってやってみて、うまく行かなかったら何か別の方法を考えなければならないかもしれませんが、かなりの人が「これで解決」と言っているので、多分大丈夫でしょう、、、。

>大丈夫でした。 gpart set -a active ada0 で嘘のようにうまく立ち上がり、raidz1の3TB x 3のディスクサーバの出来上がり。 あ、設定を忘れてラックに入れてしまったので、もう一度取り出してsshでアクセスできるようにしておかないと、、、。

FreeBSDへはWindows上のXming(無償のX server)で対応できそうなので、これでもあまり今までと変わりなく使える事を期待しています。 ま、どうしても必要であればWindows上のVirtualBoxで動かせばいいわけだし、、、。

SmartSDRなど無線関係でWindowsを頻繁に使うようになり、だいぶ軟弱路線化している自分、、、。
 

2007年4月16日月曜日

FrrBSD-current でZFS(3)

うーん、/usrをZFSにして、make buildworld してみましたが、raidz2でufsに比べて4倍くらい遅い、、、。
最適化はこれからだとしても、このままではちょっと、直には使えません。 (何か、特定の設定を変えることにより、パフォーマンスが上がるような記載は無かったので、デフォルトの状態での実験ですが、ひょっとしたら、良いパフォーマンスが出る方法があるのかもしれません)。
ドライブの追加、交換などの作業が簡素化出来そうなのと、パーティションを切らなくても済むのがメリットであることは確かですが、この為にスピードを犠牲にすることになるのでは使えません。 早くufs以上のI/Oスピードが出るようにoptimizeされることを願っています。

WSJT-x Super F/H

 WSJT-x使い始めてから随分経ちます(JT65しかなかった頃から)が、FT8のF/Hの使いがっ手の悪さ、MSHVの方が利用されている実態、F/HでFoxがマルチで返答すると信号が弱くなる、などからSuperF/Hが実装されましたね。  そこまでは、問題なく理解していたのですが...