Linuxにおけるビデオフォーマットの取り扱い(H.264/H.265/VP9 WebM)

ビデオのファイルフォーマットについて

ビデオのファイルフォーマットは、

  • 動画部分
  • 音声部分
  • それをまとめる部分

の3パートからなる。
今回は

  • H.264+AACのMPEG-4 Part14(mp4)
  • H.265+AACのMPEG-4 Part14(mp4)
  • VP9+OpusのWebM

の3種類についての検討となる。

検討すべき点

画質とファイルサイズ

画質面では基本的に非圧縮が最良である、と考えて良い。
しかし、それではあまり巨大なデータになってしまうので、圧縮することになる。
非可逆圧縮を行えば画質は劣化する。これは、音声と同じ理屈である。可逆圧縮も存在するが、やはりサイズが大きく、現実的ではないとみなされている。

そもそもの話として、そんな巨大すぎるデータを扱うことは難しいため、動画素材が出力される時点でなんらかの圧縮がされているというのが普通だ。
それは、例えば録画ソフトだったり、ビデオカメラだったりだ。録画の場合、録画時に圧縮されるだけでなく、録画ソースがデジタル動画なら、その動画自体が既に圧縮されていて、2回目の圧縮をかけることになる。

いずれにせよ、非圧縮の映像ソースが手に入らないのであれば、映像ソースの状態が最良である。画質向上のための加工をすれば改善する可能性はあるが、それは普通ではない。

そこからさらにファイルサイズを小さくするために変換するか、あるいは取り扱いやすさのために変換するか、ということになる。
場合によっては、カメラから出力されるデータの圧縮形式を選べる、という場合もある。

つまりここで問題になるのは、ファイルサイズに対して画質の劣化がどれくらい抑えられるか、である。

速度

エンコード時に時間がかかるコーデックは、動画を変換してファイルとして出力する際に時間がかかる。

デコード時に時間がかかるコーデックは、再生が間に合わず飛んでしまうかもしれない。

ただ、実感としては、デコード時の所要時間の問題というよりは、ビットレートが高い動画は飛びやすい、という印象だ。
ただし、動画再生の重さには関係する。

ハードウェアアクセラレーション

デコードが重いコーデックであっても、ビデオカードがそのデコードを担うことができるのであれば、それは問題にならない。

これは、プロセッサ、ドライバ、そしてアクセラレーションの仕組みの全てがサポートしていなければ利用できない。

フォーマット

H.264

H.264(≈MPEG-4 AVC)は2003年に勧告された新しいフォーマットで、現在の主流といっていい。
MPEG-1から続く基本的な動画圧縮アルゴリズムを改良したもので、かなりの高圧縮でも目立った劣化が少ないことから主流となった。

高機能・高圧縮・高画質とメリットは大きいが、H.264を「使わない理由」といえば、エンコードに時間がかかりすぎるため、というのが一般的だ。

一般的なので、とりあえず迷ったらH.264で良いと思う。
LinuxではVDPAU/VA-APIにおいて、nVidiaグラフィックスにオープンソースまたはプロプライエタリのドライバ、さらにAMDグラフィックスにRadeonまたはCatalystドライバでH.264アクセラレーションがサポートされるというのは大きなメリットだろう。
どうもAMD APUでうまく動作してくれていないが。

nVidia Quadro 2000グラフィックスにLinux 4.3 + nvidia 1:352.53-1という構成のvdpauinfoはこのようになっている。

H264_BASELINE                  --- not supported ---
H264_MAIN                      41  8192  2048  2048
H264_HIGH                      41  8192  2048  2048
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---

Quadro 2000はFeature set Cなのでこうなっているのだろう。

非常に扱いやすい、お勧めできるフォーマットだ。
可搬性からいえば、MPEG-4のほうが上かもしれない。ちなみに、MPEG-4 Part2は、H.263がベースで、H.264と比べると劣っている。

H.265/HEVC

承認されたのが2013年という非常に新しいコーデックで、携帯向け映像配信から8kビデオまで幅広くターゲットにしている。
dアニメストアがH.265を採用していることで知られている。

同等の画質でH.264の半分の容量、という触れ込みだ。
非常に優れたフォーマットだが、新しすぎて結構厳しい。ハードウェア支援が追いついておらず、それでいて処理は非常に重い、というのが辛い部分でもある。
将来的には、H.265を置き換えていくのだろう。

H.265をサポートするFeature set FはGTX950/960のみで、TITANも含まない。QuadroシリーズはM6000まで含めて最大でもEまでだ。H.265が新しいフォーマットであることもあり、対応はまだまだ進んでいない、最新のカードでようやく対応がはじまったということなのだろう。

ちなみに、エンコード速度の差はあまりなかった。
というよりも、私の環境ではH.264の高品位エンコードが結構遅いので、H.265を若干軽い設定にしたこともあってか、2.1fpsでどちらも同じだった。

VP9 (WebM)

H.264はかなり複雑な特許関係になっているし、H.265はMPEG LAが特許を保有している。
こうしたことを嫌う人は、かなりいる。

Mozilla Firefoxは、以前mp4系ではなく、Ogg Theoraをサポートしていくことを表明したことがある。

Ogg Theoraについてはちょっと説明が必要だろう。Oggというのは、そもそもコンテナフォーマットで、任意の数の対応したコーデックを格納できる。一番有名なのは非可逆圧縮音声コーデックのVorbisで、OggコンテナフォーマットにVorbisを格納したものがOgg Vorbisだ。

そして、可逆圧縮音声コーデックのFLACを格納したものがOgg FLAC(FLACはOggに格納しないほうが普通)、動画コーデックのTheoraを格納したものがOgg Theoraだ(音声はSpeex, Vorbis, CELT, Opus, FLAC, OggPCMのどれか)。

このあたりは、Xiph.orgが開発したロイヤリティフリーコーデック/フォーマットで、OSSの一翼を担うと自負するMozillaなりのプライドだったのだろう。
しかし、そもそもOn2のVP3をベースにしたTheoraはあまり品質の良いものではなく、結局普及もしないままだ。オープンなのは良いことだが、Ogg Theoraをサポートしているプレイヤーも少なく、最初から影の薄い存在だ。

動機は似ているが、よりアグレッシヴに、技術的な主導権を握ろうとしたのがChromeの開発を行うGoogleだ。GoogleはChromeへの搭載とYouTubeでの採用の両面から働きかけている。

GoogleはコンテナフォーマットWebMを開発し、VPコーデックを開発してきたOn2を買収してその最新コーデックであるVP8を採用、音声フォーマットはVorbisをメインに採用してきた。
VP8に関しては特許問題があったが、最初から利用者に対する開放という方針は貫かれている。その後特許問題をライセンス契約締結によって解決し、自由に使えるようにした。

主導権を得るために、かなり献身的な振る舞いをしていると言ってもいい。品質面に問題があるTheoraに対して、VP8を採用するWebMは品質面でもH.264+AACのmp4に対抗できる存在だった。
現在においてもこの試み、つまりオープンソースによってデファクトスタンダードを塗替え、フォーマットを統一してリーダーボードを握るというのは依然として野心的だが、挑戦は続いているし、かつ悪くない話でもあり失敗もしていない。

そして、WebMの第二世代ともいうべきサポートが、VP9ビデオコーデックとOpusオーディオコーデックの採用だ。

VP9は、VP8に対して同一画質でビットレートを半分にする、ということなので、その目標はH.264に対するH.265と等しい。仕様がH.265と比べてもシンプルで、YUV444, 12bit色深度, アルファチャンネル, 深度チャンネル, 8kと機能はむしろ勝ってさえいる。
2011年にスタートしたプロジェクトで、後追いだったVP8とは違い、H.265に対して一歩前をいく状況で始まっている。

さらに、音声コーデックのOpusは、スピーチ向き音声フォーマットのSpeex、あるいは音楽向けコーデックのVorbisを越える存在として登場している。
IETFによって開発され、RFCで標準化され、リファレンス実装がBSDライセンスでリリースされている。Xiph.orgが手動するVorbisやFLACよりも、さらに文句なしにフリーだ。
音質がいいだけでなく、低レイテンシも実現している。ビットレートによって(場合によってはシームレスに)モードが切り替わり複数の仕様が混在するのは美しいとは言えないように思うが、実際に品質は素晴らしいのだから文句のつけようがない。
政治的紛争と無縁というわけではないのだが、Vorbisの次を叶えるコーデックではあるだろう。

つまり、完全に特許と制約に基づいたH.265+AACに対して、課題はあれども利用者としては自由に使うことが約束されているVP9+Opusでは、まずそこで魅力がかなり異なる。
しかも品質面でも優れている。

