HGST HUC101812CSS200のベンチマーク
中古のPowerEdget T330を買ったらHGST HUC101812CSS200が付いていた。仕様はこんな感じ。
| ドライブ名 | Ultrastar C10K1800-1200 |
|---|---|
| モデル名 | HUC101812CSS200 |
| 容量 | 1.2TB |
| セクタサイズ | 512n |
| 回転数 | 10520RPM |
| インタフェース | SAS 3.0 (12Gbps) |
| フォームファクタ | 2.5インチ, 15mm厚 |
実物のSASドライブを見るのも触るのも何気にこれが初めてだったりする。見せてもらおうか、SASドライブの性能とやらを！
（参考：ST2000LM007）
------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
[Read]
SEQ 1MiB (Q= 8, T= 1): 218.497 MB/s [ 208.4 IOPS] < 38209.34 us>
SEQ 1MiB (Q= 1, T= 1): 217.400 MB/s [ 207.3 IOPS] < 4816.72 us>
RND 4KiB (Q= 32, T= 1): 4.499 MB/s [ 1098.4 IOPS] < 28893.87 us>
RND 4KiB (Q= 1, T= 1): 2.191 MB/s [ 534.9 IOPS] < 1867.12 us>
[Write]
SEQ 1MiB (Q= 8, T= 1): 216.078 MB/s [ 206.1 IOPS] < 38515.68 us>
SEQ 1MiB (Q= 1, T= 1): 100.678 MB/s [ 96.0 IOPS] < 10410.15 us>
RND 4KiB (Q= 32, T= 1): 3.303 MB/s [ 806.4 IOPS] < 39386.47 us>
RND 4KiB (Q= 1, T= 1): 1.001 MB/s [ 244.4 IOPS] < 4085.40 us>
Profile: Default
Test: 1 GiB (x5) [H: 0% (0/1118GiB)]
Mode: [Admin]
Time: Measure 5 sec / Interval 5 sec
Date: 2023/10/09 0:26:57
OS: Windows 10 Professional [10.0 Build 19045] (x64)
Comment: HGST HUC101812CSS200 (SAS/1.2TB/10000RPM)
スクショの上がHUC101812CSS200で、下が参考用のST2000LM007の結果。後者はSMRなんでだいぶ不利な結果だと申し添えておく。
2.5インチでシーケンシャルリード、ライトが200MB/s超ってかなり速い気がする。ランダムアクセスもHDDにしては速めなような……さすがSASドライブってところ？まぁ、こんな単純なベンチでは何もわからんのだろうけど。ゼロフィルは1200243695616バイトを6624秒で完了ってわけで、平均182MB/sとなった。
それはそうと、SASってS.M.A.R.T.が取得できないんすな。
当初、PERC H330経由なのが原因かと思ってITファームでHBA化してもダメで、なんでぇ？と思いきや、そもそもS.M.A.R.T.はATA規格の仕組みなので、SASでは取得できないのが正しい、と。SASでドライブの状態が取得できないかと言えばもちろんそんなことはなく、KCQ (Key Code Qualifier)って仕組みで取れるそうな。UNIX系で有名なsmartmontoolsでは、ドライブごとにS.M.A.R.T.とKCQを使い分け、統一的な結果を表示してくれるため、SASドライブでもあたかもS.M.A.R.T.が使えているように見えるとかなんとか。実際のログはこんな感じ。
# smartctl -a /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.2.16-15-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: HGST
Product: HUC101812CSS200
Revision: FU29
Compliance: SPC-4
User Capacity: 1,200,243,695,616 bytes [1.20 TB]
Logical block size: 512 bytes
Formatted with type 2 protection
8 bytes of protection information per logical block
LU is fully provisioned
Rotation Rate: 10000 rpm
Form Factor: 2.5 inches
Logical Unit id: 0x5000cca02d7e9154
Serial number: xxxxxxxx
Device type: disk
Transport protocol: SAS (SPL-4)
Local Time is: Sun Oct 15 23:50:26 2023 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 43 C
Drive Trip Temperature: 50 C
Accumulated power on time, hours:minutes 49469:04
Manufactured in week 36 of year 2017
Specified cycle count over device lifetime: 50000
Accumulated start-stop cycles: 58
Specified load-unload count over device lifetime: 600000
Accumulated load-unload cycles: 2118
Elements in grown defect list: 0
Vendor (Seagate Cache) information
Blocks sent to initiator = 1590129651089408
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 10 0 39 257428 3792.083 0
write: 0 0 0 0 39447 5364.802 0
verify: 0 97 0 391 94932 795.533 0
Non-medium error count: 0
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Reserved(7) Completed 64 3 - [- - -]
# 2 Background short Completed 96 1 - [- - -]
Long (extended) Self-test duration: 8851 seconds [147.5 minutes]
ECCのエラー訂正数とかも取れて、ガチのエンプラ用ドライブしゅごい。まだまだ知らないことだらけですわ。
参考サイト
今度こそRAIDZ Expansionが来る？
RAIDZ ExpansionのPR作成の報を打ってから早2年、今度こそRAID-Z Expansionが来そうな雰囲気？である。
当時のPRは閉じられており、6月末にどういう訳か新しいPRに移行して作業が行われている。見てないけどOpenZFSリーダー会議で移行議論の概要が見られるようだ。
今回は着々とレビューとコミットが積み上げられている。RAIDZ Expansion自体は問題なく動いているようで、既に自前ビルドで使っている勇者もいるっぽい。今度こそマージされてほしい。
Proxmox VEで仮想ディスクを4Knデバイスとして扱う
Proxmox VEの仮想ディスクは、仮想マシンから512バイトセクタのストレージとして見える。正確にはQEMUのデフォルト挙動で、仮想環境における極々一般的な挙動なので普通に使う分には困らないし、意識すらしないだろう。
じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合や、4Kn環境をそのままP2Vした時のディスクイメージとかで困る。例えばパーティションテーブルなんかはLBA（セクタ番号）で管理されているので「パーティション1はセクタ1～262144」という設定は、4kセクタ環境なら1GiB、512バイトセクタ環境なら128MiBのパーティションを表すことになり、だいぶマズいわけですよ。（そもそも、GPTの配置自体が“LBA 1”と規定されているのでセクタサイズが合ってないとパーティションテーブル自体が正しく認識されない。）
というわけで、仮想ディスクを4Knとして認識させるには、/etc/pve/qemu-server/VMID.confをエディタで直接編集し、args:に下記の設定を追加してやればよい。
args: -set device.scsi0.physical_block_size=4096 -set device.scsi0.logical_block_size=4096
scsi0の0の部分はSCSI IDなので任意に読み替え可能で、複数のデバイスも同様に設定が可能。SATAやvirtio-blkも行けると思うけど未確認。
説明するまでもないだろうが、物理と論理のセクタサイズをそれぞれ4096に指定してあげればよい。物理4096, 論理512にすれば512e扱いになるかも？
上記設定を行った4KnのSSD×3、512eのHDD×5をRDMしてる当方の仮想環境では、想定通りに認識されている。
$ dmesg | grep sectors da0: 2969600MB (760217600 4096 byte sectors) da1: 2969600MB (760217600 4096 byte sectors) da2: 2969600MB (760217600 4096 byte sectors) da3: 17166336MB (35156656128 512 byte sectors) da4: 17166336MB (35156656128 512 byte sectors) da5: 17166336MB (35156656128 512 byte sectors) da6: 17166336MB (35156656128 512 byte sectors) da7: 17166336MB (35156656128 512 byte sectors) cd0: 998MB (511254 2048 byte sectors)
また一つ、どーでもよいノウハウがたまってしまった。
参考サイト
OPPO Reno A (CPH1983)をSDカードから復旧させる
遠方のかーちゃんのスマホが「ColorOS RECOVERY」状態で起動しなくなったとのこと。状況的にOS更新に失敗してブートできなくなったっぽい？
keep data（データ保持）の文言につられ、最初はOnline update(keep data)を試みたがダメ。No available firmware detected的なメッセージで進めなかった。
で、アレコレ調べたら、SDカード上のファームウェアイメージから復旧できるとの情報を発見。OPPO公式サイトにやり方は書いてるんだが、なぜか日本語訳がないので備忘録がてら手順を残しておく。
実際に試したのはOCN版Reno A (CPH1983/RAM 6GB/ROM 64GB)である。おそらく国内SIMフリー版として流通してるのと一緒かしら？
- 本体の電池残量を40%以上まで充電する
- https://support.oppo.com/jp/software-update/software-download/?m=Reno%20A から最新版のファームをPCでダウンロードする
- DLしたファームウェア（拡張子ozip）をSDカードの直下にコピーする（実際はどこでも良さそうだが一番アクセスしやすいところに置く）
- Reno AにSDカードを挿し電源ON。
- ここでリカバリモードに入らなければ、音量ダウンボタンを押しながら電源を入れる（明示的にリカバリ起動してみる）
Install from storageをタップし、続けてFrom SD cardをタップ- 3のファームウェアをタップ。確認メッセージが出たら「Yes」（ここはちょっと曖昧）
Installation successfulが出たらRebootをタップ
特に問題が起きなければ、データは残ったままスマホが復旧するハズ。
参考サイト
動的ライブラリをリンクしたシェルをログインシェルにしてはいけない
freebsd-updateなどでシステム更新の際、手順ミスでライブラリに不整合が生じることがある。Shared object “libxyzw.so.8” not found的なアレ。
これがログインシェルで起きると悲劇で、シェルの起動に失敗しシステムにログインできなくなってしまう。マシンに物理アクセス可能ならシングルユーザーモードなりで復旧可能だが、アクセス手段がsshとかしかなかったりすると詰むんですわ。お察しの通り、記事にしてるくらいだから実際に詰んだんですけどね。
実家サーバをfreebsd-updateが中途半端な状態で再起動したら、以下のような状態でsshログイン不可になってしまった。
$ ssh Decomo@192.168.0.1 Password for Decomo@: Last login: Sun Nov 6 13:06:52 2022 from 192.168.0.2 FreeBSD 13.1-RELEASE-p1 GENERIC Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier To change this login announcement, see motd(5). ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "fish" Connection to 192.168.0.1 closed.
ログインシェルの変更さえできればリモートアクセスできそうなものの、ssh経由で実現する方法はついぞ見つけられなかった。実のところ作業自体は11月の実家帰省中に行っており、目の前にマシンも液晶モニタもあるのに、D-Sub→DVI-Iのケーブルがなく、手も足も出なかったという。この度、ケーブル持参でようやく復旧できたというわけ。
そもそも、リモートアクセス手段しかない状態でシステム更新すんなよって話だが…静的リンクなbashであるbash-staticがPortsに存在する理由を“わからせ”られた。
というわけで、動的リンクなシェルをログインシェルにしてはいけない。どうしても設定する場合は、/bin/shをログインシェルとするリモートアクセス可能な緊急回復用ユーザー1)を作っておくと良いだろう。