NASに入れてるHDD,WD60EZAZ-RT WD Blueは、WDの６TBのHDDで、SMR方式。
全然気にしてなかったけど、SMRはプラッタ（磁気面）に情報を書き込むヘッドの幅より狭い間隔で書き込むことでプラッタに書き込める情報の容量を増やす方式だ。トラック（ 書き込まれた磁気情報 ）を重ねる様が瓦吹きの屋根を連想させるので、S（Shingled=瓦状）MRなんだそうな。バックアップの磁気テープの代わりにHDDを使うならシリアルアクセスなんだから、こんなんで良いんじゃねの？という感じで出てきたもののようだ。
だから、本来はPCどころか NAS にも向いていない方式です。
そのままではデータセンタとかのエンタープライズ向け専用になってしまうので、HDDでも多少は高速で書き込める外周部（おそらく今までのCMR方式で読み書きしてる）にとりあえず書いて後でコッソリと本来の位置にノンビリと書き込むなら性能は変わんないじゃね？ま、Unix系のHDDもメモリのある限りキャッシュして後からベタ書きしてるしので違和感はないし、一応HDDにかきこんであるから、メモリのみでキャッシュするよりは安心かもしれない。
それに今のHDDへのアクセスは物理的なセクタ位置（トラック、シリンダ、ヘッド）ではなくHDDのコントローラに論理セクタ番号を送るので、予備エリアの管理もHDDのコントローラ任せだから、こんな方式を採用してもHDD内部での話なのでマザボとかOSへの影響もなさそうだ。
実際、PCの前でファイルを保存する時はいつも外周部に書いてるなら、その分CMR方式より少し速く、HDDの空き容量が減って内周部へのアクセスが増えてくれば普通は遅くなっていくがその影響も少ないだろう。
でも、毎回外周部を使ってたら早めにエラーが出そうな気もする。
と云うことで、NASのHDDを引き抜いて見てみたら、やはり２つとも SMR方式のWD60EZAZだった。
引き抜いたせいかNAS起動後の認識が遅い様だ。
あ゛～！
ルータを変えたから、IPアドレスがセグメントすら変わってる。
ReadyCloudから認識しなおさないといけない。
それにNASの電源をOFFると、NASのバックアップボタンを押してReadyCloudで再認識させないとダメらしい。
で、やっとベンチしてみた。
参考：LinuxでもCrystalDiskMarkぽいディスクベンチマークしたい
最初は/tmpで実行したらディスクが足りないらしい。
fio: posix_fallocate fails: No space left on device
（中略）
Seq-Read 121.588
Seq-Write 189.19
Rand-Read-512K 1029.02
Rand-Write-512K 0
Rand-Read-4K 112.835
Rand-Write-4K 0
Rand-Read-4K-QD32 113.054
Rand-Write-4K-QD32 0
今度は、別パーティションの/homeで /tmp/fio.txtも/homeにコピってやってみると本気モードなんで時間が結構かかってしまう。
Seq-Read 150.118 Seq-Write 179.55 Rand-Read-512K 39.91 Rand-Write-512K 154.794 Rand-Read-4K 0.389 Rand-Write-4K 6.069 Rand-Read-4K-QD32 1.796 Rand-Write-4K-QD32 6.154
そうそう オワッタ後を dfで見ると
df -H Filesystem Size Used Avail Use% Mounted on udev 11M 4.1k 11M 1% /dev /dev/md0 4.0G 4.0G 0 100% / （中略） /dev/md127 6.0T 13G 6.0T 1% /home （略）
rootの下が１００％。さっきのエラーの原因だな。
もっともroot下が４GBしかないというのもいかがなものか・・・
# ls -l で/tmp （略） -rw-r--r-- 1 root root 1073741824 Feb 24 13:37 Rand-Read-4K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:37 Rand-Read-4K-QD32.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:37 Rand-Read-512K.0.0 -rw-r--r-- 1 root root 0 Feb 24 13:37 Rand-Write-4K.0.0 -rw-r--r-- 1 root root 0 Feb 24 13:37 Rand-Write-4K-QD32.0.0 -rw-r--r-- 1 root root 0 Feb 24 13:37 Rand-Write-512K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:37 Seq-Read.0.0 -rw-r--r-- 1 root root 1007206400 Feb 24 13:37 Seq-Write.0.0 （略） # ls -l で /home （略） -rw-r--r-- 1 root root 398 Feb 24 13:38 fio.txt -rw-r--r-- 1 root root 1073741824 Feb 24 13:38 Rand-Read-4K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:38 Rand-Read-4K-QD32.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:38 Rand-Read-512K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:41 Rand-Write-4K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:43 Rand-Write-4K-QD32.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:39 Rand-Write-512K.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:38 Seq-Read.0.0 -rw-r--r-- 1 root root 1073741824 Feb 24 13:39 Seq-Write.0.0 （略）
な惨状なんで消すと
df -h Filesystem Size Used Avail Use% Mounted on udev 10M 4.0K 10M 1% /dev /dev/md0 3.7G 1.8G 1.8G 50% / （中略） /dev/md127 5.5T 3.7G 5.5T 1% /home （略）
10GBぐらい使ってたのか。
ベンチ結果は 普通のHDD並みだから、HDD外周部のキャッシュを使い切っていない様だ。つまり普通のベンチが扱い１０GBより大きいサイズ（数十GB）らしい。
え？外周部のキャッシュを使い切るまでベンチするべきじゃないか？って？
今の/homeの使用量は3.7G。まだ外周部のキャッシュサイズより小さいので３２GB越えベンチをしても影響の具合は判らないだろう。
暫く経ってからNASのHDDのモータの起動御（ウーーン）や停止音（ｷﾞｨｰｰｺﾞｵｵ：ヘッド退避かな？）がしてたけど、これはSMR方式が外周部に残ってるキャッシュの情報を更新してるのかな？
普通、HDDの電源ってアクセスから５分ぐらいでOFFる設定してるけど大丈夫なのかな？SMRはHDDの電源入れっぱなしにするのが吉なのかもしれない。
仕事場のノートＰＣのＨＤＤも容量少ないけどＳＭＲなんだろうか？そう思うと腑に落ちる。もしＳＭＲなら小容量故に外周部キャッシュも小容量でWindowsUpdateでもキャッシュを使い果たして超低速もかもしれない。
ま、超低速といっても自分で測った訳では無く、ググった記事を見る分には３０分の１の速度になってしまうらしい。ただでさえランダムアクセスが終わってるのに、そこから３０分の１ってUSBメモリを下回りそう。
今時ＣドライブにＨＤＤなんて使うんじゃねーよ。
これからのHDDはＳＭＲ方式がデフォだからな！ということなのかな。
ま、テレビの外付け録画用HDD専用としては問題は無いのかもしれない。