だが、決定的なディスアドバンテージもある。LinuxのVDPAUにおいてどころか、WindowsのPureVideoでさえ、VP9はもちろん、VP8もハードウェアアクセラレーションがサポートされていない。
VP8がサポートされていないということは、将来的にも大きな状況の変化がない限りはVP9も含め、WebMでのハードウェアアクセラレーションはサポートされないのだろう。
H.265のサポートはもう見えている。これは決定的だ。

比較

実際に比較してみた。

エンコーディングはだいたい同じくらいの時間がかかった。VP9+OpusのWebMが3.0fps出ていて1.5倍ちかく速かったが、それでもとても遅いのであまり意味はない。

サイズを見てみよう。

-rw------- 1 aki users 194571866 12月 10 10:59 moto-mad-01.h264.mp4
-rw------- 1 aki users 153719824 12月 10 17:14 moto-mad-01.h265-crf20.mp4
-rw------- 1 aki users  96287262 12月 10 09:13 moto-mad-01.h265.mp4
-rw-r--r-- 1 aki users 492912031  4月 16  2015 moto-mad-01.mov
-rw------- 1 aki users 215367319 12月 10 11:50 moto-mad-01.webm

H.264はCRF18、h265-crf20とWebMはCRF20、h265はCRF24だ。
ちなみに、元のMOVファイルはH.264+AC3である。

CRFが同一基準にならないようにしか見えないので、それぞれのコーデックで画質と容量の関係を探らなければ意味がなさそうだ。
実際、FFmpeg公式で、x265については

default CRF of 28. The CRF of 28 should visually correspond to libx264 video at CRF 23, but result in about half the file size.

と言っていたりする。色々やってみなければ分からないのだが、実際H.265の「劣化が少ない」は納得できる。H.264と比べてもそこは結構違う。H.264でCRFを上げていくとかなり乱れるので、ケータイ向けに用意したりするとはっきりと違ってくるのだ。

ちなみに、この生成物の感覚的な画質の比較でいうと

  • H.264は若干粗い。滑らかさが足りない
  • H.265は綺麗。CRF20かCRF24かの違いはほとんど分からない
  • WebM(VP9)はなめらかに見えるが、動きが激しいところではざらついて見える

結論

  • 今のところはH.264を使うのが可搬性を考えてもまとも
  • どうしてもファイルサイズを落としたい場合、H.265は結構いい
  • とりあえずVP9を使うメリットは、OSS派以外にはなさそう。エンドユーザーから見るとこだわりがない限り動機としてはかなり弱い
  • 将来的にはH.265に移っていくと考えて良いと思う
  • WebMがもっと普及して、ハードウェアアクセラレーションも対応してくれると嬉しい
  • そもそも、現在大抵の動画はH.264になってるし、普通の人がコーデックを選ぶ機会があまりないと思う
  • 昔のWMVやRM抱えてる人はWebMにしちゃうのもいいかもよ

FM2+Killer GodavariとXeon W3565+Quadro2000マシンを比べてみた

コンピュータの仕様

FM2+88X Killer

  • AMD A10-7870K APU
  • DDR3-1600 8GB RAM *4
  • 320GB 2.5inch HDD SATA2 (Windows System)
  • 256GB ADATA SSD SATA3 (Linux SYstem)
  • UEFI Boot

hp Z400

  • Intel Xeon W3565
  • nVidia Quadro 2000 Graphics
  • DDR3-1366 2GB ECC Unbuffered RAM * 2 + DDR3-1600 4GB Non-ECC Unbuffered RAM * 2 (DDR3-1066 driven)
  • 250GB Samsung 3.5inch HDD SATA2 (Windwos System)
  • 120GB Corsair SSD SATA3 (SATA2 Connection) (Linux System)
  • Legacy Boot

Windows Experience Indexによる比較

項目 FM2+Killer Z400
CPU 7.4 7.5
Memory 7.4 7.5
3D Graphics 6.8 7.0
2D Graphics 6.8 7.0
Disk 5.9 5.9

「Z400のXeon W3565+Quadro2000のほうがわずかに速い」というのは、ベンチマークの通りで面白みもない。

だが、見るべきところはある。

まず、メモリーもz400のほうが速い、ということだ。
メモリーはz400は1066で、FM2+Killerは1600で動作していて、FM2+Killerのほうが速いはずだ。
しかも、FM2+Killerはデュアルチャンネル構成だが、z400はトリプルチャンネルだが2種類を2枚ずつで機能していない。
それでもメモリアクセスはz400のほうが高速だという。

さらに、グラフィックスにしても、3DグラフィックスはDirectX9でテストされるが、OpenGLに特化していて3Dグラフィックスを得意としないQuadroであるにもかかわらず、Radeon R7を内蔵したGodavari APUに優るという。

AMDという第二の選択に対して、Intel+nVidiaという定番構成がいかに強力かがよくわかる。
理屈では見えてこない差があるようだ。

LinuxでのCPU処理

実用的かつ単純な方法として

time xz -zc image.iso > /dev/null

によって比較。これは、今のところxzが最も時間がかかっているためで、imageはtmpfs上にDebian jessie DVD 64bit(debian-8.2.0-amd64DVD-1.iso)。SystemRescueCDをnomodeset+nokmsboot+docacheでブートし、wgetでイメージを取得してテストした。つまり、イメージはRAM上にあり、ディスクアクセスは発生しない。

FM2+Killerは

1862.41s user 3.46s system 99% cpu 31:09.98 total

対するZ400は

1743.0s user 1.92s system 99% cpu 29:09.72 total

やっぱりZ400のほうがやや速い。

xzはコアをフルに使い切れないことが多いのだが、日常的にすることで、全てのコアを使い、かつ負荷や結果が一定になるものが思い浮かばず、xzにした。差自体は恐らくこんなものだと思う。ImageMagickでは極端に差が出るが、およそこれくらいの割合でZ400のほうがいつも速い。
プロセス数の多い処理はZ400のほうが有利か。

LinuxのGPU処理

OpenGLの処理速度を比較するため、Linux上でのベンチマーク。

Windows上の普通のベンチマークとは色々と事情が変わってくる。

  • LinuxではDirectXは使えないため、OpenGLを使う
  • いずれもメーカー提供のプロプライエタリドライバを使用するが、Windowsドライバと比べるとかなり性能が低い。特にAMD Catalystは出来が悪い
  • Quadroは元々OpenGLグラフィックスであり、AMD APUは一般向けであるためDirectXグラフィックスである

テストはUnigine Heaven Benchmark 4.0を使用した。
なお、再起動した上で新規ユーザーでテストすることで差異を可能な限り埋めてはいるが、CatalystがLinux 4.2ではうまく動かないため、Linux 4.1を使用している。

いずれもプロブライエタリドライバを使用し、ディスプレイはFHDの1台にセッティングした。

  • Render: OpenGL
  • Mode: 1920×1080 fullscreen
  • Preset: Custom
  • Quality: Low
  • Tessellation: Disabled
Term FM2+Killer Z400
Platform Linux 4.1.12-1-MANJARO x86_64 Linux 4.2.5-1-MANJARO x86_64
CPU Model AMD A10-7870K Radeom R7, 12 Compute Cores 4C+8G (3892MHz) x4 Intel(R) Xeon(R) CPU W3565 @ 3.20GHz (3200MHz) x8
GPU Model AMD Radeon(TM) R7 Graphics (1024MB) x1 Quadro 2000 PCI Express 352.55 (1024MB) x1
FPS 22.4 26.0
Score 563 655
Min FPS 7.7 17.7
Max FPS 47.0 39.8

FM2+killerも体感よりはかなりがんばっている。
FM2+Killerはビデオ再生がひどいため、まともに動くとは思わなかったのだ。

Max FPSは大幅に逆転している。
だが、全体にはWindows Experience Indexの結果と比べて、さらにもう少し差が開いた印象ではある。

LinuxではCatalystドライバに不具合がかなり多いため、数値よりも快適性には大きな隔たりがある。

しかし、ドライバの出来と、openGLに特化したQuadroであることを考えると、もっと差が開いて然るべきだったけれど、意外とGodavariが健闘した。

結果を受けて

FM2+Killerの構成は、もともとはKaveri(A10-7700K)で、およそ19万円かかったが、これは大容量メモリと、多数のハードディスクのためだ。

例えば、TSUKUMOのAMD A10-7870K Black Edition BOX スペシャルセットが34344円(2015-11-07現在)となっている。
実際は、4GBx2 RAMであること、Mini-ITXマザーボードであることを考えれば、TSUKUMOで計算するとFM2A88X Killerが12480円、A10-7870Kが18274円、W3U1600HQ-8GC11(8GBx2)が12150円で42904円。
PCケースDefine R5が13014円、Seagate STT1000DM003が5992円、慶安 静か KT-S400FXAが6151円なので、全体では68061円になる。

