このページの翻訳:
ソースの表示
最近の変更サイトマップ

XigmaNASの設定XMLで無理やりマウントポイントを指定する

XigmaNASの設定XMLファイルを書き換えて、無理やりマウントポイントの設定を行っちゃおうっていう、完全なるバッドノウハウ記事。

そもそもWebGUIの「ディスク > マウントポイント > マネージメント」で追加しろよって話なんだが、XigmaNAS 12.1.0.4 (Ingva/revision 7743)ではバグってるようで、マウント対象のディスクに何も表示されないのよ…。

過去のバージョンで設定したマウントポイントは、問題のバージョンに更新後も正常に動いているので、どうにか設定を流し込んで永続化できれば動くハズ……と、苦肉の策で思いついたのが、設定のバックアップ&リストアを使えばいいんじゃねっていう。

試してみたら上手くできたので、記録として残しておく。

1. XigmaNASのWebGUIの「システム > 設定のバックアップ」から設定XMLを書き出す。

2. 設定XMLのmounts要素の中にマウントポイント情報を書く。

    <mounts>
        <mount>
            <uuid>fe8974cf-548c-4aa9-91bf-80bb542cf153</uuid>
            <type>disk</type>
            <mdisk>/dev/da0</mdisk>
            <partition>p4</partition>
            <fstype>ufs</fstype>
            <gpt type="bool">1</gpt>
            <rawuuid>781bae78-8c56-11e7-b005-000c29de16ba</rawuuid>
            <devicespecialfile>/dev/ufsid/59a4be63ab3efa3e</devicespecialfile>
            <fsck type="bool">1</fsck>
            <sharename>sys</sharename>
            <desc>usb</desc>
            <accessrestrictions>
                <owner>root</owner>
                <group>wheel</group>
                <mode>0777</mode>
            </accessrestrictions>
        </mount>
    </mounts>
タグ 意味 備考
<uuid> たぶんXigmaNASがマウントポイントを管理するのに使うUUID
<type> デバイスの種類
<mdisk> マウント対象のデバイスファイル
<partition> デバイファイルのパーティション識別文字列
<fstype> ファイルシステムの種類
<gpt> たぶん対象のディスクがGPTであることを表す
<rawuuid> デバイスのUUID。gpart list デバイスで表示されるマウント対象のrawuuidを指定する。
<devicespecialfile> UFSの場合はdumpfs -l デバイスで表示されるパスを指定する。
<fsck> たぶん起動時にfsckするかどうかのフラグ
<sharename> /mntのマウント先ディレクトリ名
<desc> XigmaNASのマウントポイントの詳細情報
<accessrestrictions> アクセス制御
<owner>
<group>
<mode>
字面のとおり

4.「システム > 設定のリストア」で書き換えた設定XMLでリストアする。

とりあえず、目先の回避だけできればいいので、各要素の詳細は調べてない。重要なのはmdisk, partition, fstype, rawuuid, sharenameかな?devicespecialfileは指定しなくても動きそうな気もするけど、わかんにゃい。

早くバグが直りますように。

参考サイト

ZFSにdRAID(パリティ非クラスタ化RAID)が来る

OpenZFS 2.1で分散ホットスペアを実現する新たなプール構成「dRAID」がリリースされる見込みだそうだ。dRAIDによってホットスペアが抽象化され、障害発生時のプールのリビルドが高速化されるとのこと。実装の解説を見ると、Declustered RAIDそのものな気がするが、OpenZFSでは慎ましく“Parity Declustered RAIDZ”と言っているようだ。

現在のZFSでは、ホットスペアはプールの予備デバイスという扱いとなっている。伝統的なRAIDシステムと同じ考え方で、ホットスペアは障害が起きたvdevの物理デバイスを置き換え、vdev内でresilver(データの復元とパリティの再計算)が行われる。抽象化が進んでいるZFSシステムの中では珍しく、割と物理デバイスを意識させる実装となっている。

dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスがかかわり分散的にデータ/パリティとスペアブロックを読み書きするため、リビルド時間が短縮されるという構図のようだ。ちなみに、dRAIDのrebuildはチェックサムとパリティの検証を行わないため、resilverとは明確に違うらしい。

言葉だけだとイメージが付きにくいが、図を見れば簡単に理解できるかと。

「Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance」(Zhi (George) Qiao, Song Fu, Hsing-bung Chen, Bradley Wade Settlemyer) より編集して抜粋

HCIのストレージの挙動に近いかも?

RAID-Z同様、dRAIDのvdev構成を後から変えることは現時点では出来ないとされている。ただし、dRAIDのデータ構造からするに、いわゆるdRAID Expansionはそう難しくない気がするが果たして…?。コードソンで会おう!

参考サイト

FreeBSDのif_bridgeが5倍速くなるらしい

FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。

FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。

これはなかなかムネアツ。

一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。

参考サイト

PostgreSQLをDBドライバ経由で使った時の「SSL error」はスレッド周りを見直す

超絶ハマったのでメモ。

