■

Cでのエラーコードのベストプラクティスが知りたい

Google: error code definition in c

モジュールの場合はローカルのエラーコードを作るというのもありみたい。
C naming suggestion for Error Code enums - Stack Overflow

一日考えた結果、APIのソースコードファイルにstatic variableにエラーコードを持たせることにした。
Pythonのwrapperでもほぼ同様の形にした。

■

QNAPのiSCSIデバイスが不安定になった、その対応

QNAPのiSCSIを使ってLinuxからストレージをマウントしている。この機能はとても素晴らしいが、今回少し難しい障害が発生した。

QNAPでは4TBのHDD２枚をRAID1構成にして、ストレージプールを作り、全領域をiSCSIのひとつのLUNにしている。これをlinuxからSCSIデバイスとしてマウントしてる。1TBのSSDをキャッシュに設定している。

Linux側でこのデバイスI/Oエラーが発生した。QNAPのstrage managerでは一見HDDに問題が見られない。とりあえず、linuxとQNAPを再起動したものの、問題は解決せず。

QNAPのインターフェースをポチポチしていると、strage manager-> Disks/VJOBOD -> ストレージを選択肢し、Disk health -> Test　と進んでいくことで、S.M.A.R.Tを使ったテストができることがわかり、RAID1に使っているHDD２枚それぞれテストしてみると、一枚に問題が見つかったのでホットスワップで交換した。

次の日RAID1の再構成が終わったのを確認してiSCSIデバイスをマウントしてみたものの、再度障害が発生。ただなんとなく障害の度合いが少しマシ。例えば、昨日は一度障害が発生するとiscsiadmでLUNを切り離したあと、再度LUNにつなごうとしてもつながらなかったが、今日は同様の作業をしてみたらLUNにつながる。とりあえずQNAPとlinuxを両方再起動してみたものの、問題は解決せず。

もう、さらにできそうなことは、SSDキャッシュをやめることくらいなので、SSDをQNAPから外し、QNAPとlinuxを再起動。その結果、障害が発生しなくなった。ただ、問題が本当にSSDにあったのかというと、なんとなく違う気がする。いずれにせよ、SSDキャッシュを必要とするほどのデータアクセスはないので、要らないものは付けないに限るということでSSDなしで運用を続けることにする。

まとめ。

QNAPで障害が発生した。QNAPのストレージテストで、HDDが故障していることが確認できた。HDDを交換するものの障害が完全には治らず。最終的にSSDキャッシュを外すことで障害が治った。QNAPは異常に大きな負荷をかけない限り安定しているし、知らなかった便利な機能がビジュアルで見つかったのはありがたかった。

■

Emacs 80文字を超えた文字を強調する

どこから見つけてきたか忘れました（スミマセン）。

;; highlight charageter beyond 80 columns
(add-hook 'python-mode-hook
  (lambda ()
    (font-lock-add-keywords nil
      '(("^[^\n]\\{80\\}\\(.*\\)$" 1 font-lock-warning-face t)))))