高機能を狙った構成なので、もっと安く上げるのであれば、4.5万円くらいで収まる可能性もあるだろう。だが、だいたいそのあたりであり、別の見方をすればPC1台組むのに必要なコストがそれくらいであるとも言える。
A10-7870Kはミドルに迫るくらいの性能を持ってはいるが、素晴らしく快適な性能でもない。性能的には中途半端だが、コストパフォーマンスは良い、という微妙な立ち位置だ。
「下の上」である。

しかし、「微妙な割に便利」でもある。
オフィススイートななどの基本的な事務、1080p動画再生を含むインターネット体験、そこまで本格的でなければ3Dゲームだってできる。
つまり、一般的なユーザーのニーズを満たすことができるのだ。

ただし、Windowsであれば。Linuxでは、そのパフォーマンスが十分に発揮できず、実際Windowsで不足を感じないのに、Linuxでは随分ひっかかる。

加えて、「性能はいらないが機能が欲しい」というユーザーにも安価に応えられるのは大きい。例えばトリプルヘッドディスプレイや、4kディスプレイが欲しい、eSATAが欲しい、USB3が欲しい…といった要求にも、マザーボードが安いので対応に費用がかからない。
性能はともかく高機能を要求する場合には結構な価格差が出る。

一方、Z400は、秋葉原で3万円ほどで買った中古だ。

3万円というと、自作にせよ、BTOマシンにせよ、かなり困難なラインになる。非常に小さな、ラップトップと変わらないようなものなら購入できるが、本当に最低辺のPCだ。
だが、最新型を購入できてしまうために、中古ならでは、とはいいにくい。

ちなみに、Windowsを含む場合は、3万円で自作は恐らく出来ない。

Z400は、2010年のhpのエントリーワークステーションだ。
エントリーモデルとはいえミドルタワーのワークステーション。普通の人が手にするようなものではない。
安価なhp Z230SFFでも123,200円から。値段的にはそこまでもないとも取れるが、用途が特殊だ。
Z400の構成は、当時でいえば、パソコンならば最上位クラスにあたる。

PCが5年使い続けられることはない。性能の変化、規格の変化、タイミングにもよるが、どうしても5年はもたない。3年が良いところだ。

だが、要求水準が元より異なる場合はその限りではない。5年前は時代遅れのポンコツだが、それでもかたや5年前の、パソコンでいえばハイエンドに匹敵するクラス。かたや最新ながら、あくまで安価でありながら性能を確保したことが魅力であるエントリー・モデルだ。

それを比べた結果、「5年前のワークステーションのほうがやや高性能だった」という結果が出たということだ。これをどう捉えるか。

安価なマシンを求めるのであれば、秋葉原で、良い中古マシンを確保したほうが性能は高い。

これはおおよそ真だ。ただし、機能的にはどうしても劣る。タイミングによっては、旧規格を採用しているために非常に苦労する場合もある。
Z400はSATA2, USB 2.0といった旧規格であり、新規格には対応していない。小さなことだが、不便でもある。
メモリの速度は1066だ。1600が普通に使える今となっては低速で勿体無くもある。
そして、グラフィックスは4kより前の時代であり、4kに対応しておらず、トリプルヘッドにも対応していない。

こうした機能面では最新のGodavari、それも高機能マザーボードのFM2+Killerのほうが圧倒的に優れている。
もし、Windowsを普通に使うのであれば、私はFM2+Killerをメインにしていたと思う。

だが、Linuxでは随分とエクスペリエンスの差がある。
さらにいえば、AMD CPUだとオーディオエンジンが頻繁にドロップしてしまう(SONARにおいて)。
性能差というよりも、快適さが随分と違う。さすがに、王道、Intel+nVidiaという構成は強かった。

もしあなたが、何らかの理由でこのようなコンピュータを欲したとする。
もちろん、「普通にしか使わないから」といって「普通な用途に適したコンピュータ」を選ぶことはあまり勧められない。
ライフタイムが短くなるからだ。
もう少し視野を広くもったほうが良い。それに、そこそこ大きい買い物なのだし、もっと積極的に楽しんだほうがお得だ。

だが、色々理由は考えられる。
私のように急な故障で、予算はないがとりあえずまともに使えるレベルのーたが早急に必要だとか。
Windows XPマシンのリプレイスが必要だが、予算が確保できておらず、導入までの時間を遅延させたいとか。

また、業務利用の場合、要件が全く変わらず、「環境が変化しないこと」が求められる場合もある。
事務仕事や、株取引などにおいては、特に変更される必要はない。
定期的に必要にはなるが、刷新タイミング意外では毎日同じように業務を遂行できることのほうが大事だ。
この場合、特に故障などがなければ、規格が時代遅れといった問題はない。そのため、現状で使えるのであれば、そのマシンが使える限り、もしくは刷新がなされるまで使える、という考え方が可能だ。
ちなみに、DTMは環境を更新し続けるのが一般的なのでむしろ最新マシンが必要になるが、環境を変えないなら変えないでもなんとかなるものだ。

そのような場合においてどちらを選ぶべきか?

中古のほうが若干だがお得感はある。だが、新品のほうが高機能で快適である可能性がある。

もちろん、中古の場合は保証がない。新品の場合はある。
だが、5年も前のもので、しかもずっと使われてきたものであるならば中古はそうそう壊れない。機会の故障率はバスタブカーブを描くため、故障するなら普通はそれ以前に生じる。
新品であれば保証が利き、修理も依頼しやすい。

どちらが良いかは、好き好きとしか言いようがない。
そして、自作も中古も、趣味が入っていないとやっていられない。
本当の業務システムでやるようなことではない。

VDPAU / VAAPI * AMD A10 kaveri / Cinnamonが立ち上がらない

LinuxでのGPUハードウェアアクセラレーションつきでの再生のトライ。

設定はわかっているが動作のためにセットアップ。

VDPAUを利用するため、libvdpau-va-glとlibva-xvba-driverのインストールを行い、/etc/profile.d/vdpau_vaapi.sh

#!/bin/sh
export VDPAU_DRIVER=va_gl

と設定して実行可能に。(root:root 744)。再起動して有効化できる。 別パッケージのvdpauinfoによると

libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/fglrx_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0
display: :0.0   screen: 0
[VS] Software VDPAU backend library initialized
API version: 1
Information string: OpenGL/VAAPI/libswscale backend for VDPAU

Video surface:

name   width height types
-------------------------------------------
420     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
422     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
444     1920  1080  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 

Decoder capabilities:

name                        level macbs width height
----------------------------------------------------
MPEG1                          --- not supported ---
MPEG2_SIMPLE                   --- not supported ---
MPEG2_MAIN                     --- not supported ---
H264_BASELINE                  51 16384  2048  2048
H264_MAIN                      51 16384  2048  2048
H264_HIGH                      51 16384  2048  2048
VC1_SIMPLE                     --- not supported ---
VC1_MAIN                       --- not supported ---
VC1_ADVANCED                   --- not supported ---
MPEG4_PART2_SP                 --- not supported ---
MPEG4_PART2_ASP                --- not supported ---
DIVX4_QMOBILE                  --- not supported ---
DIVX4_MOBILE                   --- not supported ---
DIVX4_HOME_THEATER             --- not supported ---
DIVX4_HD_1080P                 --- not supported ---
DIVX5_QMOBILE                  --- not supported ---
DIVX5_MOBILE                   --- not supported ---
DIVX5_HOME_THEATER             --- not supported ---
DIVX5_HD_1080P                 --- not supported ---
H264_CONSTRAINED_BASELINE      --- not supported ---
H264_EXTENDED                  --- not supported ---
H264_PROGRESSIVE_HIGH          --- not supported ---
H264_CONSTRAINED_HIGH          --- not supported ---
H264_HIGH_444_PREDICTIVE       --- not supported ---
HEVC_MAIN                      --- not supported ---
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         457866064 457866064    y  
R8G8B8A8         457866064 457866064    y  
R10G10B10A2      457866064 457866064    y  
B10G10R10A2      457866064 457866064    y  
A8               457866064 457866064    y  

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             -
DEINTERLACE_TEMPORAL_SPATIAL     -
INVERSE_TELECINE                 -
NOISE_REDUCTION                  -
SHARPNESS                        -
LUMA_KEY                         -
HIGH QUALITY SCALING - L1        -
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              -  
VIDEO_SURFACE_HEIGHT             -  
CHROMA_TYPE                      -  
LAYERS                           -  

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 -  
CSC_MATRIX                       -  
NOISE_REDUCTION_LEVEL            -  
SHARPNESS_LEVEL                  -  
LUMA_KEY_MIN_LUMA                -  
LUMA_KEY_MAX_LUMA                -  