QtのPostgreSQLドライバ(QSqlDatabaseの“QPSQL”)で連続したクエリを大量に発行すると、ポスグレのログに以下のようなログが記録されて正しく実行されない現象に遭遇した。

2020-06-11 19:41:00.598 JST [2593] db@postgres STATEMENT:  DEALLOCATE qpsqlpstmt_10
2020-06-11 19:41:00.633 JST [3924] db@postgres LOG:  SSL error: decryption failed or bad record mac
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  could not receive data from client: Connection reset by peer
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  unexpected EOF on client connection with an open transaction
2020-06-11 19:41:00.645 JST [3925] db@postgres ERROR:  invalid input syntax for type timestamp: " " at character 77
2020-06-11 19:41:00.645 JST [3925] db@postgres STATEMENT:  EXECUTE qpsqlpstmt_16 (TIMESTAMP WITH TIME ZONE '2020-06-11T10:41:00.634Z', '[, )', FALSE, 0, 0, 0, 0, 0, 10, '', 0, 2020061110480001, 0, 1, 0, 10)
2020-06-11 19:41:00.646 JST [3925] db@postgres WARNING:  there is no transaction in progress
2020-06-11 19:41:56.266 JST [12492] db@postgres LOG:  SSL error: tlsv1 alert protocol version
2020-06-11 19:41:56.272 JST [12492] db@postgres LOG:  could not receive data from client: Connection reset by peer

Qt側のログは消失してしまったが、SSL SYSCALL Resource temporarily unavailableSSL SYSCALL error: EOF detectedといったエラーが出てDBとのコネクションが破壊され、トランザクションに失敗したりとかそんな感じ。

両方のログから読み取れるのは、クエリ発行時にプログラムとポスグレ間のSSL接続が通信途中で切れたり、データが破壊され変なクエリを実行しようとしたり、SSLの認証に失敗したりしてる。どーしてそんなことが起こるの?

それらしい単語でググると、postgresのSSLを無効にして解決とか出てくるけど、それって何の解決にもなってなくね?っていう。自分が加えた変更以後に発生するようになったので、原因は間違いなく自分ってことだけはハッキリしてる( ˘ω˘ )。

DBドライバとコネクションについて調べ、コードを追ってみたところ、スレッドをまたいで同一のDBコネクションを使ってたのが原因のようだった。一般的に、1つのデータベースコネクションを複数のスレッドで操作するのは禁じ手だそうで、Qtのドキュメントにも

A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported.
(訳:コネクションは生成されたスレッドからしか使用できない。コネクションのスレッドをまたぐ移動や異なるスレッドからのクエリ生成は非対応。)

という記述がある。でーびーしょしんしゃなのでしらんかった。

DB操作スレッドで作られ使われていたコネクションに対し、今回メインスレッドからクエリを発行する変更を加え、なおかつ、特定の操作を行うと両スレッドが入り乱れてコネクションを使うために、問題が顕在化したようだった。

というわけで、メインスレッド用に別途コネクションを用意し問題を回避した。解決ではなく回避なのは、かなりアレな設計で緊急措置的な対応だから…。元の構造がアレすぎていい対処方法が思いつかなかったの……。

Transcend TS32GMTS400 32GBのベンチマーク

ルータ用にと思って買った小型PCに、トランセンドのM.2 Type 2242なSSD MTS400シリーズの32GB、T32GMTS400が入っていたのでベンチなんぞを取ってみる。公式サイトによると、32GB版のスペックは読み込み200MB/s、書き込み40MB/s、90TBWの2DWPD(3年)となっている。

ディスクの状態は↓こんな感じ。新品で買ったPCの割に電源投入回数と書き込み量が多いような…。

ベンチは↓な感じ。

------------------------------------------------------------------------------
CrystalDiskMark 7.0.0 x64 (C) 2007-2019 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential 1MiB (Q=  8, T= 1):   279.169 MB/s [    266.2 IOPS] < 29939.73 us>
Sequential 1MiB (Q=  1, T= 1):   268.454 MB/s [    256.0 IOPS] <  3902.29 us>
    Random 4KiB (Q= 32, T=16):   107.224 MB/s [  26177.7 IOPS] < 19488.81 us>
    Random 4KiB (Q=  1, T= 1):    28.066 MB/s [   6852.1 IOPS] <   145.41 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):    53.481 MB/s [     51.0 IOPS] <153808.46 us>
Sequential 1MiB (Q=  1, T= 1):    53.065 MB/s [     50.6 IOPS] < 19666.44 us>
    Random 4KiB (Q= 32, T=16):    53.459 MB/s [  13051.5 IOPS] < 39015.26 us>
    Random 4KiB (Q=  1, T= 1):    52.687 MB/s [  12863.0 IOPS] <    77.35 us>

Profile: Default
   Test: 1 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/04/12 13:20:08
     OS: Windows 10 Professional [10.0 Build 16299] (x64)
Comment: Transcend TS32GMTS400

カタログスペック以上の速度は出ているが、最初期のコンシューマ向けSSDと比べても遅めですな…。128GB版でも書き込み160MB/s程度っぽいので、このシリーズはこんなものなのだろう。

参考サイト

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
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