おのたく日記

2021-01-16(Sat) [HDD][ZFS]HDD 4TB→8TB SRM換装結果 [長年日記] この日を編集

■ 1月11日の日記で換装して、1月12日の日記で一日目までの様子を書いた、Seagate Barracuda ST8000DM004の交換だけど、4日間掛かってやっとRAIDのrebuildが終わった。

# zpool status -v

pool: tank

state: ONLINE

status: Some supported features are not enabled on the pool. The pool can

still be used, but some features are unavailable.

action: Enable all features using 'zpool upgrade'. Once this is done,

the pool may no longer be accessible by software that does not support

the features. See zpool-features(5) for details.

scan: resilvered 2.43T in 4 days 02:42:08 with 0 errors on Fri Jan 15 20:06:22 2021

config:

NAME STATE READ WRITE CKSUM

tank ONLINE 0 0 0

mirror-0 ONLINE 0 0 0

sdc1 ONLINE 0 0 0

sdb1 ONLINE 0 0 0

cache

sda3 ONLINE 0 0 0

errors: No known data errors

前回は2日くらいで終わったのに、「永久に終わらないのではないか?」という恐怖を抱えながら、書き込みをしているDockerコンテナのサービスを止めながら。特に、ログで書き込みの多いGitLabサービスを止めて。なんとか、4日と3時間弱(99時間)掛かって終わった。

よくよく調べてみると、容量が4TBとかは、みんな瓦書きだと思っていたけど。前のHDDは瓦書きでなく、最近はSMRであることをメーカーも公表していて、今回が初めての瓦書き(SMR)だった。

で、時間が掛かっていたけど、どんな性能だったのかを、まとめとく

※おうちさーばは、熱が出ないようにATOM系のCPUだし、ZFSも2.0だけど全機能をまだenableにしていず、カリカリにチューニングしてあるわけではないので、ご参考。

■ 全体をスループットで説明

Throughput

右端の一番最初の谷は、前のHDDでscrubを実行して、ZFSの確認をしていた時の、整合性を取るための読み込み。130MB/sくらい出ている。

次の100MB/sくらいでている書き込みの山が、zfs replaceを始めて書き込みが開始された時、30分間くらい続いている。32GBくらいは、HDD上の一時キャッシュ領域が効いていた。

rebuildは、シーケンシャル書き込みだから性能は落ちないのかとも思いきや、ここまで、その後は、8MB/sくらいが続く。ついには0に近くなってしまったので、書き込みをしているであろうDockerコンテナのサービスを止めた。

サービスを止めて、少し性能が戻り、6時間後に30分くらい100MB/sを出すけど、また10MB/sくらいに戻る。このときになぜ100MB/s出たのかは不明。

そこで85%程度終わりゴールが見えてきたので、Dockerコンテナのサービスを再起動した。ただ、様子を見ていると、GitLabは書き込みが多いようなので止めた。

で、なんとか完了。

■ Utilization

Utilization

SMR HDDは、受け取ったデータを再構成して瓦のように重ねていくので、CPU利用率のようなUtilizationが上がる。

replaceを開始してから90%代。Dockerコンテナを止めるとreplaceの書き込みがはげしくなるからか100%近くなっていた。

replace終了後の通常運用でも20%程度で、結構、普段でも性能を消費していることが分かる。

ちなみに、従来のHDDだとscrubのような連続読み込みのようなときに90%とかになっていたけど、普段は10%未満。

■ レイテンシー

Latency

Logのグラフだからわかりにくいけど、青のIO wait timeいままでは5ms以下だったけど、SMRのHDDでのreplaceでは、ときどきだけど1s程度のプチフリがあり、運が悪いと最高5sとか掛かっている。5sは一日一回くらいだけどプチフリ程度ではない。

通常運転に入っても、10msとやっぱり遅い。Write WaitよりRead Waitの方が遅いのは何故?

[ツッコミを入れる]

2021-01-12(Tue) [ZFS] HDD換装続き [長年日記] この日を編集

■ 前回のzfs replaceは、40MB/sぐらい出ていたけど、今回は

scan: resilver in progress since Mon Jan 11 17:24:14 2021

759G scanned at 26.4M/s, 419G issued at 14.6M/s, 2.42T total

420G resilvered, 16.93% done, 1 days 16:05:13 to go

と２日近く掛かる見通し。新しいDISKのST8000DM004は、前の5900rpmから5425rpmに落ちていたり遅いのか? 瓦書きで書き込みは同じだと思うのだけれど。

Throughput per device

