2020.07.15
カテゴリ： ソフト開発日誌
まず買ったばかりの SMR HDD WD60EZAZ の sequential read 速度
実用上この速度は出ない。Trim された領域を read して出ている速度だ。File System を構成するならば、書き込んだことが無い領域を読むことは無い。読んだとしてクラスタ単位で操作する都合上で行われるはずだ。380Mbytes/sec は記憶媒体に律速されない AHCI SATA I/F - WD60EZAZ 間の最大転送速度を示していると考えられる。
Trim されているので何回 sequential read を繰り返してもほぼ同じ結果になると考えていた。繰り返してみると、転送速度に僅かな変動が見られたり、
瞬間的に(全容量に対して 2 ～ 3% 程度の範囲で)突如として転送速度が低下する現象がみられた。なぜ起きるのか良く分かっていない。
買ったばかりなのに媒体上に不安定な領域でもあるのだろうか？あるいは、HDD の firm ware に使われているアルゴリズムが動作履歴に左右されやすい時間オーダーになっているのだろうか？
先に行った random read/write に続けて、 sequential read /write をする。1 回目の sequential read は転送速度が進捗に対して 3 段階で変化した。各段階で最大転送速度と最小転送速度の差が大きい。比較的早い外周領域(0% ～ 33.3%)の範囲でも 90Mbytes/sec 差が有り、ほぼ 2 倍の振れ幅がある。振れ幅も密度に差が有り、allocation unit に沿うように転送速度が低下している様に見える。
段階の位置を見るとほぼ進捗の 33.3%, 66.6% の所で段ができている。いかにも意図的な位置だ。大規模な分割構造がある様に見える。LBA で綺麗に 3 分割されているということは、媒体上では外周では細い環、内周では太い環に分割されているのだろうか？ さらに細かく分割して最適化を追求するよりは動作検証をしやすくした様に見える。
1 回目の sequential write の転送速度(リンク先は続く sequential read を含む)
転送速度の変化も分割構造の前後で非対称だ。ヘッドを静定する時間がシーク方向に依存しているか、HDD 媒体上の allocation unit に未使用追記領域が無かった場合の空き検索アルゴリズムに方向性があるのか？
特定条件を満たしたときにデーターシートスペック 180Mbyte/sec を出しているようにも見える。何が何でもスペックを出すような構造を設計した？
分割構造の境界付近を「SMR 追記を早く行うための余剰領域」かつ「不良ブロックが発生した場合に代替利用する領域」にしているのだろうか？転送速度が速くなる進捗の幅が 3%, 5%, 5%, 3% となるので、何か意図的な割り振りを感じる。
おおよそ HDD に書き込んだデータのうち、15 ～ 20% 位が書き換えられると想定して、追記未使用領域を用意しているのだろうか？あるいは運用中に不良ブロックが発生したとして、最大 20% 程の代替領域があれば、運用継続可能と想定している？
そうだとすると SMR 方式は物理的な記録密度向上に対して、性能と耐不良ブロックのために払う代償も大きい。コスト競争が激しい製品で、差し引き 3 割り増しにもなれば大きいのも確かだ。
全領域を Sequential write すればスッキリするのだろうか？ sequential read 転送速度が向上し、CMR 方式 HDD と同等と見なせる程度に転送速度のブレは減るのだろうか？
2 回目の sequential read をしてみる。転送速度は全般的に向上した。分割構造の外周部で、205Mbytes/sec が出る様になった。転送速度のブレは依然として大きい。最外周の分割部分で転送速度の振れ幅は 70Mbytes/sec 程度、速度低下の機会はある程度減ったように見える。
中央、内周分割部分でも転送速度は 10M ～ 20Mbytes/sec 向上している。気持ち速度低下頻度が下がったように見える。
HDD 内の allocation unit をほぼカバーするような sequential write を行った積もりだった。write() システムコールに対して転送長 256Mibyte、Linux Kernel の BIO から AHCI driver 間の最大転送長は 30720kiByte (30Mibyte) にしている。HDD 上の allocation unit を綺麗に上書きで書き直せると期待していた。sequential read 転送速度の結果を見ると、依然として allocation unit に対して追記、溢れた場合は隣接 allocation unit に対する追記に振り替えている様に見える。
2 回目の sequential write をしてみる。転送速度が波打つ様なことは無くなった。最外周の分割構造で、upper 205M ～ 200Mbytes/sec, lower 160M ～ 155Mbytes/sec の転送速度が出ている。ある程度 block 配置状態が整理された様に見える。依然として、転送速度に振れ幅がある。
奇妙なことに真ん中の分割構造で、転送速度の下限が 130Mbytes/sec 程に安定して底打ちする現象が見られた。原因は分からず。勘ぐった見方をすると転送速度調整をしている様に見える。外周側の分割構造でも、転送速度の変化が進捗に対して 5Mbytes/sec になっている。HDD に乗ったチップ内の DMA controller 速度を媒体記録密度とは別の調整パターンで設定している？マーケティング / ブランディングと言った大人の事情？
WD60EZAZ は Trim command を受け付ける。何か変化があるから command として受け付けるのだろう。試してみるか。
2020.7.15 22:50 追記: 手順の流れを明確化した。
2020.7.18 追記:
SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果
SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う
実用上この速度は出ない。Trim された領域を read して出ている速度だ。File System を構成するならば、書き込んだことが無い領域を読むことは無い。読んだとしてクラスタ単位で操作する都合上で行われるはずだ。380Mbytes/sec は記憶媒体に律速されない AHCI SATA I/F - WD60EZAZ 間の最大転送速度を示していると考えられる。
Trim されているので何回 sequential read を繰り返してもほぼ同じ結果になると考えていた。繰り返してみると、転送速度に僅かな変動が見られたり、
瞬間的に(全容量に対して 2 ～ 3% 程度の範囲で)突如として転送速度が低下する現象がみられた。なぜ起きるのか良く分かっていない。
買ったばかりなのに媒体上に不安定な領域でもあるのだろうか？あるいは、HDD の firm ware に使われているアルゴリズムが動作履歴に左右されやすい時間オーダーになっているのだろうか？
先に行った random read/write に続けて、 sequential read /write をする。1 回目の sequential read は転送速度が進捗に対して 3 段階で変化した。各段階で最大転送速度と最小転送速度の差が大きい。比較的早い外周領域(0% ～ 33.3%)の範囲でも 90Mbytes/sec 差が有り、ほぼ 2 倍の振れ幅がある。振れ幅も密度に差が有り、allocation unit に沿うように転送速度が低下している様に見える。
段階の位置を見るとほぼ進捗の 33.3%, 66.6% の所で段ができている。いかにも意図的な位置だ。大規模な分割構造がある様に見える。LBA で綺麗に 3 分割されているということは、媒体上では外周では細い環、内周では太い環に分割されているのだろうか？ さらに細かく分割して最適化を追求するよりは動作検証をしやすくした様に見える。
1 回目の sequential write の転送速度(リンク先は続く sequential read を含む)
転送速度の変化も分割構造の前後で非対称だ。ヘッドを静定する時間がシーク方向に依存しているか、HDD 媒体上の allocation unit に未使用追記領域が無かった場合の空き検索アルゴリズムに方向性があるのか？
特定条件を満たしたときにデーターシートスペック 180Mbyte/sec を出しているようにも見える。何が何でもスペックを出すような構造を設計した？
分割構造の境界付近を「SMR 追記を早く行うための余剰領域」かつ「不良ブロックが発生した場合に代替利用する領域」にしているのだろうか？転送速度が速くなる進捗の幅が 3%, 5%, 5%, 3% となるので、何か意図的な割り振りを感じる。
おおよそ HDD に書き込んだデータのうち、15 ～ 20% 位が書き換えられると想定して、追記未使用領域を用意しているのだろうか？あるいは運用中に不良ブロックが発生したとして、最大 20% 程の代替領域があれば、運用継続可能と想定している？
そうだとすると SMR 方式は物理的な記録密度向上に対して、性能と耐不良ブロックのために払う代償も大きい。コスト競争が激しい製品で、差し引き 3 割り増しにもなれば大きいのも確かだ。
全領域を Sequential write すればスッキリするのだろうか？ sequential read 転送速度が向上し、CMR 方式 HDD と同等と見なせる程度に転送速度のブレは減るのだろうか？
2 回目の sequential read をしてみる。転送速度は全般的に向上した。分割構造の外周部で、205Mbytes/sec が出る様になった。転送速度のブレは依然として大きい。最外周の分割部分で転送速度の振れ幅は 70Mbytes/sec 程度、速度低下の機会はある程度減ったように見える。
中央、内周分割部分でも転送速度は 10M ～ 20Mbytes/sec 向上している。気持ち速度低下頻度が下がったように見える。
HDD 内の allocation unit をほぼカバーするような sequential write を行った積もりだった。write() システムコールに対して転送長 256Mibyte、Linux Kernel の BIO から AHCI driver 間の最大転送長は 30720kiByte (30Mibyte) にしている。HDD 上の allocation unit を綺麗に上書きで書き直せると期待していた。sequential read 転送速度の結果を見ると、依然として allocation unit に対して追記、溢れた場合は隣接 allocation unit に対する追記に振り替えている様に見える。
2 回目の sequential write をしてみる。転送速度が波打つ様なことは無くなった。最外周の分割構造で、upper 205M ～ 200Mbytes/sec, lower 160M ～ 155Mbytes/sec の転送速度が出ている。ある程度 block 配置状態が整理された様に見える。依然として、転送速度に振れ幅がある。
奇妙なことに真ん中の分割構造で、転送速度の下限が 130Mbytes/sec 程に安定して底打ちする現象が見られた。原因は分からず。勘ぐった見方をすると転送速度調整をしている様に見える。外周側の分割構造でも、転送速度の変化が進捗に対して 5Mbytes/sec になっている。HDD に乗ったチップ内の DMA controller 速度を媒体記録密度とは別の調整パターンで設定している？マーケティング / ブランディングと言った大人の事情？
WD60EZAZ は Trim command を受け付ける。何か変化があるから command として受け付けるのだろう。試してみるか。
2020.7.15 22:50 追記: 手順の流れを明確化した。
2020.7.18 追記:
SMR 記録の HDD WD60EZAZ ランダムアクセステスト結果
SMR HDD WD60EZAZ 買った直後に近い状態に戻す - trim(blkdiscard) を使う
お気に入りの記事を「いいね！」で応援しよう
最終更新日
2020.07.18 01:38:29 コメントを書く
[ソフト開発日誌] カテゴリの最新記事
-
Final Data Photo Recovery 9.0 - exFAT … 2024.06.06
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
© Rakuten Group, Inc.
