Lewis
1
こんにちは、
QuTS hero が合計容量や空き容量をどう計算しているのか質問があります。もしどなたか理解の手助けをしてくれるなら、ありがたいです。
私のセットアップは 18TB ドライブが9台（RAID 6, ZFS、つまり2台がパリティで7台が実際の容量になります）です。
そのドライブをフォーマットすると実際には 16.4TB（16.39ですが、四捨五入して）になります。
16.4 * 7 = 114.8TB がストレージマネージャに空き容量として表示されると期待していました（OSやアプリは NVMe ドライブにあるので、これは別のストレージプールで影響しません）。
QuTS では 108TB と表示されているので、いきなり 6.8TB（114.8-108）どこへ消えたのだろうと疑問です。
その後、そのストレージプール2に共有フォルダを3つ作成しました。
1.HDP_Backups
2.Master
3.Media
この3つのフォルダはすべて「シンプロビジョニング」なので、仕組みとしては容量計算が動的ですよね？ボリュームを拡張（ディスク追加）すれば容量も増えるはずですよね？
フォルダ1と2は空き容量（メディアファイルを一部コピー済み）が 83.16/83.17TB と表示されますが、Media フォルダだけは 96.63TB と表示されます。
同じプールなのに、ひとつのフォルダだけ他より13TBも多く表示されるのは「トリック（仕掛け）」があるんでしょうか？それともバグでしょうか？
実際、Media の数字が一番近い感じです。93.6+13.47（これは107TB）は全体容量108TBに近いですが、他2つのフォルダだと全体容量が96TB（83+13.4）になってしまいます。
ありがとうございます
こんにちは、
ここだと思います。
ストレージプールのオーバープロビジョニングの構成 | QuTS hero h6.0.x
さらに、圧縮や重複排除も利用できます。
データ削減 | QuTS hero h6.0.x
そして、おそらく3つのシンフォルダーを全体的に割り当てすぎていると思います。
プール = 108TB
3つのシンフォルダー = 83TB + 83TB + 96TB = 262TB
プールの108TBしか実際には利用できません！！！！
Lewis
3
こんにちは @Becker2020、参加してくれてありがとうございます。
いくつかの記事やRTFMを読んで、ThinとThickについていろいろな動画も見ましたが、自分の用途ではどうやらThinの方が良さそうです。今後ボリュームを拡張する予定で、いずれHDDが安くなったら、2035年くらいかな ;)。あと5.4TBを追加しても、いまいち数字が合わないんですよね :)。
ZFSをQuTS heroで使うと、フォルダーがQTS/ext4ボリュームやSynology BRTFS、Windows NTFSと比べて、ボリュームのように扱われるのは理解していますが、それでも同じPool内なので全てのフォルダーが108TBの条件に合うはずと思っていました。もちろん「オーバープロビジョニング」はThinモードなら常に発生しますが、それは普通ですよね。
Thickだったら、NAS上で作成する各フォルダー（ZFSライクなボリューム）に108TBを割り振る必要がありますが、自分の使い方・計画では、どのフォルダーが最終的にどれだけ使うか、HDPがワークステーション・PCのバックアップでどれだけ使うか全く分からないので、計算が面倒だし、「柔軟」なThinモードの方が良い選択だと思っています。
なので、5.4TBのオーバープロビジョニングを考えても、メインの「問題」はやっぱりフォルダーごとに表示される値が違うことです。
Windowsでも同じで、各フォルダーのサイズや空き容量が違って表示されるのですが、これって「Thin」モードであるべきなのに、同じストレージプールなのにフォルダーごとに「空き容量」が違う数値で出てくるのが何とも不思議です。
多分、ZFSのクセや特徴に脳を「再配線」しないとダメですね :D。
あと、もう一つ。
技術的には、Pool2（HDDだけのやつ）のオーバープロビジョニングをオフにすることもできるんでしょうか？OSやアプリ用のPool1（NVMe・RAID1）も使ってるので、それで大丈夫ですよね？
それは間違っています。
83.16TB、83.17TB、96.63TBは共有フォルダの容量です
79.99MB、9.99GB、13.47は共有フォルダ内のデータです
それはあまり良いアイデアではないと思います。
ストレージがほぼ満杯になると、システムが遅くなったり効率的に応答しなくなる場合があります。
ストレージプールやボリュームが閾値まで達するとどんなリスクがありますか？ | QNAP
Lewis
6
私が知る限り、これは「アラート閾値レベル」向けのものだけで、各フォルダーごとにオンにしているので問題ありません。
もう一つは、「オーバープロビジョニング」についてですが、ネット上で調べた限りでは主にSSDドライブにとって有用・メリットがあり（新しいNVMeでは、これが内部ハードウェアレベルで実装されている場合もある）HDDでは必要ありません。
ありがとうございます。
NA9D
7
ルイスへ、
君はいろんな細かいことにばかり気を取られているようだね。NASはちゃんと動いてるんだから、もっと楽しもうよ。
OSのために使われている容量もあることを忘れてるよ。OSはすべてのドライブに分散しているんだ。
NASを楽しんでね。 
Lewis
8
正直まだ使い方を理解しないと楽しめないので、これからちゃんと学ぶ必要がありますね 
。
それと、OSが全ドライブに広がるというコメントについてですが、ZFS QuTS Heroではそうじゃないと思います。QNAPチームの推奨通り、私はシステム／OSとアプリ専用のプール（2台の2TB NVMeドライブ）を作っています（QNAP UKの動画でも推奨されていました）。
なので、もしHDDを全部抜いても、NASは問題なく動作・起動します。システムOSとアプリは全部別のプール（Pool 1）にあるからです。
この容量「問題」はデータ保存用のHDDだけのPool 2で起きています。
全部ちゃんとセットアップできたら楽しめると期待しています。今のところはまだSynologyからファイルをコピーしたり、QuTS heroのクセやバグを色々見つけたりしてる段階なので、色々質問して「自分の理解不足なのか」「QuTS heroのバグなのか」を確かめてます。
例えば、QVR監視の設定がまだうまくいかないし、CAYINプレーヤーもサムネイルが表示されないなど…。でも、まず自力で解決しようとがんばってから質問しようと思っています。
それに、自分のミスじゃないと確認できたものは公式のチケットシステムに報告もしています（だからみんなの協力が必要なんです :))。QNAP開発チームもすでにいくつか返信をくれて、次回のQuTS hero 6.1リリースで修正してもらえたものもあります。
ではでは！
cat /proc/mdstat を実行してみれば、自分で確認できます（QuTSでもOSパーティションはextです）
こちらが私のTVS-h1288Xの例です
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md322 : active raid1 sde5[4](S) sdl5[3](S) sdk5[2](S) sdj5[9](S) sdi5[8] sdg5[7] sdf5[6](S) sdd5[5](S)
31868416 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md321 : active raid1 nvme0n1p5[2] nvme1n1p5[0]
31868416 blocks super 1.0 [2/2] [UU]
bitmap: 0/1 pages [0KB], 65536KB chunk
md13 : active raid1 sde4[137] sdl4[136] sdk4[135] sdj4[134] sdi4[133] nvme0n1p4[1] sdg4[141] nvme1n1p4[129] sdh4[130] sdb4[131] sdc4[132] sdd4[138] sda4[140] sdf4[139]
458880 blocks super 1.0 [129/14] [UUUUUUUUUUUUUU___________________________________________________________________________________________________________________]
bitmap: 1/1 pages [4KB], 65536KB chunk
md9 : active raid1 sde1[136] sdl1[135] sdk1[134] sdj1[133] sdi1[132] nvme0n1p1[1] nvme1n1p1[140] sdg1[139] sdf1[138] sdd1[137] sdc1[131] sdb1[130] sdh1[129] sda1[128]
530048 blocks super 1.0 [128/14] [UUUUUUUUUUUUUU__________________________________________________________________________________________________________________]
bitmap: 1/1 pages [4KB], 65536KB chunk
unused devices: <none>
[~] #
md9とmd13はNASのOSとログ用パーティションで、加えてQuTSが作成したスワップパーティションもあります（NVMe＋その他）
[~] # df -h | grep /dev/md
/dev/md9 493.5M 172.4M 321.0M 35% /mnt/HDA_ROOT
/dev/md13 417.0M 385.1M 31.9M 92% /mnt/ext
Lewis
10
私のセットアップにはQNAPのLogic/ビデオチュートリアル/おすすめを使いました。
同じ2つのSSD/M2をOSシステム用に使って、普通のHDDはストレージプール用にしています。
NASのセットアップ方法に関係なく、これらのパーティションは必ずこのように設定されます。（QTSとQutSの基本動作に必要です）
NA9D
12
@Lewis — QNAPの世界では「system（システム）」は「OS」とは同じ意味ではありません。System drive（システムドライブ）は、標準のストレージや一部のQNAPアプリケーション、デフォルトの共有（publicなど）が保存される場所です。ちょっとややこしいですが、OS自体はすべてのドライブに分散されています。NVMeドライブを使っても「OS」の動作が速くなるわけではありません。ただし、一部のアプリケーションの起動や、それらが使用するQNAPのデータベースは速くなります。
以下の例のようなスクリーンショットを共有していただけますか？詳しく確認したいと思っています。また、先ほど言及された 93.6 TB という数値がどこから来ているのかも教えていただけると助かります。ありがとうございます！
Lewis
14
こんにちは、Steve。
最初の投稿のスクリーンショットを見てください。赤枠で96GBと83GBのフォルダサイズの違いを強調しています（同じボリューム／プール上です）。
ありがとうございます。ご指摘いただいた共有フォルダ間の違いを確認しました。利用可能な容量が内部でどのように計算されているかを調査し、詳細が分かり次第こちらでご報告します。
SteveKo
16
こんにちは @Lewis、お待たせしてすみません。容量の計算方法を確認しましたので、ご説明します。
シン・プロビジョニングされた共有フォルダは固定サイズではありません。その容量は以下のように計算されています：
容量 = このフォルダで使用中のスペース ＋ ストレージプールの空き容量
つまり、この数字は「他のフォルダがデータを書き込まなければ、このフォルダがどこまで拡張できるか」を示しています。
あなたのフォルダでの計算例はこうなります：
| フォルダ |
使用済み |
＋ プールの空き容量 |
= 表示される容量 |
| HDP_Backups |
79.99 MB |
83.16 TB |
83.16 TB |
| Master |
9.99 GB |
83.16 TB |
83.17 TB |
| Media |
13.47 TB |
83.16 TB |
96.63 TB |
3つのフォルダすべてで、利用可能な空き容量は同じく83.16 TBです。Mediaだけが容量が大きく表示されているのは、すでに13.47 TBのデータが保存されているためです。つまり、これはバグではなく、容量が消失しているわけではありません。
ただ、この表示方法が混乱を招く可能性があることには同意します。社内でこの点を共有し、今後も情報の見せ方を改善できるよう検討します。ご指摘ありがとうございました — とても参考になりました。
Lewis
17
こんにちは、Steveさん。
フィードバックありがとうございます、感謝しています。
それと、表示方法が少し分かりにくいという点には同意します。スペースが多く使われているように見えるので、結局のところ総容量が大きいのかなって思ってしまいますね :)。
それでは。
NA9D
18
これがQuTS Heroのクールなところです。いくつかの共有フォルダにはとても小さい容量を設定していますが、他のフォルダにはプール全体のサイズを割り当てています。だから、とても柔軟に使えるんです。実際に持っている物理容量以上のスペースを割り当てているか？ はい、そうです。物理的な上限に近づいてきたときには注意が必要か？ はい、必要です。でも私の考えでは、それらはこの柔軟性に比べれば些細な問題です。