っていうか、最初100M/s出ていた書き込み止まってない? 少し様子を見ると、2M/sとか出ているときも有るみたいだし…

Utilization

Utilization を見るとHDDは精一杯働いているようなので、しばし様子を見る。

あ、HDDだけではなくて、ZFSもkernel 5.10で動かすために、2.0のexperimentalに上げたけどzpool upgradeしてないとか、結構怪しいかも

[ツッコミを入れる]

2021-01-11(Mon) [ZFS] HDD換装 4TB->8TB [長年日記] この日を編集

■ 10月21日の日記以来、だましだまし使ってきたSeagate Desktop HDD ST-4000DM000だけど、ついに

This message was generated by the smartd daemon running on:

host name: on-o.com

DNS domain: on-o.com

The following warning/error was logged by the smartd daemon:

Device: /dev/sdc [SAT], 16 Offline uncorrectable sectors

Device info:

ST4000DM000-1F2168, S/N:Z3123535Z, WWN:5-000c50-026c09fdb, FW:CC54, 4.00 TB

For details see host's SYSLOG.

You can also use the smartctl utility for further investigation.

The original message about this issue was sent at Sat Jan 9 19:44:02 2021 JS

Another message will be sent in 24 hours if the problem persists.

なんてメールが来るようになって、ZFS scrubでも

ZFS has finished a scrub:

eid: 33

class: scrub_finish

host: on-o.com

time: 2021-01-11 12:44:03+0900

pool: tank

state: DEGRADED

status: One or more devices has experienced an unrecoverable error. An

attempt was made to correct the error. Applications are unaffected.

action: Determine if the device needs to be replaced, and clear the errors

using 'zpool clear' or replace the device with 'zpool replace'.

see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P

scan: scrub repaired 248K in 08:16:54 with 0 errors on Mon Jan 11 12:44:03 2021

config:

NAME STATE READ WRITE CKSUM

tank DEGRADED 0 0 0

mirror-0 DEGRADED 0 0 0

sdc1 DEGRADED 7 0 14 too many errors

sdb1 ONLINE 0 0 0

cache

sda3 ONLINE 0 0 0

errors: No known data errors

となっていて復旧不可能。HDD自体は生きているけど、不良セクターが多すぎているらしい。もう、三年半以上使っているので寿命かな。

そこで、今回こわれたHDDを入れた20017年5月31日の日記や、今回生きている、2018年11月の日記、さらにそれの前の2013年12月28日の日記でもやっている定例業務だから、手慣れたもので、HDDを新しいSeagate Barracuda ST8000DM004に換装して

# zpool replace -o ashift=12 tank 9428551599581464311 /dev/sdc1

# zpool status -v

pool: tank

state: DEGRADED

status: One or more devices is currently being resilvered. The pool will

continue to function, possibly in a degraded state.

action: Wait for the resilver to complete.

scan: resilver in progress since Mon Jan 11 17:24:14 2021

197G scanned at 2.95G/s, 392K issued at 5.85K/s, 2.42T total

0B resilvered, 0.00% done, no estimated completion time

config:

NAME STATE READ WRITE CKSUM

tank DEGRADED 0 0 0

mirror-0 DEGRADED 0 0 0

replacing-0 DEGRADED 0 0 0

9428551599581464311 UNAVAIL 0 0 0 was /dev/sdc1/old

sdc1 ONLINE 0 0 0

sdb1 ONLINE 0 0 0

cache

sda3 ONLINE 0 0 0

errors: No known data errors

という感じでreplace中。

ashift=12 で4KBを明示したのは雰囲気

# zdb|grep ashift

ashift: 12

そもそも、tankは4KBセクターだった。

[ツッコミを入れる]

2021-01-07(Thu) [長年日記] この日を編集

■ [Debian][apparmor][squid] またCPU 100%

といっても、appmarmorを再インストールしたのに、「2020年7月8日の日記」の修正をすっかり忘れていて、またまた、squidGuardが立ち上がらなくなっていた。

今回は、AppArmor プロファイルの追加と作成を読んで、aa-logprof が単体起動できるし、auditログから判断できることを知ったので、

# aa-logprof -f /var/log/audit/audit.log

として、audit.logでDENIEDとなっている部分から解析させ、/tmp/tmp*に差分がてきたところで、Abortして、/etc/apparmor.d/以下を自動的に更新させず、その差分から手動で/etc/apparmor.d/usr.sbin.squidからincudeされる/etc/apparmor.d/local/usr.sbin.squidに追記

/usr/bin/squidGuard cx -> /usr/bin/squidGuard,

