Steamマシン用に中古のIntel SSDSC2BB600G4を購入した。使用時間24506時間≒1021日、総書込量246775GB≒240TBという中々使い込まれたブツだが、この辺は商品説明に載ってたので納得ずくでの購入である。稼働時間の割に電源投入回数が22回と極めて少なく、240GB/日の書き込み量から推察するに、どっかの業務サーバで使われてたものだろうか。

本SSDはエンプラ用だけあってTBWは330もあるので、酷使されてなお一般用SSDと同等の耐久性が残っている事になる。メディア消耗指標を信じると残り1PBくらい書き込める計算だ。ZIGSOWのレビューによれば240GBモデルで905TB書き込めたそうなので、十分ありうる数値かと。

そんなわけで、使い込まれたIntel DC S3500 600GBの簡易ベンチマークなんぞを載せてみる。

-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
                           Crystal Dew World : http://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) :   502.399 MB/s
  Sequential Write (Q= 32,T= 1) :   491.719 MB/s
  Random Read 4KiB (Q= 32,T= 1) :   279.477 MB/s [ 68231.7 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :   257.936 MB/s [ 62972.7 IOPS]
         Sequential Read (T= 1) :   414.177 MB/s
        Sequential Write (T= 1) :   462.606 MB/s
   Random Read 4KiB (Q= 1,T= 1) :    29.766 MB/s [  7267.1 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :    67.414 MB/s [ 16458.5 IOPS]

  Test : 4096 MiB [C: 42.8% (103.8/242.6 GiB)] (x5)  [Interval=5 sec]
  Date : 2017/04/01 19:29:06
    OS : Windows 10 Professional [10.0 Build 10586] (x64)
    Intel DC S3500 600GB (240TBW)

目立った性能劣化もなく、至って普通の結果やね。

タイトルの通りでござる（ヽ´ω`）

FreeBSD 11が入っているSSDの入れ替え作業でパーティションを切り直していた際、例によってブートコードを書き込もうとしたら空き容量がないと怒られた。

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada15
gpart: /dev/ada15p1: not enough space

パーティション構成は前のSSDからの丸コピーであるからして、FreeBSD 10から11に更新した時にブートコードの更新をしていなかった、ないし今回のようにエラーが出ていたもののスルーしてたって事になる。FreeBSD 11にしてから5ヶ月経つというのに今まで気付かなかった……。古いブートコードでよく起動できてたなっていう。

念のため調べてみた所、やはりFreeBSD 11.0-RELEASEで/boot/gptzfsbootの容量が87KiBに増え、64KBのパーティションでは物理的に収まらなくなったようだ。エラッタにも、次のような記載がしっかりとなされていた（ヽ´ω`）

[2016-10-21] The size of the GPT enabled ZFS boot blocks (/boot/gptzfsboot) has increased past 64K. Systems upgraded from older releases may experience a problem where the size of the existing “freebsd-boot” partition is too small to hold the new gptzfsboot. FreeBSD 11.0-RELEASE Errata

さて、これはどうしたもんかね…。まぁどうしたもこうしたもパーティションを拡大するしかないわけだが、ブートパーティションはディスクの先頭にあり、その直後にシステム＆データパーティションが続いているので拡大の余地はないのだよ。このようなパーティション構成は極めて一般的だと思うし、とりわけFreeBSD 8/9時代にRootOnZFS環境を作って乗り継いできた人の殆どにとって頭の痛い問題なんじゃなかろうか。

ディスクの後方に空きがあるなら、そっちにfreebsd-bootパーティションに新設するってのが一番手っ取り早いかも？これはこれで凄い気持ち悪いのと、ブートローダの容量の壁（ディスクの先頭○GB以内に配置しないといけない系のやつ）にハマりそうな気がしなくもないが、2017年にもなって流石にもうないか？gpartのドキュメントによると、freebsd-bootパーティションは他のFreeBSD系パーティションの直前か直後に配置する必要があるそうなので、環境によっては完全に詰む可能性あり。

どうせ作り直すんだったらパーティションを超でっかくしたくなるが、最大545KBまでという制限もあるので要注意。起動時にfreebsd-bootパーティション全体がメモリに読み込まれるそうで、古のコンベンショナルメモリとの絡みから来る容量制限なのかしら？ゆとりの僕にはわかんないんです(・ω<)

これを機にUEFIブートに乗り換えるってのもありかなー。こっちはこっちでESPを確保しなければならないので、全く同じ問題を抱えてるわけですがね！

ちょっと前に家鯖が絶不調で、3.5インチHDD×4台のzpoolにアクセスするとフリーズする現象に見舞われていた。そのフリーズたるや生半可なものではなく、電源ボタン長押しすら受け付けず、コンセントぶっこ抜いた上に暫く放置してからじゃないと電源すら入らないというレベル。

すわ、電源ユニットが死んだか！？と思い早速手配し交換すべくサーバを開腹したところ、電源ファン前のフィルタが埃で目詰まりしていた。不調だったのは単に埃のせいで廃熱がままならず、サーマルプロテクションが動いてただけなんじゃないか疑惑。ま、もう電源買っちゃったし交換しときましたがね…。

こんな感じで、HDD×4台のRAID-Zは比較的短期間のうちに5～6度に渡る不意の電源断にさらされたわけだが、いくら堅牢なZFSとはいえ流石に耐えられなかったようで。回復不能なエラーが発生し、ファイルが1つお亡くなりになってしまった。

$ sudo zpool status -v
パスワード: 
  pool: zdata
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 64h6m with 2 errors on Sun Mar  5 06:42:20 2017
config:

	NAME         STATE     READ WRITE CKSUM
	zdata        ONLINE       0     0     2
	  raidz1-0   ONLINE       0     0     4
	    ada5p1   ONLINE       0     0     0
	    ada4p1   ONLINE       0     0     0
	    ada3p1   ONLINE       0     0     0
	    ada2p1   ONLINE       0     0     0
	logs
	  mirror-1   ONLINE       0     0     0
	    ada15p4  ONLINE       0     0     0
	    ada11p4  ONLINE       0     0     0
	cache
	  ada11p5    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /zdata/path/to/broken_file.wmv

scrub中にも電源断が起こったため、このような残念な結果になってしまったのだろう。初回scrubが出来ていれば、恐らくデータが壊れることはなかったと思う（個人的な経験に基づく推測）。

幸いにして死んだファイルはあ～ん♡な動画だったため大した影響はなかったが、バックアップの重要性を考えさせられる良い機会となった。……とは言ったものの、個人でTBレベルの現実的なバックアップって難しいんだよなぁ。HDDにせよLTOにせよ、その都度引っ張り出してくるようでは面倒になってその内バックアップしなくなるのは目に見えてるし、かといって繋ぎっぱなしじゃバックアップの意味が薄れるし。流行のクラウドは容量も然る事ながら、自分の管理外の場所にデータを置くってのが信用できないし。

あ～ん♡データの維持もなかなか大変である。

どこかからの放出品なのか、東芝のエンプラ向けHDD MG030ACA300が安かったので買ってみた。例によってCDMの結果を貼り付け。これまた例によってUSB 3.0変換での結果なので参考程度にオナシャス。

5860533167セクタを6時間42分でゼロクリアできたので、平均書き込み速度は118.6MiB/sという結果に。

速度は至って普通だが、ゼロクリア中の最高温度が60℃（室温26.5℃）と最近のHDDにしてはかなり熱め。アイドル状態で1時間放置しても53℃で、使ったケースがスライディング裸族で放熱性が悪いことを差し引いても熱い気がするなぁ。似たような条件でここまで高温になったHDD見たことないし。実運用では放熱をしっかり考慮する必要がありそう。実家の屋根裏サーバに使うつもりだけど、果たして大丈夫か！？

郵便の再配達で「他の郵便局の窓口でお受け取り」を選択した場合、配送履歴は「最寄局・最寄店送付」を経て「保管中」となる。

受け取る事ができるのは保管中になってからである。「送付」は受取指定したところまで配送中という意味なのでお間違えの無きよう…。なお、2017年2月7日現在の情報なので、遠い未来でこのページを見てる人は要注意。

国際書留には追跡番号がついてるのに、再配達は「お知らせ番号」で管理されてるのは何でなんだろう？二重管理で面倒なだけな気がしてならない…。