2025/03/09(日)FreeBSD UFS2 SU+J ファイル削除はあまり速くない
どうも、I/O よりも kernel VFS 内部でのロック処理あるいは journal 処理などで時間かかってそう。
積年の /var/db/freebsd-update/files ディレクトリのファイルを削除しようとしたら思ったより時間がかかった。
時間かかるので途中で止めて time で時間を計ってみたところ、殆どが sys に時間を取られている。
もしかすると find -delete よりも xargs のほうが速いかも…？
SSD なら fsck を我慢できるので softupdate journal は不要かもしれない。
削除コマンド
root@:/var/db/freebsd-update/files# find . -mtime +365 | wc -l 468408 root@:/var/db/freebsd-update/files# find . -mtime -365 | wc -l 62895 root@:/var/db/freebsd-update/files# find . -mtime +365 -delete ^C root@:/var/db/freebsd-update/files# find . -mtime +365 | wc -l 114599 root@:/var/db/freebsd-update/files# time find . -mtime +365 -delete real 10m23.096s user 0m0.362s sys 10m21.413s root@:/var/db/freebsd-update/files#
I/O
FreeBSD の dirty buffer の定期書き出し以外では Read/Write はほぼ無し。root@:~# iostat ada4 1 | perl -pe 's/^/localtime() . " "/e' Sun Mar 9 14:58:09 2025 tty ada4 cpu Sun Mar 9 14:58:09 2025 tin tout KB/t tps MB/s us ni sy in id Sun Mar 9 14:58:09 2025 1 73 16.1 11 0.2 2 0 1 0 96 Sun Mar 9 14:58:10 2025 0 311 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:11 2025 0 173 4.0 2 0.0 1 0 50 0 49 Sun Mar 9 14:58:12 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:13 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:14 2025 0 173 4.0 2 0.0 1 0 50 0 50 Sun Mar 9 14:58:15 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:16 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:17 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:18 2025 0 173 4.0 2 0.0 1 0 50 0 50 Sun Mar 9 14:58:19 2025 0 287 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:20 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:21 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:22 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:23 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:24 2025 0 173 13.3 3 0.0 0 0 51 0 49 Sun Mar 9 14:58:25 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:26 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:27 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:28 2025 0 173 4.0 2 0.0 0 0 52 0 48 Sun Mar 9 14:58:29 2025 tty ada4 cpu Sun Mar 9 14:58:29 2025 tin tout KB/t tps MB/s us ni sy in id Sun Mar 9 14:58:29 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:30 2025 0 311 10.0 4 0.0 0 0 50 0 49 Sun Mar 9 14:58:31 2025 0 173 30.8 48 1.4 0 0 50 0 49 Sun Mar 9 14:58:32 2025 0 69 3.0 3 0.0 0 0 56 0 44 Sun Mar 9 14:58:33 2025 0 173 4.0 4 0.0 0 0 51 0 49 Sun Mar 9 14:58:34 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:35 2025 0 173 4.0 2 0.0 0 0 51 0 48 Sun Mar 9 14:58:36 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:37 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:38 2025 0 173 4.0 2 0.0 1 0 50 0 49 Sun Mar 9 14:58:39 2025 0 173 27.7 13 0.4 0 0 50 0 50 Sun Mar 9 14:58:40 2025 0 173 13.8 7358 99.2 0 0 55 0 45 Sun Mar 9 14:58:41 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:42 2025 0 173 4.0 2 0.0 1 0 50 0 49 Sun Mar 9 14:58:43 2025 0 173 4.0 2 0.0 1 0 50 0 49 Sun Mar 9 14:58:44 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:45 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:46 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:47 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:48 2025 0 173 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:58:49 2025 tty ada4 cpu Sun Mar 9 14:58:49 2025 tin tout KB/t tps MB/s us ni sy in id Sun Mar 9 14:58:49 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:50 2025 0 311 18.0 4 0.1 0 0 50 0 50 Sun Mar 9 14:58:51 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:52 2025 0 173 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:58:53 2025 0 375 4.0 2 0.0 0 0 51 0 48 Sun Mar 9 14:58:54 2025 0 173 4.0 2 0.0 1 0 50 0 49 Sun Mar 9 14:58:55 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:58:56 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:57 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:58:58 2025 0 173 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:58:59 2025 0 173 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:59:00 2025 0 173 4.0 2 0.0 0 0 52 0 48 Sun Mar 9 14:59:01 2025 0 173 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:59:02 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:59:03 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:59:04 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:59:05 2025 0 173 13.3 6 0.1 0 0 50 0 50 Sun Mar 9 14:59:06 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:59:07 2025 0 173 4.0 2 0.0 0 0 50 0 50 Sun Mar 9 14:59:08 2025 0 173 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:59:09 2025 tty ada4 cpu Sun Mar 9 14:59:09 2025 tin tout KB/t tps MB/s us ni sy in id Sun Mar 9 14:59:09 2025 1 175 4.0 2 0.0 0 0 51 0 49 Sun Mar 9 14:59:10 2025 0 311 4.0 2 0.0 0 0 50 0 49 Sun Mar 9 14:59:11 2025 1 228 27.5 3787 101.7 0 0 44 0 56 Sun Mar 9 14:59:12 2025 6 228 20.6 3455 69.6 0 0 23 0 76 Sun Mar 9 14:59:13 2025 9 269 0.0 0 0.0 0 0 2 1 98 Sun Mar 9 14:59:14 2025 0 173 0.0 0 0.0 0 0 0 0 99 Sun Mar 9 14:59:15 2025 1 184 0.0 0 0.0 2 0 11 0 87
tunefs
softupdate, soft update journaling, trim が on。と言ってもそもそも dirty buffer 書き出しはすぐ終わっているので、古いSSDでも I/O スピードは間に合っている。
root@:/var/db/freebsd-update/files# tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 2% tunefs: space to hold for metadata blocks: (-k) 1600 tunefs: optimization preference: (-o) space tunefs: volume label: (-L)
対象デバイス
root@:~# camcontrol identify ada4 | head -6
pass4: <SanDisk SD6SB1M064G1022I X230600> ATA8-ACS SATA 3.x device
pass4: 150.000MB/s transfers (SATA, UDMA6, PIO 512bytes)
protocol ATA8-ACS SATA 3.x
device model SanDisk SD6SB1M064G1022I
firmware revision X230600
root@:~#
root@:~# mount | grep ssdroot
/dev/gpt/ssdroot on / (ufs, local, noatime, soft-updates, journaled soft-updates)
root@:~#
root@:~# glabel status | grep ssdroot
gpt/ssdroot N/A ada4p3
root@:~#
ちなみに開始前 /var/db/freebsd-update/files の状況
2014年からの freebsd-update の残りかすが溜まっていたようだ。2014年は FreeBSD 10 くらいなので、それからずっと freebsd-update で更新してきたという事になる。
root@:/var/db/freebsd-update/files# find . -ls | less 4333839 88640 drwxr-xr-x 2 root wheel 45338112 3月 8 18:11 . 4334257 1344 -rw-r--r-- 1 root wheel 642298 11月 19 2014 ./8417c2444df4aa495c9ee7e953b9e24ff91a552b512ad7041ced4724f6482e63.gz 4334258 104 -rw-r--r-- 1 root wheel 51255 11月 19 2014 ./e43dbfcf12eb2d71aa998cb17b4e67bd5a52f40482524049a19ceb400019b739.gz 4333840 8 -rw-r--r-- 1 root wheel 1578 8月 23 2014 ./8d9d85c2c6d24a47cadc45dc1074d5c09ac1bfbda719598e28e84c20c4e3ffaf.gz 4333841 160 -rw-r--r-- 1 root wheel 79103 8月 23 2014 ./a9cda8f4ae23244290ad6a939b8a4c4ac28a353e166645948b0aef5cb943eac3.gz 4333842 80 -rw-r--r-- 1 root wheel 37036 8月 23 2014 ./a449f23323e5fab78d05cbd2477a744a31cacc8274d658ce45ab77772c96545a.gz
2024/03/30(土)FreeBSD gmirror 拡張方法メモ
容量の大きいHDDでメンバーを置き換えて、最終的に大きいミラーボリュームにする作業の手順メモ。
本メモ注意点
- 各手順では、ステータス表示コマンドなどは省略している。
- 本手順では、gmirror で構成したミラーデバイスに対してGPTパーティショニングをして使用している例となる。
- 個別HDDを先に GPT パーティションで区切って、各パーティションを gmirror のメンバーとする場合は若干手順が異なる。
本手順の例示構成 HDD1 : /dev/ada0 HDD2 : /dev/ada1 ミラーを構成するメンバー (/dev/ada0 + /dev/ada1) ↓ gmirror (mirorr/data2) ↓ GPTパーティション(gpart) ↓ UFS2ファイルシステム (mirror/data2p2)この構成で、ada0, ada1 を大きいHDDに置き換えて、ファイルシステムを拡張する。
- ディスク全体を1つのファイルシステムとするときは、GPT(MBR)パーティションを使用しての管理は必ずしも必要ではない。
- 高いサーバなら電源投入したままHDDを差し替えてもOKだと思うが、私の作業対象はそこまで高くないので、HDD交換時は電源を落として作業をしている。
- 高いサーバでもディスク交換時は spindown や eject、交換後の rescan などの手順が追加で必要かと思われる。
- IPL領域を含むディスクの場合（起動用ディスクがmirrorの場合）、1本目を交換してから電源を投入した場合に、2本目のディスクから正常に起動するかどうかはBIOS(or uEFI)の出来による。
- 1本目のディスクが真っ新なときにBIOSが2本目以降の起動領域を探してくれる必要がある。無理な場合は正常なディスクを1本目に、真っ新なHDDを2本目に入れ替えて起動する必要があるかもしれない。
作業時に取得しておいた方が良い情報など
面倒なので各手順の所には記載していませんが実際には各コマンドの前後に色々と情報を取得しています。ディスク情報関係
dmesg | grep ^ada camcontrol devlist geom disk list smartctl -a /dev/ada0 smartctl -a /dev/ada1 cat /etc/fstabミラーの情報関係
gmirror list gmirror statusパーティション情報関係
gpart show gpart listファイルシステムの空き容量等
df -h df -g df -iその他 GEOM 関連ログ
grep GEOM /var/log/messages
作業順
- 念のため 別のPCを使って GEOM 情報を削除する
- HDD交換１本目
- ミラーからメンバーを外す
- サーバ停止
- HDDを入れ替える
- サーバ起動
- ミラーにメンバーを追加する
- 同期完了を待つ
- HDD交換２本目
- ミラーからメンバーを外す
- サーバ停止
- HDDを入れ替える
- サーバ起動
- ミラーにメンバーを追加する
- 同期完了を待つ
- サイズ拡張
- gmirror サイズ拡張
- GPT パーティションサイズ拡張
- UFS2 ファイルシステム サイズ拡張
念のため 別のPCを使って GEOM 情報を削除する
やらなくてもたぶん大丈夫かなと思ってるが、新しく使用するHDD が過去にgmirror メンバーだった場合で、gmirror remove や gmirror destory し忘れていたHDDの場合に事故ると困るので念のためgeom 情報を強制的に削除する。
(新品HDDに対しては、もちろんこの作業は不要です)
手順は省略
dd で先頭100MB位を /dev/zero で上書きするだけ。
個別の手順で使用するコマンドの説明
ミラーからメンバーを外す
既存の gmirror のメンバーとなっているディスクを、ミラーから外す書式: gmirror remove ミラー名 メンバー名 例: gmirror remove -v data2 ada0
実行例 (gmirror remove)
# gmirror status data2
Name Status Components
mirror/data2 COMPLETE ada0 (ACTIVE)
ada1 (ACTIVE)
#
# gmirror remove -v data2 ada1
Done.
#
# gmirror status
Name Status Components
mirror/data2 COMPLETE ada0 (ACTIVE)
#
ミラーからメンバーを外し忘れてディスクを抜いて DEGRADED になったステータスを修正する
既存の gmirror のメンバーとなっているディスクを、ミラーから外し(remove)忘れてHDDを抜いて起動すると、ミラーのステータスが DEGRADED に変わる。
このステータスを正常扱いにするには、すでに抜いたHDDメンバーの事を忘れさせる必要がある。
書式: gmirror forgetミラー名 例: gmirror forget -v data2
forget すると、間違えて抜いてしまった場合に挿しなおしても、もう同期再開されない。
誤って forget した場合は、新しいメンバーとして insert する必要がある。
実行例 (gmirror forget)
# gmirror status data2
Name Status Components
mirror/data2 DEGRADED ada1 (ACTIVE)
#
# gmirror forget data2
# gmirror status data2
Name Status Components
mirror/data2 COMPLETE ada1 (ACTIVE)
#
ミラーにメンバーを追加する
書式: gmirror insert ミラー名 メンバー名 例: gmirror insert -v data2 ada1
実行例 (gmirror insert)
# gmirror status
Name Status Components
mirror/data2 COMPLETE ada0 (ACTIVE)
# gmirror insert -v data2 ada1
Done.
# gmirror status
Name Status Components
mirror/data2 DEGRADED ada0 (ACTIVE)
ada1 (SYNCHRONIZING, 0%)
#
gmirror サイズ拡張（最大サイズ）
ディスクの余っている最大サイズまで、gmirror のサイズを拡大する。書式: gmirror resize ミラー名 例: gmirror resize -v data2
実行例 (gmirror resize)
# gmirror list data2 Geom name: data2 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NONE GenID: 0 SyncID: 2 ID: 706164073 Type: AUTOMATIC Providers: 1. Name: mirror/data2 Mediasize: 4000787029504 (3.6T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e2 Consumers: 1. Name: ada1 Mediasize: 16000900661248 (15T) (略) # # gmirror resize -v data2 Done. # # gmirror list data2 Geom name: data2 State: COMPLETE Components: 2 Balance: load Slice: 4096 Flags: NONE GenID: 0 SyncID: 2 ID: 706164073 Type: AUTOMATIC Providers: 1. Name: mirror/data2 Mediasize: 16000900660736 (15T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r2w2e3 Consumers: 1. Name: ada1 Mediasize: 16000900661248 (15T) (略) #
GPT パーティションサイズ拡張
GPT パーティションでパーティションを管理している場合、ファイルシステムの拡張前にパーティションサイズを拡張する。(MBRパーティションでも同様)
書式: gpart show gpart resize -i インデックス番号 mirror/data2 例: gpart resize -i 2 mirror/data2
実行例 (gpart resize)
# gpart show
=> 40 31251759024 mirror/data2 GPT (15T)
40 4056 - free - (2.0M)
4096 125829120 1 freebsd-swap (60G)
125833216 28672 - free - (14M)
125861888 7688159232 2 freebsd-ufs (3.6T)
7814021120 23437737944 - free - (11T)
# gpart resize -i 2 mirror/data2
mirror/data2p2 resized
#
# gpart show
=> 40 31251759024 mirror/data2 GPT (15T)
40 4056 - free - (2.0M)
4096 125829120 1 freebsd-swap (60G)
125833216 28672 - free - (14M)
125861888 31125897176 2 freebsd-ufs (14T)
#
UFS2 ファイルシステム サイズ拡張
最後にファイルシステムを拡張する。サイズ未指定時は最大サイズを確保する。
書式: growfs マウントポイント名 growfs デバイス名 例: growfs /home
実行例 (growfs)
# growfs /home Device is mounted read-write; resizing will result in temporary write suspension for /home. It's strongly recommended to make a backup before growing the file system. OK to grow filesystem on /dev/mirror/data2p2, mounted on /home, from 3.6TB to 14TB? [yes/no] yes super-block backups (for fsck_ffs -b #) at: 7689935040, 7691762496, 7693589952, 7695417408, 7697244864, 7699072320, 7700899776, 7702727232, 7704554688, 7706382144, 7708209600, 7710037056, 7711864512, 7713691968, 7715519424, 7717346880, 7719174336, 7721001792, 7722829248, 7724656704, 7726484160, 7728311616, 7730139072, 7731966528, 7733793984, 7735621440, 7737448896, 7739276352, 7741103808, 7742931264, 7744758720, 7746586176, 7748413632, 7750241088, 7752068544, 7753896000, 省略 31077716928, 31079544384, 31081371840, 31083199296, 31085026752, 31086854208, 31088681664, 31090509120, 31092336576, 31094164032, 31095991488, 31097818944, 31099646400, 31101473856, 31103301312, 31105128768, 31106956224, 31108783680, 31110611136, 31112438592, 31114266048, 31116093504, 31117920960, 31119748416, 31121575872, 31123403328, 31125230784 #どうでもいいけど super-block backups 多すぎでは・・・？
2006/06/11(日)XFS on FreeBSD
http://lists.freebsd.org/pipermail/cvs-all/2006-June/175117.html 以降たくさん。
しかし基本的には Softupdates のみで、ディレクトリエントリから参照されていない余分な領域が確保される場合はあっても、その他の不整合はおきないわけで、XFSを導入するメリットって何だろう。偉い人向けには「ジャーナリングファイルシステム」という字面がウケが良いんだろうとは思うが。