profile /usr/bin/squidGuard flags=(complain) {

#include

/usr/bin/squidGuard mr,

}

[/etc/apparmor.d/local/usr.sbin.squidより引用]

audit.logでもsquidGuardがDENIEDからALLOWEDに変わっていて、squidGuardが起動されていることを確認して、めでたしめでたし。

[ツッコミを入れる]

2021-01-02(Sat) 謹賀新年 [長年日記] この日を編集

■ 冬休みに入ったので、

BBTのAirSearchにBeta版なるものが出たので、ACexに、その対応とTypeScript 4.1対応など内部リファクタリングを一気におこなった。

年内には終わるかと思ったけど、2013年から7年間使っているソフトウェアなので、あちこちに手を入れる必要が有って、今日まで掛かって、やっとChromeウェブストアの審査に出すことができた。

$ git pull

Updating 2caa828..25f86c8

Fast-forward

README.md | 21 ++++--

build.sh | 3 +-

src/ACex.ts | 123 ++++++++++++++++++++---------------

src/AirSearchExtender.ts | 63 ++++++++++++++++++

src/Background.ts | 376 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------

src/CountResult.ts | 287 ++++++++++++++++++++++++++++++++++++++++++++-------------------------------------

src/CourseList.ts | 138 ++++++++++++++++++++++-----------------

src/MakeSlide.ts | 148 ++++++++++++++++++++----------------------

src/MessageUtil.ts | 21 +++---

src/Options.ts | 179 +++++++++++++++++++++++++++++++++------------------

src/PlayerExtender.ts | 117 +++++++++++++++++++++++++++++----

src/Popup.ts | 18 +++---

src/TabHandler.ts | 34 ++++++----

src/Types.ts | 76 ++++++++++++++++++----

src/_locales/en/messages.json | 18 ++++++

src/_locales/ja/messages.json | 20 +++++-

src/background.html | 1 +

src/countresult.html | 1 +

src/courselist.html | 1 +

src/manifest.json | 14 ++--

src/options.html | 7 ++

src/popup.html | 1 +

tsconfig.json | 8 +--

23 files changed, 1108 insertions(+), 567 deletions(-)

create mode 100644 src/AirSearchExtender.ts

なんだかんだで、半分は改造とは言え１週間で1Kステップ以上書いてる。

いまから公開用にcommit logをきれいにしたGitHub版つくらなきゃ

[ツッコミを入れる]

2021-01-01(Fri) 気分一新 [長年日記] この日を編集

■ YouTubeチャンネルに合わせて、「わんこ日記」を「おのたく日記」に変えてみる。

[ツッコミを入れる]

2020-12-03(Thu) [長年日記] この日を編集

■ [Debian][php][tt-rss] php-php-gettextの問題が解決

先日(11/29)の日記で、php-php-gettextパッケージがデグっているみたいということを書いたけど、無事に解決された。

php-gettext (1.0.12-2) unstable; urgency=high

* Team upload.

[ Sunil Mohan Adapa ]

* Fix issue with plurals patch breaking localization for non-English

locales. Closes: #976135.

-- James Valleroy Wed, 02 Dec 2020 22:27:45 -0500

