FATのディレクトリエントリは長いファイル名がunicodeで表現されていますが、 短いファイル名の場合はディレクトリエントリの中身がANSI/DBCSなので言語設定依存です。
Fedora Linuxでは最初から /etc/udisks2/mount_options.conf.example がひな形として用意されています。 これを /etc/udisks2/mount_options.conf としてコピーします。 それから編集します。 defaultsのセクション宣言がないと設定は認識されません。
[defaults] vfat_defaults=uid=$UID,gid=$GID,shortname=mixed,utf8=1,showexec,flush,iocharset=utf8,codepage=932
設定ができたら sudo systemctl restart udisks2 を叩きます。 メディアを再マウントしてからmountコマンドを叩き、mount optionsの効果を確認します。 それから、念の為に、ファイル操作に入る前に読み取りが正しくできるか確認しておいたほうが良いでしょう。
事業になるような規模であればdedupeのリスクは無視できるでしょう。 それは本質的に有限責任であり、資本金で均すことができるからです。 もうひとつはdedupeしなければやってられないほど膨大な記録、 または遠距離の記録を行うからです。 そのような規模では本質的に採否の決定権がありません。 dedupeの採用が先にあり、安全性に関する説明は後付けの言い訳です。
個人のデータ保管であればdedupeのリスクをどうするかよりも先に dedupeのコストは無料ではないという点が大きくのしかかります。 dedupeには膨大なメモリキャッシュを必要とするので、 サーバが不必要に巨大になるという点は無視できません。 そこまでするなら素直にストレージを買い足すという選択もできます。
結局のところ、 dedupeをするかしないかという問題は、 住んでいる世界がどう異なるかという問題に帰着します。
dedupeが安全だと言われるのは、 暗号学的なハッシュ関数がどんな入力に対しても疑似乱数を返すことに由来します。 疑似乱数同士の衝突確率は誕生日のパラドックスで語られます。 HDDが読み書き故障を経験するのは、設計上、確率的に1014bitのオーダーであると言われています。 11.6TiBぐらい書くと1bitぐらいは壊れているかも知れないね、ということを意味します。 計算が面倒なのでWikipediaのテーブルを引きます。 1015回の試行でも壊れない水準を求めると、それでも8.2x1011回の試行余地があります。 これはHDDに3PiBぐらい書き込んでもHDDの読み書き故障率に到達しないことを意味します。 つまりdedupeの失敗とハードウェアの故障とを区別する必要がないであろう、という理屈です。 もちろん確率の話なので、それで判断してどうなるかなんて誰も保証はしませんし、誰も責任は取ってくれません。
Fedora 44にアップグレードするとき、tlpの存在がストッパーになってしまいました。 Fedora 44の標準構成としては、パワープロファイル系はtuned-ppdに置き換えられたということです。 旧来はバッテリの保護をtlpで実施されてきましたが、今後はtuned-ppdで実施することになります。 このような切り替えが行われると、しばらくの間はバグに悩まされることになりがちです。 正しく動作するかどうかに注目しましょう。
バッテリ保護は再起動中などOSが稼働している間は効かないので、 再起動するときなどはそのあたりに注意して適宜放電することとし、 調整する必要があります。
ストレージホストと仮想化基盤ホストを同居させるのはハードウェア利用効率が悪い、という課題があります。 仮想化基盤ホストはIOPSが重要ですからRAID-1を組むことが推奨されます。 ストレージホストは通常はIOPSよりも記録密度が重要です。 そこではRAID-1のような贅沢をする余裕はありません。
クラウドでは高可用性をアプリケーションで負担するという考え方が一般的です。 その場合は「壊れたら即座の復旧は諦める」ことを前提にハードウェアをシンプルにできます。 NVMe SSDをメインストレージにしてHDDにバックアップする素朴な構成が組めます。 コストを掛けられないご家庭レベルでは親和性が高い考え方であると言えるでしょう。 NVMe SSDは滅多に壊れるものではありません。 それでも壊れる時は壊れ、そのときは突然死にます。 ですからNVMe SSDだから大丈夫と考えるのは危険です。 HDDなどによるバックアップは必要です。
高可用性が組みたい場合はProxmox VE + DRBDの2-node構成が最小限度です。 実用経験を求めるならProxmox VE + Cephの3-node構成が勧められます。 しかしCeph方式はnode数が増える分だけ初期コストも維持コストも増えます。 Cephを試すのはnode数を5本以上に増やしたい希望がある場合に限られると見てよいでしょう。 DRBDをサポートするLinbitはProxmoxから見てサードパーティです。 DRBDを採用する場合は、 将来のセキュリティパッチやアップグレード等の時点で問題が発生しうることは十分に承知しておく必要があります。 Proxmox自身がDRBDをなぜサポートしないのかという、 歴史的な経緯も調査しておいたほうが良いでしょう。 最終的に、個人用であれば高可用性をあきらめるというのが、 掛かるコストとのバランスを考えると妥当だと思います。
ストレージノードについて。 4〜8TBクラスになると動画でも溜め込まない限り生涯mirrorで足りるという事例も出てきます。 このような場合はmirrorで済ませることも考えられます。 実際、市販のNAS箱はそのほとんどがmirror以上のことに対応しません。 mirrorで足りない場合はZFSをベースにRAIDZを組むのが鉄板です。 ストレージもバックアップが必要であることは間違いありませんが、 ストレージのリカバリー操作にはとにかく時間がかかります。 HDDが1本壊れたからと言って 「回復プロセスを待つ、回復できる機会を待つ」 ということはできないことが多いです。 最低でもmirrorは組んでおいたほうが良いでしょう。