H.264しかサポートできていない?

VAAPIはAMD APU A10 Kaveriで必要なのはlibva-xvba-driverなので、それだけでOK。Catalystドライバは既に使用している。 Mplayerはmplayer-vaapiをAURから導入すれば良いということだが(コマンドラインオプションは必要。Wikiは英語版mplayerの項目でのみ、AURにあることが示されている。communityからdropしたパッケージ)、現在のところ鍵が検証できない(手動追加しても受け付けない)ので試していない。 SMplayerはVAAPIはIntelのみだと言ってくる。

結局うまく動いていない気がする。

Cinnamonが立ち上がらない

再起動すると、Cinnamonが立ち上がらなくなった。

待たされた上でデフォルトの壁紙が表示され、

Cinnamonはクラッシュしました

と表示される。

~/xsession-errorsを調べると、~/.config/dconfがPermission Deniedになっている。

ls -ldR ~/.config/dconf

したところ、ごっそりとパーミッションがroot:rootのmask077になっている。 chownしたのだが、chownしても何度も戻ってしまい、ちょっと苦労した。

hp pavilion x2 10 修理へ

hp Pavilion x2 10のカメラが動作しないために、修理送りとなった。

Skype for Windows Desktop起動時に「全面緑」で動作しない。カメラはインジケータランプはついているのにだ。 Firefox Helloで試すと真っ白。

そして、今回はチャットサポート。 前回と同じ方の対応で、やりやすかった。

「カメラ」アプリでテスト、ドライバ削除からの再起動、BIOSリセットからの再起動と試したものの改善せず、引き取り修理へ。

ついでに、先の液晶の傷?問題も見てもらうことに。

2時間もお付き合いいただき、ありがとうございました…

しかし、私、ハードウェア不良ひく確率高くないか。先日もカメラ初期不良で送ったばかりだし、その前はThinkPadをファクトリー送りにしたし、電熱スリッパも送ったし、なんか憑いてる。

LGディスプレイの顛末

まぁ、次の通りだ。

LGの回答
LGの回答
  • 色がおかしい→否定&交換(下記と同一)
  • 画像がおかしい→肯定&交換
  • アダプタが鳴く→否定&交換

結果としては

  • 画像がおかしい、という点は直った
  • 色はやはり白いが、色が出ていないという部分は直った
  • アダプタの鳴きは多分直った
これでみても右が白っぽく色も出ていない
これでみても右が白っぽく色も出ていない

結論としては

  • フォームで散々サポートを拒否した上、今回も受け取りも経過報告も一切なしで送ってきたので、結構苛立つ
  • 製品品質もひどい
  • 今後LG製品を買うことはないだろう
  • 素直に交換されているので、最終的にはダメだったわけではない(品質は悪いが)。経過や品質を気にしない人はいいと思う。
  • 少なくとも詐欺商品の類ではない
  • 品質に関して、高級なやつは違うのかもしれないけれど、それは分からない。22EN43と22EN33がこれだけ品質が違うので大いにありうる

hp ProLiant MicroServerとCentOS 7とZFSonLinuxの話

ProLiant MicroServerにHDD組み込み

先週秋葉原で買ったHDDが、初期不良対象期間が土曜日までだったので、金曜日にProLiant MicroServerにHDDの組み込みを行った。

実際に開けたり調べた限りで分かるのは次のことだ。

  • HDD搭載個数は4個。ホットプラグではない
  • eSATA端子を装備。
  • 5インチベイ用はSATAでケーブルは付属せず。ただし、ここはIDEとして動作し、低速

とりあえず開けてみる。これが非常によくできていて、扉は鍵で開ける。工具は不要、付属の鍵を使うのだ。ちなみに、上部の5インチベイ部分については、扉を開けた上で後方のボルトヘッドを手で回し(ダイアル状になっていて、工具は完全に不要)スライドする。ボルトは外れるようにはなっていない。

扉は開くが、横倒しにしていると外れることがある。外れると横倒しのままではなかなか正しくはまらないので注意。正しく置いた時に上下とも下側に突起があり、穴に突起がはまるようになっている。なかなか考えられた構造だ。簡易でコストが安く、扱いやすく、壊れにくい。

ハードディスクはホルダーを介して止まっている。リリースボタンを押してレバーを解除し、レバーを引く。レバーが押しこみ防止になっているもので、若干この動作が恐い感触があるが、精度はしっかりしていてブレる心配はない。封印された4台が備えられ、左に500GBのハードディスクが収まる。このハードディスクは裏面がカバーされたサーバー向けのタイプ。具体的にはWD5003ABYX。7200rpmのエンタープライズ、イエローだ。

今回は4TBx1,3TBx3に換装する。ホルダーについては特殊なネジで止められているが、扉の裏側にホルダー用のネジと工具がある。ちょっと探してしまったが、上手いものだと思う。紛失の心配もなく、コンパクトで、面倒もない。また、ホルダーのネジは予備もある。5インチベイ用のネジもここにある。こちらは六角。

順次固定していく。非常に簡単な作業だ。若干ネジまわしが疲れるくらいか。特にケース側はしっかり入っているのと、ネジを落とさないようにしなくてはいけないのが疲れる。数も多いし。

固定したらこれらを閉めて各種インターフェイスを接続、USB光学ドライブを接続しSystemRescueCDで起動。for i in /dev/sd[a-d]; do smartctl --all "$i"; done | lessとして問題がないことを確認した。

ProLiant MicroServerについて

15000円ほどの安価な、いわゆる安鯖、廉価サーバーだ。非常に安価でありながら現代的な性能を持つコンピュータであり、特にまともなコンピュータを持つもたない人にとってはとりあえず購入しておいてもいいというような代物といっていい。

ただし、普通のデスクトップコンピュータ、今の感覚で言うと普通ではないが、とは差異があることを理解しておかなくてはならない。つまり:

  • サスペンドはできない。ハードウェア的にサポートされていない
  • グラフィックスは非力であり、出力はVGA(D-Sub15)である
  • 基本的に枯れたハードウェアを採用。また、CPUは低速で消費電力が低いものを使用
  • OSなし
  • このモデルについては光学ドライブもない
  • ハードウェアがサーバー向けであるため、Windowsではサポートされない可能性がある

だが、サーバーだからこそのメリットもある

  • 24時間稼働に対応
  • ECCメモリーを使用
  • 低消費電力
  • 高信頼性

だが、このProLiant MicroServer Turion II NEO N5 F1F35A0-AAAEに関して言えば、PCI-E x16をロープロファイルながらサポートするため、普通にデスクトップとして使用できる。電源が200Wなのでハイパワータイプはとてもではないが使えないが、ローエンドモデルの接続は可能だ。ただし、ディスクを最大5台積める仕様なので、それだけでいっぱいいっぱいではあるだろう。

とはいえ、別に高性能を目指すようなものではないし、VGAで十分だと私は思う。CPUの性能も高くないし、デスクトップとしてバリバリ使うものではないだろう。だが、ちょっとした用途には十分事足りる。

サーバーとして見ると、この小さな筐体にHDDを4台搭載した上にeSATAディスクも搭載可能、というのは非常に大きい。ただし、eSATAの使いどころはかなり難しい。台数が多いケースは高いし、内蔵に使うにしても引き込めない。予備インターフェイスと考えたほうが良さそうだ。

しかし単純に考えて、筐体自体はHDD6台がCapableであるというのはすごい。しかも、小型の筐体だけに中に手を突っ込めるようにはなっていないが、上部パネルと同じく手回しボルトをゆるめることでMB全体を引き出すことができる、と非常に考えられた設計だ。

さらにECCメモリを搭載するということもあるが、それ以外を見ても非常に安定している。自作機とは比べるべくもないが、厳しく検証を重ねて安定したものと比べても非常に安定している。

さらにBIOS画面の待ち時間はやや長く、しかも入力のためのステップを複数用意する。もしブートデバイスがみつからなくても、そこでブータブルメディアを挿入すると自動的に認識して起動してくれる。つまり、とりあえず起動してからディスクを挿入することが可能。さらに、起動や終了のタイミングでのトレイオープンも可能。デスクトップだと起動時に起動される前にトレイオープンができないため、メディアの挿入/排除が結構大変だ。しかも、ProLiantならゆっくりメディアを入れても大丈夫。

いくつかの問題も発生しているが、ハード自体は極めて安定しており、信頼性も高い。

