最近の変更サイトマップ

RAID-Z Expansionのプリアルファ版コードとFreeBSDで使える格安10GbE NIC

本日はFreeBSD関連ネタを2本お届け。

RAID-Z Expansionの続報

2017年10月に鳴り物入りで発表されたRAIDZ expansion、続報が無くてどうなってんじゃい!と思って調べてみたら、昨年4月の時点でFreeBSDのPhabricatorでプリアルファ版のコードがレビューに出されてた。

といっても、この1年何のレビューも行われてなくて世に出るのはまだ先かも?という印象。それより気になったのはSUMMARYに書いてある何気ない一言「On disk format will change, you will have to destroy your pools.」である。まーじーかー。まぁ仕方ないか…。

FreeBSDで使える1万円の10GBASE-T NIC「EN-9320TX-E」

ここ2~3年で1万円前後の格安10GBASE-T対応NICが出回り、対応スイッチの価格もジリジリとではあるが下がり、ようやく10GbE環境が普及しだしそうな昨今、格安10GbEチップの定番AquantiaにはFreeBSD用ドライバが無くデーモン使いは地団駄を踏んでいた。

そんな中、たまたまFirst inexpensive 10GBase-T / NBASE-T card with FreeBSD drivers? | iXsystems Communityという記事を見つけ、それによればEdimax EN-9320TX-EがFreeBSDで使えるとのこと。10GBase-TだけではなくNBase-T対応なのも嬉しい。

このカードに搭載されているチップはTehuti TN9710Pってやつで、メーカーが公式にFreeBSD用のドライバを用意している模様。ダウンロードにはユーザー登録(無料)が必要っぽい。チップは違うけどLR-LINKのLREC6860BTも同じドライバで動くらしい。

FreeBSDで使える激安10GBase-T環境がなかなか出てこないことにしびれを切らし、光ファイバー系の方に行ってしまったワタクシには最早関係のないことですがね…。

InnoDB File-Per-Tableモードではinnodb_data_home_dirは無視される

MySQL/MariaDBにinnodb_data_home_dirというシステム変数がある。InnoDBのデータファイル置き場を明示する変数だが、InnoDB File-Per-Tableモードでは指定値が無視される。File-Per-Tableモードとは、InnoDBのテーブル毎にファイルを作成するモードの事でinnodb_file_per_table変数で制御可能である。MySQL 5.6.6以降でデフォルト有効になったため、innodb_data_home_dirは事実上意味がなくなってしまった。

よって、File-Per-TableモードではZFSのrecordsizeprimarycacheをストレージエンジン毎に最適化する、という手法が取りにくくなった。(DBごとにフォルダが作成され、その中にInnoDBやMyISAMのファイルが混在することになるため。)自分のメモも兼ねて最適とされるパラメータを下表にまとめる。

ストレージエンジン recordsize primarycache
MyISAM 8kBall
InnoDB(データ) 16kBmetadata
InnoDB(ログ) 128kBmetadata

参考サイト

FreeBSD 11.2-RELEASEでZFSのトップレベルvdevの削除機能が取り込まれてた

OpenZFS Developer Summit 2018を眺めてたら、Device Removalなるスライドを発見。タイトルの通りvdevの取り外しに関する機能である。

ご存知の通りZFSでは、一度プールに組み込んだデバイスの削除に非常に厳しい制約がある。プールのスケールアップは極めて容易な一方、スケールダウンは事実上不可能だった。しかしDevice Removalによって、ミラー構成のvdev限定ではあるものの削除が可能となる。

嬉しい人には嬉しいと思われるこの機能、なんとFreeBSD 11.2-RELEASEで既に取り込まれてた。11.2Rのmanから説明を引用してみる。

Removes the specified device from the pool. This command currently only supports removing hot spares, cache, log devices and mirrored top-level vdevs (mirror of leaf devices); but not raidz.

スライドの方にしか書いてないけど、この機能でミラー構成トップレベルvdevを削除するには、各vdevのashiftが同量じゃないと駄目らしい。ashiftはvdev単位での設定なので、デバイス追加時は注意が必要。

