Monthly Archives: 11月 2018

[ZFS][zpool]zpoolのHDDをスタンバイモードにして消費電力を減らそう

我が家のNASサーバーはFreeBSDの入ったHP microserverである。
HP microserverにはHDDを4つ入れることができる。
たいへん便利なのだが、HDDが4つとも24時間動きっぱなしというのは精神衛生上、よろしくない。

実は、HDD4つのうちメインで使っているのはOSの入っているものと、Samba共有しているものの2つだけで、残りの2つはバックアップ用である。
少なくとも、残りの2本はバックアップを取得するときだけ動いてくれればよいので、それ以外の間は、HDD内円盤の回転を止めておきたい(スピンダウン)。

しかしSamba共有しているもの、バックアップ用のHDD(要するにOSの入っているHDD)以外はすべてzfsのzpoolを構成しているものである。
気軽にスピンダウンしてしまってよいものだろうか。

というのが調査を始めたきっかけである。

ああ、それと、頻繁に止めたり動かしたりすることがHDDに悪い、というのは重々承知の上。

結論(camcontrol standbyしろ)

結論から言うと、camcontrolでディスクを止めろ。
ディスク停止には、”standby”で。”idle”はやめておけ。

ATAデバイスのモード

ATAデバイスには4つのPower Modeがあり、条件によりそれぞれを行き来する。

  1. Active
  2. Idle
  3. Standby
  4. Sleep

Activeモードは、通常のデータのやり取りができる状態のこと。
それ以外は、Idle > Standby > Sleep の順に消費電力が下がり、反応速度も遅くなる。
詳細は以下書類(PDF注意)の4.18.3 Power modesを参照されたし。
http://www.t13.org/Documents/UploadedDocuments/docs2007/e07163r2-Comments_on_ATA8-ACS_revision_4a.pdf

これを踏まえて、任意のタイミング、あるいは、一定時間アクセスがないタイミングでIdle/Standby/Sleepに遷移させられれば目的が達成できる。
FreeBSDにおいて、Power modeの遷移にはcamcontrolコマンドを使う。
しかしその前に、zfs/zpoolで使えるPower Modeを調べねばならない。

zfsにはStandby

FreeBSD Forumにあるcamcontrol standby weirdnessというスレッドを見ると、以下のような記述がある。要するにStandbyを使えと。Idleだとzfsは当該ディスクをlost/defect/detachedと判断し、zpoolはdegradedになるか、unavailableになるという。

First of all: ZFS is fine with disks that go into STANDBY (accessing a zpool with disks in STANDBY will wake them up and ZFS will wait for it). ZFS cannot handle disks that are in IDLE mode (it considers the disks lost/defect/detached and the zpool will go degraded or even unavailable).

https://forums.freebsd.org/threads/camcontrol-standby-weirdness.59296/#post-340121

自分で試す気にはならないので、そのまま受け取る。

camcontrolによるstabdby操作

再びFreeBSD Forum。[AHCI] Spinning down ada(4) disksというスレッドの以下のポストを参照
https://forums.freebsd.org/threads/ahci-spinning-down-ada-4-disks.8841/page-2#post-98640

camcontrol standby adaXとすればよい。
またcamcontrol standby adaX -T sssとすれば、ただちにstandbyモードに移行し、その後もsss秒、アクセスがなければstandbyモードに移行することができる。
以下なら/dev/ada3をすぐにstandbyモードに移行させるとともに、20分の間アクセスがなければやはりstandbyモードに遷移するようタイマー設定している。今すぐはstandbyモードにしなくてもいいけど、タイマーだけ設定したい、という方法はないみたいだ。
[bash]# camcontrol standby ada3 -T 12000[/bash]
しかし上記のコマンドを実行したとしても、応答はない。なしのつぶてである。
standbyモードに移ったのか。かくなる上はHDDの回転数はいかほどか、耳を澄ますほかはない。
そんなご無体な、とgoogle先生に訴えたところ、FreeNASのフォーラムに以下のポストを発見。

Spinning Down your Drives and Checking Power States. (New Script)

上記にあるスクリプトを使えば、power modeを知ることができる。
本記事の末尾に転載しておく。
get_drive_status.shとして保存しておいた。
実行してみると;
[bash]$ sudo drivestatus.sh
ada0: FF
ada0: Running
ada1: FF
ada1: Running
ada2: FF
ada2: Running
ada3: FF
ada3: Running[/bash]
camcontrolでstandbyにしておいて再実行。
[bash]$ sudo drivestatus.sh
ada0: FF
ada0: Running
ada1: 00
ada1: Standby
ada2: 00
ada2: Standby
ada3: 00
ada3: Standby[/bash]
/dev/ada0はOSのあるHDDだからActiveですな。