その上に扉、トレイ、固定方法など非常に心配りのされたつくり。hpが好きになった。

CentOS7

一方、なかなか手ごわいのがCentOS 7だ。

Linuxはサーバー向け、という人がいるが、実際にLinuxのサーバー向けディストリビューションというのは多くない。どちらかといえばEnterprise Server向けだ。

一般的な選択肢は、まず最大シェアのRHEL/CentOS/Scientific Linux/Oracle Linux/Whitebox Enterprise Linux。その対抗馬はSLES、あるいは無償のUbuntu Server、サーバーユースにも耐えるとされるDebian/GNU Linux、あとは枯れた仕様・原始的なシステムのSlackware Linuxくらいのものだ。

この中でフリーというと、RHELクローンか、Ubuntu Serverか…と選択肢は非常に少ない。別にサーバーユースにはできるが、サーバー向けにはなっていないため、長期の安定運用には不安が残るし、実績の問題もある。

CentOSがダメだとは全く思っていないのだが、やはりFirewalldとNetwork Managerという新しいシステムの導入が厳しい。その設定について覚えなくてはならないからだ。

それになんだか動作がおかしい。設定したLUKSロングパスフレーズが、有効に働かないのだ。調べてみると

ディスク選択時に「データを暗号化」+LVMでPVを暗号化
Dracut内で復号できない。他システムでならば復号可能
ディスク選択時に「データを暗号化」+パーティションを暗号化
正しいはずのLUKSパスフレーズを受け付けない
ディスク選択時に暗号化を選択せず、パーティションを暗号化
正常に動作する

openSUSEでもLUKSが突然パスフレーズを受け付けなくなることがあり、正直「LUKSっていまいち」と感じている。もしくはcryptsetupがいまいちなのかもしれない。今回もなんども再起動し、SystemRescueCDと入れ替え、インストールし直し、と繰り返すこととなった。

かなり疲れてしまった。また、インストーラがかなり扱いにくく、自由にパーティションが切れない。予めパーティションを切っておき、ディスクを選択してから、その他を選択して進めるのがよさそうだ。ちなみに、GPT用パーティションを切っていないと警告される。openSUSEのインストーラはそこが不完全だったので嬉しいところ。

まずはdm-cryptの直接暗号化を使ったスーパーディスクが使えるかを試してみる。

$ <kbd>dd if=/dev/urandom of=keyfile bs=512 count=1</kbd>
$ <kbd>sudo cryptsetup –hash=sha512 –cipher=twofish-xts-plain –offset=0 –key-file=/home/aki/keyfile –key-size=512 open –type=plain /dev/sdb enc</kbd>
$ <kbd>sudo mkfs.ext4 /dev/mapper/enc</kbd>
$ <kbd>sudo mount /dev/mapper/enc /mnt</kbd>
$ <kbd>su -c ‘echo Hello, world &gt; /mnt/hello'</kbd>
$ <kbd>less /mnt/hello</kbd>

問題なし。次にZFS環境のセットアップに入る。


zfsonlinux.org/epel.html
を参考にするが、既にバージョンが進み、ファイル名は2015-02-06時点でepel-release-7-5.noarch.rpmとなっていた。

また、

Qiita
ではインストールしただけではダメというようにあるが、実際はインストールしただけで大丈夫だった。

以下はZFSの作成作業。

# <kbd>zfsmount.zsh</kbd> #各デバイスをループで暗号化。zfs_*という名前。オープンしていたものは事前にclose
# <kbd>zpool create ReasonZpool /dev/mapper/zfs_*</kbd> #Zpoolを作成
# #ここでプールをテスト。問題なし
# <kbd>zfs create ReasonZpool/world</kbd> #worldファイルシステムを作成。マウントポイントは<tt class="puredoc_pathname">/ReasonZpool/world</tt>
# <kbd>zfs get all ReasonZpool/world</kbd> #プロパティの確認
# <kbd>zfs set compress=gzip-9 ReasonZpool/world</kbd> #Gzip最高レベルでの圧縮。低速。
# <kbd>zfs set primarycache=metadata ReasonZpool/world</kbd> #キャッシュはメタデータのみ。メモリ消費量を削減。
# <kbd>zfs set acltype=posixacl ReasonZpool/world</kbd> #POSIX ACLを有効に
# <kbd>zfs set relatime=on ReasonZpool/world</kbd> #Relatime(atimeの記録を遅延させる)
# <kbd>#zfs set dedup=on ReasonZpool/world</kbd> #重複排除機能をON。メモリを大ぐらいするらしい。全域に使えるだけのメモリはない。1TBで32GBのメモリを必要とし、操作できないほどの状態になるとのことで今回は諦める。
# <kbd>zfs set setuid=off ReasonZpool/world</kbd> #nosuid+nodev

dedupの難しさについてはこんな記述がある。

しかし,この機能,ディスクは節約されるが,メモリをたくさん使うのだ.なぜかというと,メモリ上に DeDuplicationTable (DDT) と呼ばれるテーブルを準備することによって,重複を見つけているのである. 計算手順は省略するが,1TBを利用している場合に最大で約32GBのメモリを必要とし.メモリから溢れた分はディスク上のキャッシュに退避され,検索パフォーマンスが劇的に低下する.

著者が試したときにはあまりのメモリ不足のために,データセットの削除ができない程の状態となった.(1週間程度経っても完了せず,あきらめてプールごと破壊することにした)

恐らくはおとなしくHDDを増やしていくほうが現状マシだ。

さらに、usersグループを規格に沿って500に変更し、ユーザーのグループをusersに変更する。

あとはお約束。

  • ストレージを使う前にzfsmount.zshを実行する
  • ReasonZpool/worldを使う

ラップトップの選定と今昔

最新ラップトップ

