RAID-Z Expansionがマージされてた＆ファイル名の最大長拡張PRが出来てた

もはや旧聞に属する話だが、2023年11月9日のRAID-Z Expansionのプルリクがついにmasterにマージされていた。コンセプトが発表されてから足掛け7年、実に長かった。なかなかインパクトのある機能だし仕方ないか。関係者の皆様お疲れ様でございました。

とはいったものの、実際にリリースされて使えるようになるのは、まだ先と思われる。リリース時期に関する最新情報は見つけられなかったのだけど、2021年時点のロードマップではOpenZFS 3.0で対応予定となっている。どんなに早くても2.3かなー？と思いつつ、どちらのバージョンのブランチもまだ存在しないのが現状。

加えてFreeBSDで使うには、ベースシステムに取り込まれるのを待たなきゃならんわけで、1年以上先なんじゃね？という気がしなくもない（まぁportsから入れればいいんだけども）。首を長くして待ちましょー

ついでにプルリク一覧を眺めていたら、ファイル名/ディレクトリ名の最大長を1023バイトに拡張する新しい機能フラグの実装があった⇒Longname: files/directories name upto 1023 bytes by tuxoko · Pull Request #15921 · openzfs/zfs

ZFSのファイル名/ディレクトリ名の最大長は255バイトとされているが、これはFILE_MAXだかPATH_MAX定数由来の制約らしい。これはUNIX系のファイルシステムにおける典型的な最大長で、通常はほとんど困らないサイズである。

ところが、ファイル名の文字コードとしてUTF-8を使うと話が変わってくる。UTF-8では1文字あたりのバイト数が1～4バイトと可変なので、ワーストケースで63文字しか格納できない。日本語の文字種はおおむね3バイトになるため、85文字で打ち止めとなる。

これでもFreeBSD、Linux単体で使う分にはさほど問題にならないと思うが、Windowsとファイル共有するとだいぶ困ったことになる。というのもWindows (NTFS)の最大長はUTF-16で255文字¹⁾なので、ZFSの255バイトでは全然足りんのです。まぁ、日常的に85文字を超えるファイル名を使うことは、少なくとも自分は無いけれど、それでも1年に2～3回くらいは困る場面があるんだよね…

上記PRとは別に(?)最大長拡張の議論もなされており、開発のコアメンバーも認識はしている模様。互換性はどうなるんだとか、最大255文字で決め打ちしてるアプリで扱おうとした時にどうなるんだとか、色々気になる点はあるが、是非とも実現されてほしいところ。

¹⁾

260文字という話もある。さらに近年は32768文字に拡張された

permalink · 2024-03-20 22:51 · Decomo · 0 Comments · Tags:

ファイルサーバで使ってたInte SSD DC S3500 240GB (SSDSC2BB240G4)がお役御免となった。購入記録を採ってるわけじゃないけど、たぶんこの時のSSD⇒Intel SSDSC2BB240G4 (DC S3500 240GB) のベンチマーク。のちに同じSSDを中古購入し、2台でRAID組んでWindows Serverのシステム領域兼記憶域階層のSSD層として使っていた。先に買った方、つまり当時のベンチマークがある方の使用時間は5年半ほどになる。

経年でどの程度パフォーマンスが変わったのか比較してみた。

	今	5年半前