運用方法(なにかが変)

よしこれで解決。
と思ったのだが、タイマー満了してもpower modeがstandbyに移らないのである。
その割に、そのディスクのディレクトリにアクセスすると、ファイル一覧の表示に待たされたりするのである。

先に引用した彼も同じことに悩んでいる。

But, then, when the disk is idle for > 1800sec (monitor with “zpool iostat 60”), it will not spin down. Huh?

https://forums.freebsd.org/threads/camcontrol-standby-weirdness.59296/#post-339820

この彼は、zpool iostat でディスクへの読み書きをモニターできるので、何分かアクセスがなければidleモードに移すスクリプトを書いた、と言っている。
常駐スクリプトを運用するのが面倒なので、cronジョブでstandbyさせるようにした。

結果

ワットチェッカーなんてものは持っていないので、単純に温度で確認した。
以下がそのグラフ。
ある日を境に、(OSのある/dev/ada0を除いて)温度が劇的に下がっていて、現時点ではまあ満足。

power mode確認スクリプト

[bash]#!/bin/bash
#
# Created by: Motorahead
# Date: 02/19/2016
# Checks For Running Status of Connected ADA Devices

# Look for Connected Devices
DEVICELIST=($( camcontrol devlist | grep -o ‘ada[0-9]’ ))

# Checks Drive Status, but only outputs relative field $10
STATUS(){
camcontrol cmd ${LIST} -a "E5 00 00 00 00 00 00 00 00 00 00 00" -r – | awk ‘{print $10}’
}

# Loop through each device found in ${DEVICELIST}
for LIST in ${DEVICELIST[@]}; do
echo -n "${LIST}: "
STATUS
# If the Output is 00, then the drive is in Standby. If it’s FF, then it’s active.
if [[ "$(STATUS)" == "FF" ]]; then
echo "${LIST}: Running"
elif [[ "$(STATUS)" -eq "00" ]]; then
echo "${LIST}: Standby"
else
echo "${LIST} is in a unrecognized state."
fi
done

[/bash]

[zfs][zpool] zfsの別ディスクへの移行

zpoolを容量の多い別HDDに移したのでメモ。
一度、同じようなことはやっているが、時間も経っているので。
最初に書いておくが移行元でまずscrubしておくこと。

流れとしては以下の通り。

  1. 移行元HDD
    1. scrubしておく
    2. snapshot
  2. 移行先HDD
    1. GPTでzfsのパーティションを作成
    2. zpool作成
  3. zfs send, recvで丸々コピー

以下、実作業に触れる前に補足。

方針についての補足

なぜmirrorにしないのか

上記の方法のほかには、追加のディスクをmirrorとしてzpoolに追加し、resilveringが終わったら旧ディスクを外してexpandという手がある。
が、その手は採らない。
実は、zpool statusをする都度、以下のメッセージが表示されていた。
旧ディスクは512Bセクタになっていると文句を言っているのである。
ディスクを交換するか、新Poolに移せ、と。
[bash] pool: vault
state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
scan: scrub repaired 0 in 8h3m with 0 errors on Sun Nov 4 04:16:39 2018
config:

NAME STATE READ WRITE CKSUM
vault ONLINE 0 0 0
ada1 ONLINE 0 0 0 block size: 512B configured, 4096B native
[/bash]
 

512Bセクタのpoolにmirrorを追加したら、やっぱり512Bになるんではと心配になったので、mirrorではなく新規ディスクの新規Poolに移す。

なぜディスクをまるっと使わずgptでパーティションを切るのか

zpoolは、わざわざgptパーティションにしなくても、ディスクをまるっと使ってzpoolに指定できる。
できるのだが、/dev/ada2なんて名前よりも、gptラベルでpoolを作成したいのである。
これの有利な点は、例えば当該ディスクの物理的な位置で名前を付けることができる点である。
具体的には、slot_1とか名前を付けておくと、ディスク交換の時に楽。
幸いにもFreeBSDにおいては、gptパーティションを切ってもディスクをそのまま使っても、いずれもパフォーマンスに違いはない。
それならgptにしましょう。

https://www.freebsd.org/doc/handbook/zfs-zpool.html
There is no performance penalty on FreeBSD when using a partition rather than a whole disk.
(2018/11/09)

ではさっそく作業を。

実作業(移行元ディスクの準備)

scrubをしておく。

zpool scrub で。
かなり時間がかかるので覚悟しておくように。
なおscrubは最低3か月に一回が推奨
https://www.freebsd.org/doc/handbook/zfs-term.html#zfs-term-scrub
recommended at least once every three months

作業直前にsnapshot。