先日、川崎に行った際に時間があったのでヨドバシカメラに行ってきた。早々に店員に捕まってしまったが、せっかくなので「まだ見ている段階」としつつ色々聞いてみた(知識は大いに不足だったが…

今回チェックして分かったのだが、私の要求を満たすラップトップはかなり難しい。e440の携行性を問題にしているのだが、どちらかというと増やす方向だ。e440はレコーディングを考えて用意して、携行性はむしろギリギリを狙った。だが、様々なイベントに持ち出すようになり、携行性が重要になってきている。e440を持っていくほどではないがラップトップはもちたいことが普通にあるのだ。

そこで将来的に(というか来年に)e440と共存する形でモバイルラップトップを追加し、e440を普段彼女(妻)に使わせる、ということを検討した。これは、低スペックのユニットを与えるのよりも簡単で効率的な方法ではないかと考えたのだ。

だが、多くのラップトップはその操作性と携行性において、一長一短の様相を呈していた。キーボードが打ちづらいか、一体型となったタッチパッドが極めて使いにくいか、そのどちらかがほとんどだ。そうでないものは、1.5kgを越えるか、10時間を切る駆動で携行性においてe440と大差ない。

奇妙なボタンのないタッチパッドは今や主流のようだ。なぜこんな使いにくいものになってしまったのか?と聞いたところ、「コストダウンのため」という回答だった。わからなくはないが、取り替えの効かないUIをコストダウンでこのように犠牲にするのは明らかに違うだろう。普通に考えればこれが使いやすいと考えているか、もしくはなんらかの犠牲になったと考えるべきだろう。

にしても、実に使いにくい。ThinkPad e440のマジックパッドの場合、マルチタッチによるスクロールが可能ということだが、それについてはかなり古いハードウェアでもLinuxならSynapticsを使用することができることが分かり、やはり何のメリットもない。クリック時に意図したボタンが押せず、しかもタッチパッドも反応する。かなり最悪に近い代物だと思う。

もはやタッチパッド嫌いでは通用しなくなってしまった。今やThinkPadもこのように使いにくいタッチパッドを採用する。一方、アイソレーションキーボードに関しては以前と比べて打ちやすいものが増えたと思う。しかし、昔のThinkPadのような明確なクリック感があって打ちやすいキーボードというのは、もはや失われてしまったようだ。今やラップトップのキーボードは曖昧なキータッチで打ちにくいものだ。私がスマホ用に使っているキーボードはパンタグラフ式でとても打ちやすい。

つまり、第一にUIで絞り込まれる。キーボードが打ちやすく、タッチパッドが嫌にならない、という条件で既にかなり絞られてしまう。私の印象では、hpと富士通がかなりよかったのだが、今回試した範囲だといまいちだった。

また、最近はイーサネットポートがないのも困る。有線は使えるが無線は使えないケースは多いと思うし、有線のメリットをないがしろにしすぎではないか。ちなみに、最近は有線ルーターも入手困難だ。

結局のところ、候補はPanasonic Let’s noteしか残らないようだ。Panasonicのラップトップは昔からIBM ThinkPad(Lenovo ThinPadでは断じてない)と並び信頼できるラップトップだった。特に軽量・頑丈・長時間駆動に関しては圧倒的なアドバンテージを持っていた。ただし、近年はマイレージ性能は富士通が検討し、その後NECが圧倒的な性能を見せてたために存在感が薄れていた。

だが、そのトラディショナルな構成は非常に安心感がある。本命はPanasonicの特徴であるシェルドライブとホイールパッドを搭載するSXだろろうと思ったのだが、実際はSXに関しては右下のほうにあるキーが非常に打ちづらく、”.”がとても打ちにくいし、かな打ちだと「ね」「る」「め」「ろ」と普通に打つキーがそこに配置されているのがとてもとてもしんどい。句読点もしょっちゅう使うだろうに、日本市場を考えた設計には全く見えない。

軽量でプレゼンにも便利なコンバーチブルタイプのMXも同様のキーになっている。感触がよかったのはLXで、e440が2.12kg, 7.7hという仕様なのに対して1.395kg/16-23hという仕様は非常に魅力的だ。ただし、バリエーションが少なく、Office+BDドライブモデルしか選べないため、30万円近いのが厳しい。

30万円というと、もうこの計画自体に現実味がない。

だが、帰ってからカタログを眺めていて気づいたのだが、Let’ Note RZ4という、745gの10.1inchモデルが存在するようだ。NEC LZの対抗的なモデルだろうか。プロセッサがIntelの新型、14nmの小型プロセッサであるCore Mを採用しており、これが大きなメリットなのだろう。1kgを切ると本当に軽く感じるので、745gというのは本当にメリットが大きいと思う。そしてみたところまともなキーだ。アイソレーションキーで、Let’s Noteでキー自体が(小さいとかいう理由以外で)打ちにくいと感じたことはないし、配置がイカれているということもないので、これはいいかもしれない。

128GB SSDのOfficeなしという最安価モデルCF-RZ4CDDJRで14万円程度。来年春くらいならこれが候補かもしれない。256GBモデルはOfficeなしモデルがなく、素直にSSDを週末秋葉原でゲットするのが正しい道だろう。1ファイルが10GBくらいということは普通にあるので、128GBの2OSでの運用は相当厳しい。sshfsなどに直接保存するのが現実的かというとなかなか厳しい。ストリーミング保存においてはUSB-HDDへの保存もためらわれるので悩ましいところだ。

だが、結局はこうして2台にわけることで携行性を求める場合は携行性に特化するのが素直なアプローチとなりそうだ。色々な意味でのパワーが必要な場合はe440を使えば良い。ただし、本来的な意味ではパワフルなラップトップがほしいのならば、Celeronのe440は明らかにパワー不足。だが実際のシーンを考えると、ストレージがそこそこ大きくてまともに動作し、そこそこ画面サイズが大きければ困らないとも言える。

おんぼろラップトップ

だが、いきなり14万円が用意できるはずもなく、そもそも仮に用意したとしても今e440を渡すわけにはいかない。

彼女の練習用ラップトップはやっぱり必要だ。そこで秋葉原にいった際にリユースショップに寄って見繕ってきた。

8800円ほど出せばそこそこ魅力のあるものが買えそうだった。30000円以下でかなり魅力的なものもあったが、3万円出すならばもうちょっと出してhpのラップトップを買ったほうがいいだろう。hp ProBook 450 G2/CTは41900円から。ただし光学ドライブと無線LANがオプションなのでちょっとしんどいかもしれないが。しかし今ならそれを入れても50000円はいかない。e440も47000円からとそんなものだ。HP14-r200だと35000円程度でも可能。

あくまで練習用と割りきって安いのを探すと、2800円と3800円を発見。2800円はCeleron Mに256MB RAMのFMV、3800円はPentium Mに512MB RAMのFMVとCeleron Mに756MB RAMのDynabookだ。いずれもOSなし。WindowsXP法人モデルの廃棄品だろう。

OSなしとあるが動作自体は確認しているのか?と聞くとYESとのことだった。256MB RAMは厳しすぎる。動かないわけではないが、普通には使えない。Dynabookに決めかけたが2ボタンであることに気がついてやめた。だが、結果的にはSynapticsを入れれば関係なかったし、FMVの中央ボタンはクリックすると上下スクロールというあまり使いやすいものではなかった。

ただし、それでもちょっとした利便性だったりするし、PCUは優れている。また、ディスプレイが1280×800というサイズなのでちょっと特殊ではあるがXGAと比べるとやはり使いやすい。ストレージは60GBに対して40GBと劣っていた。だが、60GB程度ならばあまり変わらないだろう。

しかし使ってみると、やはりこの世代のラップトップは良い。インターフェイスが充実していて、打鍵感もしっかりしているし、今からすればタッチパッドもずっと使いやすい。今と違い重く大きく熱く、そしてマイレージ性能も劣るが、それ以外については非常に優れている。蓋がロックされるようになることになっているのも魅力だろう。

近年は改良として成立していないぞと正直思う。使い心地の良いラップトップだ。インターフェイスの配置も良い。

ちなみに、モデルはFMV-C6310。天面はシルバーで、ボディはブルーグレイ、裏面はブラックとなかなか洒落ている。ただし、おそらく彼女は2800円のFMVのほうがいいと言っただろう…

これだったらルーターにしてもいいかもしれない。少なくともThinkPad G40よりはずっと性能的にも優れているし、あの凶悪な電気の消費もないだろう。USB5ポート、PS/2、光学ドライブ、イヤホン、マイク、PCカードx2、SDカードリーダー(ほぼ使えないか?)、プリンタ(使わない)、D-Sub15、シリアル(使わない)そして謎端子ととても充実している。

ちなみに、当然ながらバッテリーは死んでいる。

PCLinuxOS

いつも私が公言・提案しているように、販売時OSなどないほうがいいくらいで、古いPCでもLinuxによっていくらでも使いようがある、ということを実現していく。

512MBというRAMがネックだが、幸いにもPAEが有効なPentium Mだった。今ならば、Intel Core世代になれば面倒は少ないが、x86_64への移行が進み、32bit CPUだとそれなりに面倒な部分がある。だが、PAEが有効ならばまだ使える。

まずはBerry Linux 1.17で動作チェック。何も問題ない。どころか、マウス接続時用にタッチパッド無効ボタンがあるが、これがちゃんと働いてすごく使いやすい!これ、今のラップトップにもほしい。

Berry 1.19はメディアは正しく作成されたことを確認しているが、まともに動かない。まず試してみようと思ったのがPCLinuxOS LXDE 32bitだったのだが、これが非常に快適でよく動き、感動的だった。512MBでもなんとかなるものだ。極端な軽量を狙わなくても今のこのクラスの中古がちょっとした工夫で普通に動く。これは重要な情報だろう。

一応、EnlightenmentとiceWMも入れてみた。iceWMがWindows XPそっくりな見た目にカスタマイズされている。e19はしっかり設定されていて素敵だが、困ったことにシステムトレイにアイコンが出ない。

ディスプレイ解像度に関しては特殊であるせいかPCLOSでは1024×800と認識されてしまうので手動設定が必要。GUI上で可能。

おおまかな手順としては

  1. ライブ起動。キーボードレイアウトはJapaneseにして起動したほうがいい
  2. インストーラ起動
  3. インストーラに従ってインストール(ただし、私は/をReiserFS、/homeをXFSとした)
  4. ディスプレイを設定
  5. Synapticで一覧を更新、アップグレード(su -c ‘apt-get update && apt-get upgrade’でもいい)
  6. Synapticのソースを日本国内のものとし、かつspecialを加える
  7. 一覧を更新
  8. addlocaleを使って日本語をインストール(Localization Manager。ウィザードで進む)
  9. Fcitx-Mozcをインストール。FcitxとMozcは自動インストールされる。ちなみにlibkkcも利用可能
  10. 入力メソッドの選択、を使ってFcitxをセレクト
  11. fonts-ttf-japanese, fonts-ttf-japanese-extra, fonts-ttf-japanese-vlgothincをインストール
  12. ~/.config/fontconfig/fonts.confを設定
  13. FirefoxにJapanese Language Packをインストール(Firefox-jaをインストールしてもダメだった)
  14. gksu, sudoをインストール
  15. su -c ‘usermod -a -G wheel user; visudo’ #Wheelグループのsudoを有効に
  16. Synapticsの設定
  17. Configuration your systemからPolicyKitの設定でユーザーのパスワードを聞くようにする
  18. Zsh, Rubyなど必要なものをインストール
  19. Copy.binは公式からインストール
  20. .zshrcの設定
  21. EnlightenmentとiceWMのインストール

以下参考

<?xml version="1.0" ?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="antialias" mode="assign">
<bool>true</bool>
</edit>
<edit name="rgba" mode="assign">
<const>rgb</const>
</edit>
<edit mode="assign" name="lcdfilter">
<const>lcddefault</const>
</edit>
<edit mode="assign" name="hintstyle">
<const>hintfull</const>
</edit>
</match>

<alias>
<family>sans-serif</family>
<prefer>
<family>M+1VM+IPAG circle</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>IPAMonaPMincho</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Ume Gothic</family>
</prefer>
</alias>
</fontconfig>

Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
Option "VertEdgeScroll" "1"
Option "TapButton1" "1"
Option "VertTwoFingerScroll" "on"
Option "HorizEdgeScroll" "on"
Option "CircularScrolling" "on"
Option "CircScrollTrigger" "8"
Option "EmulateTwoFingerMinZ" "40"
Option "EmulateTwoFingerMinW" "8"
Option "CoastingSpeed" "0"
Option "FingerLow" "35"
Option "FingerHigh" "40"
Option "PalmDetect" "1"
Option "PalmMinWidth=" "4"
Option "PalmMinZ" "25"
EndSection

ちなみに、Synapticsは、パームレストに圧力がかかっていると(タイプ中に)タッチパッドを向こうにする、二本指でなぞることでスクロールする、エッジをなぞることでスクロールする、角からはじめて回転させることでスクロールする、という機能を有効にしている。このような古いラップトップでもこの機能を使うことができ、最新型をWindowsで使っているよりも便利で快適だ。

新しいストレージワーク(GlusterFS, AoE, lsyncd)

問題点

分かってはいたことだが、先日の件でbtrfs mirrorでは不十分だ。データの冗長化は次のようなことが考えられる。

  • ストレージの故障
  • ファイルシステムの故障
  • RAIDハードウェアの故障
  • 誤操作による喪失
  • コンピュータノードの故障
  • コンピュータノードの喪失(災害や盗難など)

基本的な対応は次の通り。

ストレージの故障
ミラーリングを行い、故障したストレージを置き換える
ファイルシステムの故障
異なるファイルシステム間でミラーするか、バックアップする。
RAIDハードウェアの故障
同一のRAIDハードウェアに再接続するか、バックアップによって復元する
誤操作
gitやpdumpfs、あるいはLogFSなどスナップショットの活用
ノードの故障
新規ノードにストレージを移設する。可用性が不要ならばデータの冗長化は不要
ノードの喪失
可用性の損失は避けられない。同一箇所に保管していると同時に損失する可能性は高いため、クラウドバックアップが有効

一般にノードの損失は稀なケースだと考えられる。だが、実際はそこそこ可能性はある。落雷によっても起こりうる。この場合のことを考えれば、データを諦められないのであればバックアップは必要だ。

これまでは、btrfsの2レッグミラーを採用していた。これはストレージの故障に対する冗長性・可用性を担保する。しかし、それ以外には対応できていない。特に怖いのは、未だexperimentalであるbtrfs自体の異常だ。ファイルシステムが壊れてしまえばミラーされていたものも含めてすべてのデータがアクセス不能になる。

少々複雑な話に聞こえるかもしれないが、btrfsは「壊れにくいファイルシステム」だ。日常的な読み書きで起こるビットエラーをbtrfsは発見し、ミラーリングを行っていれば訂正することすら可能だ。そのため、他のファイルシステムと比べ非常に壊れにくい。それは他のジャーナリングファイルシステムと比べてもだ。そのためた信頼性が高いと言われ、この点を買って私は採用している。一方で、btrfsはまだ完成度が低く、btrfs自体が壊れる挙動を示す可能性がある。そのため信頼性が低いとされている。

データが既に2TiBを超えている現状にあっては、バックアップやその復元も容易ではない。ちなみに、この次にハードルが上がるのは、ストレージ1台ではすまなくなる時だ。コストを度外視すれば、8TBということになる。

基本的にはバックアップというよりも、ミラーリングによって冗長性を持たせ、データが損失しないことを前提とする方向としている。今後も情報増加は進む予定だし、それに対応する構成としておかなくてはならないからだ。そして、データ量は一般的なシングルストレージで済む量に収まる見込みはない。ストレージ増加よりもデータ増加の方がはるかに速い。

現在の対応は次の通りだ。

  • btrfsによるジャーナリング、自動訂正によるビットエラー対策
  • btrfsミラーによる冗長化
  • btrfsによる柔軟なストレージ追加。1台単位でディスク容量を問わず追加し任意のボリュームを切り出せる
  • 必要な箇所をgitとすることで誤操作による損失の防止
  • 一部データのリモートgitへのclone

だが、先日はそのストレージを格納するコンピュータノードがダウンした。そのため、データ自体にアクセスできなくなった。現在でも最低限、4台のストレージを搭載しなければデータを使うことができない。Proliant Microserverは搭載ストレージ台数は4なので、システムドライブを含めるとそれを搭載することができない。

もちろん、データは損失していないのだからコンピュータノードを追加すれば良いのだが、その間仕事は完全に停止してしまう。やはりこの点も冗長性が必要だろう。

機能問題は別として、別のコンピュータがデータを触れれば良いのだ。コンピュータノード全体がダウンしても機能するようにすれば、1台のコンピュータが損失しても問題ない、ということになる。もっとも、実際に必要となるのは完全なクラウドバックアップだが、現在のところそれは月額で8万円程度が必要になるため、現実的でない。

GlusterFS

GlusterFSはペタバイト規模に対応するクラスタストレージ技術だ。ユーザースペースで動作するデーモンであり、大きなファイルの読み書きはネイティブなコードで行う。FUSEでマウントできるだけでなく、NFSやCIFSでもマウント可能。

分散ファイルシステムだがネイティブファイルシステムではなく、各コンピュータはマウントされた特定のディレクトリをGlusterFSデーモンによって公開する(blickと呼ぶ)。クライアントはblickを束ねてvolumeとしてマウントすることができる。中央サーバーがないのがGlusterFSの特徴だ。

CephやGFSと比べかなりお手軽に使えそうに見えるGlusterFSだが、実際には意外と厳しい。それは、blickの容量をみずにファイルベースで振り分けていくこと、GlusterFSのレプリケーションはblickを組みとして複製するものであることによる。このことから、実質的にはblickはすべて同一容量でなくてはならない。しかも、blickの追加はRAID化している数をunitとして行わなくてはいけない。例えばstriped replicated volumeだとしたら、4 blicksが追加単位となるのだ。ディスク単位のblickにしても4台のディスク、コンピュータ単位だと4台のコンピュータだ!

また、このような技術はノードの停止は「障害」であるため、HAの理屈に基づき稼働停止が許されなくなる。電気代で考えても厳しいし、デスクトップユースでの無停止はそもそも難しい。結構よく見えたのだが、GlusterFS適用はかなり難しいように見えた。

ただし、適用方法はある。それは、「そもそも2組のストレージにしてしまい、2 blicks GlusterFS volumeにする」という方法だ。例えばiSCSI+LVMなどで複数のコンピュータノードからなるひとつのファイルシステムを編成し、それをマウントし、それをblickにすれば良い。そうすればコンピュータを2組に分けることができ、片方の組のコンピュータが停止しても全体はダウンしない。ストレージ追加はLVMなどの単位で行えるためかなり柔軟だ。容量の問題は、単に合計容量が小さいほうの組を上限としてそれを越えないように運用する、という制約があるだけだ。

lsyncd

だが、やはりこのようなHA技術は少々重い。それであれば少なくともデスクトップは使う側にしてデスクトップにストレージをもたせるのはやめるべきだ。

任意に停止しゆるい同期を行えれば良い。つまり、「手動で同期サービスを開始・停止し、ファイル更新時に反映してくれれば良い」という考えだ。可用性については、短時間の停止なら十分許容できる。

原始的には定期的にrsyncを回す方法もあるが、せめてファイル更新を監視したい。別にそれをスクリプトにしてもいいのだが、ionotifyというLinuxの機能があるのだから、それを活かしたいもの。そこで「ファイル変更を監視して同期する」というものを探したところ(正確には「なんて名前だっけ」だった)、lsyncdが見つかった。

lsyncdはファイル同期デーモンだが、実際にはミラーリングを行う機能はなく、rsyncなどをバックエンドとして使う。つまり、lsysncdはionotifyによってファイル更新を受け取り、それをトリガーとしてrsyncなどを起動するデーモンだ。

デスクトップレベルではこれが順当なところではないだろうか。台数が増えるとオンオフも困難になるので普通にHAストレージでいいのかもしれないが。

台数が少ないうちは普通にイーサネットケーブルでつなぎ、それをまとめて2つのストレージを編成すればいいのだが、台数が増えてきた場合、それぞれキーになるノード(片方はデスクトップ)をシングルにつなぎ、それぞれがストレージ用ハブを持っておくと良いだろう。構成手順は次のとおり

  • デスクトップは現在btrfsミラー
  • キーサーバーAを接続し、ZFSでストレージを束ねる
  • キーサーバーAにrsyncで全データをバックアップ
  • デスクトップのbtrfsのミラーをやめて構成しなおす
  • キーサーバーAからrsyncでデスクトップにデータを戻す
  • デスクトップとキーサーバーAにGbEインターフェイスを追加する
  • 追加されたGbEインターフェイスをハブに接続する
  • ストレージサーバーノードをGbEでストレージ側ハブに接続する
  • ストレージサーバーノードのディスクをAoEを用いてそれぞれのキーノードのブロックデバイスとしてみえるようにする
  • 追加されたストレージサーバーノードのディスク(AoE)をbtrfs/ZFSノードに加える
  • btrfs/ZFSをリバランス

10GbEに置き換えるところまで考えればかなりの規模までこれでいけるように思う。ただし、グループノードのいずれかがダウンすると障害発生なので、「故障率」は当然あがる。これはグリッドシステムでは常に起こることだ。

Manjaroがまた死んだ。さらに電源が入らなくなった

システム再セットアップ

pacman -Syuuの最中にフリーズしてしまい、LVMでロールバックしたが、ファイルシステムのミスマッチがあるとしてブートしてくれなくなった。systemdで落ちてしまう。

LVMでロールバックしてダメだとどうしようもない。さっさと諦めてtarでUSBメモリーに待避して再セットアップ。

もうなれたものだ。以前の記事にもした手順でセットアップしていく。だが、問題がいくつかみつかった。

  • tarballが「予期せぬEOF」と言われて展開できない。どうやら、不完全なtarballができてしまったらしい。実際、232MBとかなり小さい。
  • かなり多くのパッケージがインストールできない。その大部分はpackage()関数がないためだという
  • UTのリポジトリにアクセスできないため、mozc-utが使えない
  • 4kvideodownloaderのチェックサムが通らない

tarballについては諦めるしかない。

package関数については、build()にまとめてあってpackage()がないものが結構あるのが問題だ。そのため、やり方は乱暴だが、

sed -i 's/^build().*{/package() {/' /tmp/yaourt-tmp-user/aur-package/PKGBUILD

とすれば通る。これは、PKGBUILDを取得してから、再開しますか?とか続行しますか?と聞かれている時に行う。ちなみに、単純に分割すると「installをmakeするターゲットがありません」と言われてしまう。もちろん、単純に

package() {
:
}

と書いても通るとは思う。

UTリポジトリについては対処方法はないと思う。4kvideodownloaderについては、手動で修正すれば良いとは思うが、とりあえずバイナリを落としてきてローカルに展開して使えるようにした。

電源が入らない

途中で何度かフリーズしてしまった。おそらく熱問題だと思われる。追加ファンが届いていたので取り付ける。

マザーボードはASRock FM2A88X+Killer、ケースはFractal Design Defnie R4だ。今回はGelid Silent 14の通常版とPWM版をAmazonで購入。既に120mmのファンが追加されている。

設置は、天面に設置していた120mmを外し、Silent 14を設置、サイドにSilent 14 PWMを設置、120mmについては前面の吸気ファンにする。

設置は比較的簡単だが、Silent14はゴムブッシュを使って固定するが、外にかなり飛び出してしまうのと、ファンに入れる時はかなり強く引っ張らないといけないのが難点。大きいケースで取り回しも楽。非常に使いやすい。

だが、フロントファンについては戸惑った。ツールレスと書いてあるのだが、穴があるだけでどう固定していいのかさっぱりわからない。とりあえずクリアテープで固定した。

この追加ファン+3(4pin*1, 3pin*2)でマザーボードのファンピンはすべて埋まる(シャシーファンに限定せず)。ケースは天面に1つ、底面に1つ固定可能だが、使用できない。

だが、そうすると電源が入らなくなった。正確には、たまに電源は入り、ランプが点灯、HDDの駆動音がし、電源ファンが回るが、それだけ。スイッチで電源を切ることもできない。放電したり、コネクタを挿し直したりしたが治らず、急遽秋葉原へ。

BUYMORE本店でいろいろ聞いたが(後述)、帰ってきてマザーボードを裸にしようとしている時に、メインの電源ケーブルがややゆるいことに気がついた。しっかり挿したら直った。恥ずかしい…

@BUYMORE本店

お店に急行して、相談すると、結構戸惑われてしまったが、それはM/Bが死んだのではないか、ということだった。

保証は利くが旧正月で1ヶ月程度かかる…とのことなので、やはり何かしら調達するしかなさそうだった。Intel 2CPUを目指していたのだが、その余裕はない。

そして現状のCPUを中心としたパワー不足でグラフィックの4kを含む他画面出力という点を見て提案を求めたところ、サーバーかWS用のものを使うべきだとした上で、現実的な妥協点として、i7-4950Kと260Xまたは960を使った8万円弱のプランを提案してもらった。

持ち帰って検討していたのだが、前述のように直ってしまった。恥ずかしい。

なお、コンシュマー向けのM/Bに大量のメモリを積んでがりがり使うとメモリエラーによってフリーズしたり不安定になりやすい、との話だった。真偽は確認していない。

Mageiaのアップデートほか

ファン取り付け

私が使用しているPCケースはDefine R4である。つまり、大型静音ケースなのだが、トラブルの解消につながるかと、ファンを追加することにした。

静音ケースながらファンは背面、底面、上面x2、側面と5個つけられる仕様で、背面のみ付属している。いずれも140mmだが、120mmも取り付けることができる。上面と側面については遮音材を取り外してかわって取り付ける構造だ。

静粛性が犠牲になるため(別に静音ケースを求めていたわけではないが、折角の静音ケースならば…)気が進まなかったが、一番効果の大きそうな上面に120mmを取り付けた。

ファンが、ネジ穴が切られておらず、「ねじ込むことで切る」仕様になっているのにはびっくりした。また、120mmが取り付けられるとはいえ、140mmをとりつけたほうが明らかに美しい。あまりお勧めはできない状態だった。

効果のほどは分からないが、とりあえずこれで様子を見ようと思う。

Mageiaのアップデート

ずっとアップデートはきているのだが競合でアップデートできない状態だった。いくら待っても改善されないため、競合にあったlibpng(lib64png/develとlibpng/devel)をはずしてアップデートすると成功、さらにlibpng/lib64pngのみをアップデートしても成功した。よくわからない。

openSUSE

openSUSEのノンフリーなリポジトリはサードパーティのものであるらしい。このあたりはFedoraやCentOSなどと同じか。だいぶ経っていたので忘れていた。

openSUEはパッケージも豊富でかなり使いやすい。情報がやや足りない気もするが、初心者にも勧められるものだと私は思っている。

openSUSEがsudoでターゲットユーザーのパスワードを求めるのは、/etc/sudoersにdefaultオプションとして書かれていた。Defaults targetpwという部分だが、このような設定をデフォルトにする理由は、ちょっと分からない。あまり普通な(自然な)振る舞いではないように思う。sudoの権限管理を楽にするために、自分が管理しているユーザーに限定する、という意味はあるだろうが(実際に、そのオプションを前提としてALL ALL=(ALL) ALLとしている)。

このオプションと全権設定を無効とし、wheelグループの設定を有効にし、usermod -aG wheel userすれば普通になる。

kblankscrn.kss

KDEでブランクスクリーンのスクリーンセイバーがプロセスが死んでくれず、プロセスがたまる上に次のログイン時に大量のkonsoleが起動してしまう。そのため、定期的にkillallしておく必要があったが、いつまにか直っていた。前述のアップデート前だが、アップデートできないなりにKDE関連はアップデートに成功していたということだろうか?ひっかかってるパッケージ以外はアップデートされていたとか。

VineSeed

うまく動作しなかったVineSeedへのアップグレードだが、結局base-system+task-x11-xorg+lightdmで動くことが確認された。

また、sshはopenssh-clientにあり、sshfs-fuseは依存しておらず、scpは別パッケージ(base-systemに含まれる)という。

これはパッケージングミスや、依存関係の記述ミスであると感じたため、そのように意見してみた。