おのたく日記
YouTubeも始めました→
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にしていず、カリカリにチューニングしてあるわけではないので、ご参考。
■ 全体をスループットで説明
右端の一番最初の谷は、前の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
SMR HDDは、受け取ったデータを再構成して瓦のように重ねていくので、CPU利用率のようなUtilizationが上がる。
replaceを開始してから90%代。Dockerコンテナを止めるとreplaceの書き込みがはげしくなるからか100%近くなっていた。
replace終了後の通常運用でも20%程度で、結構、普段でも性能を消費していることが分かる。
ちなみに、従来のHDDだとscrubのような連続読み込みのようなときに90%とかになっていたけど、普段は10%未満。
■ レイテンシー
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
と2日近く掛かる見通し。新しいDISKのST8000DM004は、前の5900rpmから5425rpmに落ちていたり遅いのか? 瓦書きで書き込みは同じだと思うのだけれど。
っていうか、最初100M/s出ていた書き込み止まってない? 少し様子を見ると、2M/sとか出ているときも有るみたいだし…
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
なんだかんだで、半分は改造とは言え1週間で1Kステップ以上書いてる。
いまから公開用にcommit logをきれいにしたGitHub版つくらなきゃ
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)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== 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は半分
sdcはzfs scrubで連続リードするとレイテンシーが落ちる。ちなみに緑のsdaはSSD
SMARTの様子を見るとsmartctl_exit_statusが5:30ごろから0(正常)にもどっているのでセルフテストの途中で代替セクターが効くようになったのかな?
ちなみにscrubは2つのHDDの読み合わせなのでスループットは同じ
Utilizationは、遅いsdcが全力疾走していることがわかる
全体みると、sdcのSeagate Desktop HDD.15 ST4000DM000 は、遅い。
けど、おうちさーばの通常状態では、全力出し切っていない。
|