経緯
nasのストレージを拡張しようとTR-004を購入したが、storage poolに追加できないということにセットアップ中に気付いたので、こういうのもう嫌だなと思ったので、10年以上ぶりにファイルサーバーを自分で立てることにしました。 たまたまbcachefsがLinux Kernelにmergeされたタイミングだったので、それ使ってます。
構成
- lattepanda alpha eMMC 64GB + RAM 8GB (部屋に転がってたsingle board)
- TR-004 (外付けHDDケース) 諸悪の根源のHDDケース USB接続
- https://amzn.to/3VNfknn: ロジテックの外付けHDDケース USB接続
- https://amzn.to/3VIN3y6:MARSHALの外付けHDDケース(おすすめ) eSATA接続
- https://amzn.to/43PfL2j: SATA <> eSATAケーブル
- https://amzn.to/49fhLSJ:M.2 E-key to SATA変換 ポートマルチプライヤ対応でたくさんつなげるために導入
- https://amzn.to/3TIQamV:M.2の長さが足りないので買い足したブラケット
HDDは処分しようと思ってた古いHDDを中心に部屋にあるものをより集めて構築した。MARSHALのケースはこういう用途で使うには価格と商品のバランスが良い。HDDのホットスワップも操作としては悪くない。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 2.7T 0 disk sdb 8:16 0 2.7T 0 disk sdc 8:32 0 2.7T 0 disk sdd 8:48 0 2.7T 0 disk sde 8:64 0 3.6T 0 disk sdf 8:80 0 3.6T 0 disk sdg 8:96 0 3.6T 0 disk sdh 8:112 0 2.7T 0 disk sdi 8:128 0 447.1G 0 disk sdj 8:144 0 447.1G 0 disk sdk 8:160 0 7.3T 0 disk mmcblk0 179:0 0 58.2G 0 disk ├─mmcblk0p1 179:1 0 1G 0 part /boot/efi └─mmcblk0p2 179:2 0 57.2G 0 part / mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 29G 0 disk └─mmcblk1p1 179:25 0 29G 0 part nvme0n1 259:0 0 476.9G 0 disk /mnt/nasdata
OSはubuntuの24.04の開発版がlinux kernel 6.8だったのでLTSになることを期待して導入
$ uname -r 6.8.0-11-generic
upgradeでインストールしたらコケたので非推奨
eMMCにOSをインストール。他はbcachefsのfilesystemに投入してます。検証用に3台 HDDを残して他は運用に投入
$ sudo bcachefs version 1.3.3
運用が面倒なのでrepositoryのものを利用している。
bcachefsメモ
目を通したサイト一覧
- https://bcachefs.org/
- https://bcachefs-docs.readthedocs.io/en/latest/index.html
- https://github.com/koverstreet/bcachefs
- https://wiki.gentoo.org/wiki/Bcachefs
- https://wiki.archlinux.org/title/Bcachefs
gentooとarchlinuxはまとまってて良かった。archlinuxの日本語版のサイトは更新が追いついてない部分がある。
まだ試してない
- subvolume
- encryption
- compression
- resize
構築はgentooのwikiに目を通したら大体迷わず使える。調査したところを個別に補足する
/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass> /dev/nvme0n1:/dev/sda:/dev/sde:/dev/sdf:/dev/sdg:/dev/sdi:/dev/sdj:/dev/sdk /mnt/nasdata bcachefs defaults,nofail 0 0
デバイスを一覧にしてfstabに :
で並べてmountしている。multiple deviceでのいい感じのmountはまだサポートされていない https://github.com/systemd/systemd/issues/8234
詳細は見てないが、再起動時にmountに失敗することがあるのでnofailをつけて無視するようにしてる。システム領域への利用はまだ避けた方が良い。
labelとgroup
デバイスにはlabelをつけてグループ管理が行える。よくある手順としては、ssdグループを foreground 及び cache targetに指定し、hddグループをbackground targetにするというもの。 こうするとssdに優先的に書き込み & cacheが行われ、hddにデータがssdから移動される。ような動作になる。
labelはファイルシステムへのデバイス追加後に任意のタイミングでも行える。柔軟性が高い…!!
durabirity
RAID対応の外付けケースでRAID1で構築済みの場合、durability=2をセットするとdevice自体が冗長性を持っているものとして扱われる。 replica=2指定でのファイルシステムの場合、durability=2のデバイスならほかへの複製は行われない扱いになる。 durability=0だとそのデバイスに保存されたデータはカウントされない。writethrough cacheとして利用したい場合に利用する。
RAID
RAID5,6はサポートされてない。仕組みとしてRAID1かRAID10になる。 replicas=2だとファイルシステム全体で2箇所に保存され冗長性が保たれる。
rebalance等の動作でdeviceが4台になると結果的にRAID10相当になる。というもの。replicasに3以上をセットしたときも単にデータの複製が増える形のようなので、冗長性を更に確保したい用途などでは良い選択肢かもしれない。
障害時
デバイスに障害が発生した場合
bcachefs device set-state failed /dev/sdb
該当のdeviceにfailedを追加するとdurability=0となり、replicaのカウントから除外される
bcachefs device evacuate /dev/sdb
デバイス取り外しの準備として、evacuateで対象に保存されてるデータの移動、冗長性の確保が他デバイスで確保される。
bcachefs device remove /dev/sdb
マウントできないとき
ファイルシステムに含まれる対象デバイスが故障などで認識できないときにdegrade扱いにしてmountを行う。degradedを指定するとデバイスが足りなくても取り敢えずマウントを試みてくれる。
sudo mount -t bcachefs -o degraded /dev/nvme0n1:/dev/sda:/dev/sdb:/dev/sdc /mnt/nasdata
- very-degraded データが欠落した状態でのマウントを行える
- nochanges デバイスへの書き込みを禁止してmountを試みる事ができる
degraded指定ならevacuateしファイルシステムから取り除けば復旧できる
fsck
userspaceで実行するとリソースを大量に消費する上に遅いので、mount時optionで指定するなどが望ましい。 fsck.bcachefsでも実行できる。
$ fsck.bcachefs --help bcachefs fsck - filesystem check and repair Usage: bcachefs fsck [OPTION]... <devices> Options: -p Automatic repair (no questions) -n Don't repair, only check for errors -y Assume "yes" to all questions -f Force checking even if filesystem is marked clean -r, --ratelimit_errors Don't display more than 10 errors of a given type -R, --reconstruct_alloc Reconstruct the alloc btree -v Be verbose -h, --help Display this help and exit Report bugs to <linux-bcachefs@vger.kernel.org>
感想
ファイルシステムに期待することをsimpleに実装されてるという印象。mdadmより操作しやすいのでファイルサーバーのデータ領域なら好み まだ足りてないmountなど課題もあるので現状システム領域やバックアップなしでの大容量ファイルサーバーのような運用は分けたほうが無難。 そのうちデバイスのperformance testやbadblocksの状況をみてdeviceを自動で取り除いたり、foreground/backgroundのそれぞれのgroupへデバイスの移動などができるようになってほしい。
device removeなどの操作はデータの退避が行われることがあるのか、応答に時間がかかることもあったので焦らないように運用には心のゆとりが合った方が良い。