pool内に複数のディレクトリがある場合、最上階層でsnapshot -r(recursive)すればよい。
たとえばvaultというpoolにchamber, itunesがある場合に;
[bash]vault
vault/chamber
vault/chamber@20170503
vault/itunes
vault/itunes@20170503[/bash]
※zfs list -t allの出力を一部削除したもの

zfs snapshot vault@20181109とすれば;
[bash]vault
vault@20181109
vault/chamber
vault/chamber@20180503
vault/chamber@20181109
vault/itunes
vault/itunes@20180503
vault/itunes@20181109[/bash]
※zfs list -t allの出力を一部削除したもの

となる。いちいち各ディレクトリ配下でコマンドを叩かなくてよい。

 

移行先作業

GPTパーティションの作成

以下のようなディスク
[bash]ada3 at ahcich3 bus 0 scbus3 target 0 lun 0
ada3: ACS-3 ATA SATA 3.x device
ada3: Serial Number WD-WCC7K3PU64NE
ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada3: Command Queueing enabled
ada3: 3815447MB (7814037168 512 byte sectors)[/bash]
GPTスキームをcreateし、全領域をfreebsd-zfsに割り当てる。
このとき、-lオプションでラベルを付ける。
同じくgpart showに-lオプションを付ければ名前を確認できる。
[bash]# gpart create -s GPT ada3
ada3 created
# gpart add -l slot_4 -t freebsd-zfs /dev/ada3
ada3p1 added
$ gpart show ada3
40 7814037088 ada3 GPT (3.6T)
40 7814037088 1 freebsd-zfs (3.6T)

$ gpart show -l /dev/ada3
40 7814037088 ada3 GPT (3.6T)
40 7814037088 1 slot_4 (3.6T)
[/bash]

zpoolの作成

/dev/ada3ではなくGPTラベルで指定する。
GPTラベルで指定するときは、gpt/<GPTラベル>というように指定する。
[bash]# zpool create warehouse gpt/slot_4
# zpool status warehouse
pool: warehouse
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
warehouse ONLINE 0 0 0
gpt/slot_4 ONLINE 0 0 0
[/bash]

プロパティの変更

zfsを作成する前に。
圧縮モードをlz4にする。lz4はCPU負荷の割には非常に効率が良いので積極的に有効にしたい。
また、atime(アクセスタイムの記録)もoffに。これがonだと差分snapshotが失敗するから、というのが一つと、これをoffにするとパフォーマンスが上がる(can result in significant performance gains)から。
zfs get <プロパティ名> で現在の値を取得。
zfs set <プロパティ名>=<値> で値のセット。
圧縮モードのプロパティ名はcompression、atimeはatime。
[bash]$ zfs get compression warehouse
NAME PROPERTY VALUE SOURCE
warehouse compression off default
$ zfs get atime warehouse
NAME PROPERTY VALUE SOURCE
warehouse atime on default

# zfs set compression=lz4 warehouse
# zfs set atime=off warehouse
$ zfs get compression warehouse
NAME PROPERTY VALUE SOURCE
warehouse compression lz4 local
$ zfs get atime warehouse
NAME PROPERTY VALUE SOURCE
warehouse atime off local
[/bash]

ディレクトリの用意とsend/recv

[bash]# zfs create warehouse/itunes
# zfs create warehouse/chamber
[/bash]
このとき、勝手にマウントされないようにすべきだった。-uを付ければよかったかな。
いずれにせよzfs set mountpointで後から変えられる。

sendに-Rを付けると、子孫やスナップショットもまとめてsendされる。
[bash]# zfs send -R vault/chamber@20181109 | zfs receive warehouse/chamber
# zfs send -R vault/itunes@20181109 | zfs receive warehouse/itunes
[/bash]
かかった時間、容量は以下の通り。うーむ。ちょっとかかったかな。
[bash] 991GiB 3:09:00 [89.5MiB/s]
1.10TiB 3:58:24 [80.3MiB/s]
[/bash]
このとき適当にhtopを叩いた結果。CPU負荷はそんなんでもないので、ボトルネックは別のところにあるように思われる。
[bash] 1 [||||||||||||||||||||| 47.6%] Tasks: 43, 0 thr; 2 running
2 [||||||||||||||||| 37.7%] Load average: 0.91 1.77 1.86
Mem[||||||||||||||||||||||||||||||||642M/1.84G] Uptime: 12:03:30
Swp[||||||||| 176M/907M]
[/bash]
なおCPUはAMDのTurionである。

compression=lz4の結果は.
プロパティused(HDD上の容量)とlogicalused(圧縮前容量)で調べられる。
[bash]warehouse used 2.00T –
warehouse logicalused 2.02T –
[/bash]
本来なら2.02Tのところ、2.00Tで済んでる。

これで引っ越し完了。

以上