RAID-Zでも使えるようになってほしいけど、実装面ではRAID-Z Expansion頼みかしら…?こっちの進捗具合はどうなってんだろうなー。去年のちょうど今ごろRAID-Z Expansionに関する記事を書いたものの、とんと続報がない。FreeBSD 12で実装見込みとのことだったが、十中八九間に合わないだろうなー。現時点で12.0Rは12月頭のリリース予定だし…。

SambaとZFSで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する

同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。

まずはおさらい。

ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。

調査を進めると、ファイル作成時Sambaはファイル名の重複チェックのため、作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われるWindowsのファイル名規則(FS上は大文字/小文字を区別するが、一般的なファイルアクセス上は区別しないナンチャッテcase-preserving。この差はOSが吸収する。)と合わせるための、ファイル名を大文字ないし小文字に変換する処理がボトルネックのようだ。

プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、公式ドキュメントに「ディレクトリに大量のファイルがある特殊なケースでは、case sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる(CPU負荷が上がる)という挙動から、たぶん当たってると思う。

ではcase sensitive = yesにすれば万事解決かといえば、そうじゃない罠。

前述の通りWindowsはFS的にはcase-sensitiveだが、歴史的理由で表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字or小文字に変換して扱うアプリケーションが少なくない。例えば、本来のファイルパスはC:\Data\FILE.datにもかかわらず、アプリケーション内部では c:\data\file.datとしてアクセスすることが往々にある(自分もそういう処理をつい書いちゃうんだけど(;'∀'))。ローカルのファイルに対してなら、これでも問題はない。

しかし、サーバの共有フォルダに対しては、アプリから渡されたファイルパスをそのまま渡しているようだ。故にサーバ側がその辺を考慮した処理になってないと、ファイルが見つからないという事になる。Sambaのcase sensitiveオプションは、まさにその辺の制御を設定するオプションなのだ。これをyesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイルと見なされる、ということだ。アプリからすれば、\\Server\Data\FILE.datが見つからないということになる。これでは使い物にならない。

ではどうするか。ZFSのcasesensitivityプロパティの登場だ。

お察しの通りその名の通りのプロパティで、デフォルト値はcasesensitiveである。これをcaseinsensitiveにしてやればいい。insensitiveという名付けではあるが、挙動としてはpreservingのようだ。ちなみに、mixedというのもあるが、使いどころがよくわからない挙動なので指定しない方が無難(一応、Windowsを想定した挙動らしいんだけど…)。

本プロパティはFS作成時にしか指定できないため、Windows共有用のFSを新規に作り、Sambaで共有フォルダに仕立て上げるのがよいだろう。

Sambaがファイル名をキャッシュせずファイル作成毎に全舐めしてしているのは、恐らく対象フォルダに対する変更をSamba側で検知する仕組みがないからだと思う。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたり、別のファイルがリネームされたりする可能性があるため、キャッシュではファイル名のユニーク性を担保できないのだろう。

一方、ファイルシステムレベルなら、そのような変更の検出とアトミック性・ユニーク性が保証された素敵な仕組みがあるハズだから、アプリ側でファイル名の全比較を行うより効率的なんじゃねっていう目論見。

結論としてはSambaとZFSで以下の設定を行うと幸せになれる。ZFSじゃない人はスマン…

  • ZFS
    • ファイル共有用にcasesensitivity=caseinsensitiveなFSを作る
      zfs create -o casesnsitivity=caseinsensitive ztank/path/to/cifs

  • Samba
    • ファイル名の扱いをcase-sensitiveにする

      case sensitive = yes
      case preserve = no
      short preserve case = no

ZFSが自動マウントされない時はzfs_enable="YES"になっているか確認する

FreeBSDで起動時にルートプール以外のZFSファイルシステムが自動マウントされない時は、/etc/rc.confzfs_enable=“YES”しているか確認する。この指定がなくとも、ルートプール=システムが入っているプールは自動マウントされるので、なかなか問題に気づきにくい。自動マウントされないFSのcanmountmountpointプロパティを見ても問題ないし、原因が判るまで苦労したんだぜ★

インストーラに頼らず、手動でFreeBSDをインストールした場合なんかは特に注意が必要だ。

start.txt · 最終更新: 2016-05-07 17:46 by Decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0