S.M.A.R.T.
CrystalDiskMark 6
CrystalDiskMark 6	----------------------------------------------------------------------- CrystalDiskMark 6.0.2 x64 (C) 2007-2018 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 Sequential Read (Q= 32,T= 1) : 504.027 MB/s Sequential Write (Q= 32,T= 1) : 290.264 MB/s Random Read 4KiB (Q= 8,T= 8) : 312.603 MB/s [ 76319.1 IOPS] Random Write 4KiB (Q= 8,T= 8) : 263.048 MB/s [ 64220.7 IOPS] Random Read 4KiB (Q= 32,T= 1) : 311.353 MB/s [ 76013.9 IOPS] Random Write 4KiB (Q= 32,T= 1) : 253.603 MB/s [ 61914.8 IOPS] Random Read 4KiB (Q= 1,T= 1) : 21.859 MB/s [ 5336.7 IOPS] Random Write 4KiB (Q= 1,T= 1) : 66.980 MB/s [ 16352.5 IOPS] Test : 4096 MiB [I: 0.0% (0.1/223.6 GiB)] (x3) [Interval=5 sec] Date : 2023/10/11 0:36:19 OS : Windows 10 Professional [10.0 Build 19045] (x64) Intel DC S3500 240GB SSDSC2BB240G4 (2)	----------------------------------------------------------------------- CrystalDiskMark 6.0.0 x64 (C) 2007-2017 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 Sequential Read (Q= 32,T= 1) : 509.971 MB/s Sequential Write (Q= 32,T= 1) : 285.330 MB/s Random Read 4KiB (Q= 8,T= 8) : 312.081 MB/s [ 76191.7 IOPS] Random Write 4KiB (Q= 8,T= 8) : 271.718 MB/s [ 66337.4 IOPS] Random Read 4KiB (Q= 32,T= 1) : 271.167 MB/s [ 66202.9 IOPS] Random Write 4KiB (Q= 32,T= 1) : 252.995 MB/s [ 61766.4 IOPS] Random Read 4KiB (Q= 1,T= 1) : 33.345 MB/s [ 8140.9 IOPS] Random Write 4KiB (Q= 1,T= 1) : 94.851 MB/s [ 23157.0 IOPS] Test : 4096 MiB [D: 0.1% (0.1/223.4 GiB)] (x3) [Interval=5 sec] Date : 2018/03/01 1:41:52 OS : Windows 10 Professional [10.0 Build 16299] (x64) Intel SSDSC2BB240G4
CrystalDiskMark 8		なし
CrystalDiskMark 8	------------------------------------------------------------------------------ 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): 498.060 MB/s [ 475.0 IOPS] < 16791.21 us> SEQ 1MiB (Q= 1, T= 1): 404.748 MB/s [ 386.0 IOPS] < 2588.56 us> RND 4KiB (Q= 32, T= 1): 312.375 MB/s [ 76263.4 IOPS] < 418.26 us> RND 4KiB (Q= 1, T= 1): 26.909 MB/s [ 6569.6 IOPS] < 151.62 us> [Write] SEQ 1MiB (Q= 8, T= 1): 287.891 MB/s [ 274.6 IOPS] < 28986.44 us> SEQ 1MiB (Q= 1, T= 1): 288.068 MB/s [ 274.7 IOPS] < 3631.40 us> RND 4KiB (Q= 32, T= 1): 265.559 MB/s [ 64833.7 IOPS] < 492.03 us> RND 4KiB (Q= 1, T= 1): 75.663 MB/s [ 18472.4 IOPS] < 53.74 us> Profile: Default Test: 2 GiB (x3) [I: 0% (0/224GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2023/10/11 0:36:08 OS: Windows 10 Professional [10.0 Build 19045] (x64) Comment: Intel DC S3500 240GB (SSDSC2BB240G4) (2)	なし

ランダムリード・ライトが若干遅くなっているように見えなくもないが、4KiB 32QT1は速くなって良くわからん。240GBのSSDに対して93TB書き込んでるけど、問題になるような性能低下はなさそう。損耗率から計算すると残り280TBほど書き込めるようだ。

かたわれのSSDは結構深刻な状態で、ランダムライト速度が半分以下になってしまっている。

------------------------------------------------------------------------------
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):   496.475 MB/s [    473.5 IOPS] < 16845.23 us>
  SEQ    1MiB (Q=  1, T= 1):   399.525 MB/s [    381.0 IOPS] <  2621.80 us>
  RND    4KiB (Q= 32, T= 1):   312.067 MB/s [  76188.2 IOPS] <   418.81 us>
  RND    4KiB (Q=  1, T= 1):    30.675 MB/s [   7489.0 IOPS] <   133.11 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):   285.882 MB/s [    272.6 IOPS] < 29174.83 us>
  SEQ    1MiB (Q=  1, T= 1):   285.205 MB/s [    272.0 IOPS] <  3673.12 us>
  RND    4KiB (Q= 32, T= 1):    92.268 MB/s [  22526.4 IOPS] <  1419.45 us>
  RND    4KiB (Q=  1, T= 1):    43.706 MB/s [  10670.4 IOPS] <    93.19 us>

Profile: Default
   Test: 2 GiB (x3) [D: 0% (0/224GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2023/10/10 22:06:50
     OS: Windows 10 Professional [10.0 Build 19045] (x64)
Comment: Intel DC S3500 240GB (SSDSC2BB240G4)

セキュアイレースしても目立った改善は見られなかった。

Secure Erase前

Secure Erase後

S.M.A.R.T.はメディア消耗指標は問題なさそうだが、電源断保護失敗で異常が検出されており、そのためか電源投入回数が跳ね上がっている。

電源断保護失敗でパフォーマンス低下ってのも良くわからんけど、内蔵の電源回路が不調→コントローラリセット→すぐ回復→辛うじて書き込みは継続、って感じなのかなー？

若干の不安はありつつも、別サーバでZFSのRAID-1構成で引き続き頑張ってもらう予定。

permalink · 2023-10-13 23:50 · Decomo · 0 Comments · Tags:

中古の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のエラー訂正数とかも取れて、ガチのエンプラ用ドライブしゅごい。まだまだ知らないことだらけですわ。

permalink · 2023-10-09 23:04 · Decomo · 0 Comments · Tags:

RAIDZ ExpansionのPR作成の報を打ってから早2年、今度こそRAID-Z Expansionが来そうな雰囲気？である。

当時のPRは閉じられており、6月末にどういう訳か新しいPRに移行して作業が行われている。見てないけどOpenZFSリーダー会議で移行議論の概要が見られるようだ。

今回は着々とレビューとコミットが積み上げられている。RAIDZ Expansion自体は問題なく動いているようで、既に自前ビルドで使っている勇者もいるっぽい。今度こそマージされてほしい。

permalink · 2023-08-30 16:12 · Decomo · 0 Comments · Tags:

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)

また一つ、どーでもよいノウハウがたまってしまった。