[https://metadata.ftp-master.debian.org/changelogs//main/p/php-gettext/php-gettext_1.0.12-2_changelogより引用]

これで、tt-rssが、ちゃんと動くようになって良かった。

[ツッコミを入れる]

2020-11-30(Mon) [Debian][MySQL] mariadb 10.5でportがlocalhostしか開かなくなる [長年日記] この日を編集

■ 突然、おうちサーバのいくつかのサービスが不調になっていた。

とくにdockerコンテナ上のサービスがDB接続エラーを返してきていた。

「なんで突然?」と、接続できないということで、iptable周りを確認したけど、分からず。

[UPGRADE] mariadb-common:amd64 1:10.3.24-2 -> 1:10.5.8-3

[/var/log/aptidudeより引用]

と、金曜日にmariadbが10.3から10.5に上げたので

/etc/mysql以下を見ていて、

# Instead of skip-networking the default is now to listen only on

# localhost which is more compatible and is not less secure.

bind-address = 127.0.0.1

[/etc/mysql/mariadb.conf.d/50-server.cnfより引用]

というのを見つけて、bind-addressをlocalhostから変更して事なきを得る。

[ツッコミを入れる]

2020-11-29(Sun) [長年日記] この日を編集

■ [tt-rss] ログイン画面すら出ずtt-rssが真っ白画面

Nov 29 16:42:11 on-o.com php: [tt-rss] E_ERROR (1) (usr/share/php/php-php-gettext/gettext.php:325) Uncaught Error: Call to a member function evaluate() on null in /usr/share/php/php-php-gettext/gettext.php:325

[/var/log/messagesより引用]

とエラーが出ていたので、

[UPGRADE] php-php-gettext:amd64 1.0.12-0.1 -> 1.0.12-1

[/var/log/aptitudeより引用]

が原因のような気がするので、強制ダウングレード

dpkg: 警告: php-php-gettext を 1.0.12-1 から 1.0.12-0.1 にダウングレードしています

(データベースを読み込んでいます ... 現在 912998 個のファイルとディレクトリがインストールされています。)

.../php-php-gettext_1.0.12-0.1_all.deb を展開する準備をしています ...

php-php-gettext (1.0.12-0.1) で (1.0.12-1 に) 上書き展開しています ...

php-php-gettext (1.0.12-0.1) を設定しています ...

したら無事に動くようになった。

upgradeでphp-php-gettextが、でぐったのか? まあ、testingだけどね。

[ツッコミを入れる]

2020-10-21(Wed) [長年日記] この日を編集

■ [HDD] あり、SMARTのテストもパス

昨日のHDD壊れたかもとテストしていたのだけど

# smartctl -l selftest /dev/sdc

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.7.0-2-amd64] (local build)

=== START OF READ SMART DATA SECTION ===

SMART Self-test log structure revision number 1

Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

# 1 Extended offline Completed without error 00% 29737 -

# 2 Short offline Completed without error 00% 27040 -

# 3 Extended offline Completed: read failure 10% 27019 -

# 4 Extended offline Completed: read failure 10% 26953 -

# 5 Extended offline Completed without error 00% 21620 -

# 6 Short offline Completed without error 00% 12787 -

# 7 Extended offline Completed without error 00% 2366 -

# 8 Short offline Completed without error 00% 2346 -

2 of 2 failed self-tests are outdated by newer successful extended offline self-test # 1

代替セクターが効き始めたのか、エラー無く無事に終了している。

そういえば、#3, #4で起こっているリード失敗も治ったな。

■ [HDD] zfs scrubやSMARTセルフテスト中の性能

IOPSは、sdc TOSHIBA 8TBに比べて今回のsdc 4TBは半分

IOPS

sdcはzfs scrubで連続リードするとレイテンシーが落ちる。ちなみに緑のsdaはSSD

レイテンシ

SMARTの様子を見るとsmartctl_exit_statusが5:30ごろから0(正常)にもどっているのでセルフテストの途中で代替セクターが効くようになったのかな?

SMART

ちなみにscrubは２つのHDDの読み合わせなのでスループットは同じ

スループット

Utilizationは、遅いsdcが全力疾走していることがわかる

Utilization

全体みると、sdcのSeagate Desktop HDD.15 ST4000DM000 は、遅い。

けど、おうちさーばの通常状態では、全力出し切っていない。

[ツッコミを入れる]

おのたく日記 YouTubeも始めました→

2021-01-16(Sat) [HDD][ZFS]HDD 4TB→8TB SRM換装結果 [長年日記] この日を編集

■ 全体をスループットで説明

■ Utilization

■ レイテンシー

2021-01-12(Tue) [ZFS] HDD換装続き [長年日記] この日を編集

■ 前回のzfs replaceは、40MB/sぐらい出ていたけど、今回は

2021-01-11(Mon) [ZFS] HDD換装 4TB->8TB [長年日記] この日を編集

2021-01-07(Thu) [長年日記] この日を編集

■ [Debian][apparmor][squid] またCPU 100%

2021-01-02(Sat) 謹賀新年 [長年日記] この日を編集

■ 冬休みに入ったので、

2021-01-01(Fri) 気分一新 [長年日記] この日を編集

2020-12-03(Thu) [長年日記] この日を編集

■ [Debian][php][tt-rss] php-php-gettextの問題が解決

2020-11-30(Mon) [Debian][MySQL] mariadb 10.5でportがlocalhostしか開かなくなる [長年日記] この日を編集

■ 突然、おうちサーバのいくつかのサービスが不調になっていた。

2020-11-29(Sun) [長年日記] この日を編集

■ [tt-rss] ログイン画面すら出ずtt-rssが真っ白画面

2020-10-21(Wed) [長年日記] この日を編集

■ [HDD] あり、SMARTのテストもパス

■ [HDD] zfs scrubやSMARTセルフテスト中の性能