何か決めなきゃ駄目ですか。



俺が決めたら、貴方はどうするんだい。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop

ねこFD3とか

ふらっとソフマに行ってねこねこFD3を入手。
IMG_0216.jpg

予約もしてないのにテレカまでくれるなんて!


ねーちんのカードの裏は何か恨みでもあるのか・・・

スポンサーサイト

PageTop

一応

LPIC受けて、
秋葉原でカードとパーツ漁りして、
オタモダチと飲みに行って、
カラオケ行って、
そういう土日もあります。

在宅率50%を切る・・・だと・・・っ!
はいはい。

冷静に考えたらネカフェに泊まったり、漫画喫茶に泊まったり、カラオケに泊まったり、
ってのが最近多いよ、バカ。



ダークグレファー3枚入手。
100円なら買うだろ・・・俺なら。
祇園捨ててグレファー出してエッジ捨ててキール捨てて手札のホーンとSDIPしてリミッターカットだー。
・・・そこまでしないといけないの?死ぬの?


最近録画機の調子が良くなくて、気づいたら再起動してるし、これもう僕にアレしろって言ってるよね。


やべぇ。本当に断片化してきた。

こういう気分の時は、大体が未練がましいうぜぇ気分なのでEOF

PageTop

NAS環境について

これでようやく録画環境の設計ができる、ってもんだ。
ZFSを使ったNASを利用した拡張性、柔軟性に富んだ録画環境を設計しちゃうぜ!
(深夜のノリは信用してはならない。そういうものである。)

1.録画そのものを行う機材には、RAID1構成にした録画ファイルのテンポラリーディスクを設置する。
2.定期的、又はファイルの前後カット時にZFS(Samba、NFS等公開方式は問わない)に投げる。
3.ZFS poolが一杯になったら、zfs set mountpoint=/komachi tankのようにして、
 1世代前ディレクトリにマウントポイントを変更する。
 (※現行の公開プールを読み書き可能、1世代前のプールを読み取り専用とする。あくまで公開上。
   ファイル移動とか調整が必要な場合はコンソールでいいだろ・・・と、思ってる。)
4.1世代前のマウントポイントにずらしたら、新しいディスクを挿入して、
 現行のマウントポイントにマウントするようにプールを作成。
5.手順2~4を血反吐を吐くまで繰り返して生きていく。


この場合、実際は物理的に現用HDDと1世代前HDDの格納位置を調整し、
過去のHDDからデータを引き出す場合は、1世代前のHDDを抜いて、そこに過去のHDDを挿せばいい。

その場合、現用データ処理機構には影響が出ない上に、他のノードからはSambaやNFSを経由しているため、
アクセスパスは変わらないのにデータだけがそっくり入れ替わる。
2日に1回程度snapshotを取得すれば、誤って削除した録画ファイルも復元可能だ。



該当の品を探すのは困難なのだが、
PT1又はPT2を挿せて、オープンな3.5inchベイがある小さいケースにD510MOを突っ込んだものと、
HDDエンクロージャが実装可能な5inchベイを複数持つケースに、これまたD510MOを突っ込む。
3.5inchベイに2.5inchHDDを2個乗っけられるエンクロージャを使用してRAID1を組み、
割安な3.5inchHDDをホットスワップしながら世代交代していけば、割と柔軟な運用ができる気がする。

録画システムは非常に小型に実装し、自走してもらう。
こいつに多量のHDDを乗せる必要は無い。

ストレージケースには、それ以外の目的(VMの実体置き場とか)で同時に使う。
できるだけ静穏且つ省電力な多機能NASとの組み合わせは不可能じゃないし、
家庭内の情報量が逼迫するようになれば、こういった外部ストレージというのは必須になる。(言いすぎ)


・・・まぁ、それこそ録画厨かP2P厨の時代の発想かもしれないが。
根底にあるのはVHSのようなテープシステムと似ている。
カセットテープやビデオテープをHDDに、プレイヤーをエンクロージャと捉えれば、
僕の言いたいことは何となく伝わると思うのだがどうだろう。



コホン。

駄目ゲの容量の増加は微々たる物だが、HDDが安いこのご時勢にアンインストールして細々使うことも無い。
以前から言っているが、PCゲームはNASにインストールしてフレキシブルにプレイできるべきだ。
ノベルが主体ならノートPCを抱えてベッドで寝転べば良い。
派手なアクションや3Dダンジョン、歌って踊る必要があるならハイスペックPCで。
本編はデスクトップでプレイしたけど、ファンディスクはノートでプレイ。なんてことも可能だ。
途中からキャプりたくなったからノートからデスクに移動。なんてことも出来て然るべきだ。

即ち、セーブデータの配置と言うものはレジストリやマイドキュメント等、
プレイ環境を固定する場所ではなくインストールディレクトリ、ひいては起動プログラムからの
相対配下ディレクトリに置かれることで、その真価を発揮するのである。
そういった意味では、現代の作品よりも過去の作品の方がそういった実装が多かったように思う。

このような実情が背景にあるからこそ、インストール場所をレジストリに格納したりすることは、
あまり好ましくない。
そういった意味では、マスターディスクさえあれば、実体を起動させることが可能であることが望ましい。
あれもこれもと言ったプロテクトは望ましくない。
(もちろん、レジストリなら書き出せば良い話だが、探すのは一応手間なのである。)




だから、家庭にNASがあるのは悪いことじゃあないんだよ。ほんとだよ?




と、無理矢理結論を出して終わっておく。

PageTop

ZFSの使用率とパフォーマンスの関係 パターン1

ZFSを次のような用途で使う場合。
 ・買ってきたTB級のディスクを何も考えずに1つのZFS poolにする。
 ・samba公開して、諸所の目的で使う。
 ・snapshotは取らない。


ディスクの使用率が95%を越えた辺りからやべぇ、という話があるのですけど、
僕の想定する用途でも発生するかについて試してみまみた。
(参考:http://uyota.asablo.jp/blog/2009/05/09/4296115
あまり厳密な(信頼性の高い環境で)議論できる内容ではないのであしからず。


難しいことは良く分からないので、結果だけをぺたぺた貼ってみる。
Samba経由でネットワークドライブ化した、単一ドライブのZFS poolをCrystalDiskMark2_2_0p。
(多分キャッシュの影響が出まくりとかってことも無いと思うけど・・・)

zfs_diskused_001.png

zfs_diskused_002.png

zfs_diskused_004.png


最終的な状況は下記。

# zpool upgrade -v
This system is currently running ZFS version 6.

The following versions are supported:

VER DESCRIPTION
--- --------------------------------------------------------
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z
4 zpool history
5 Compression using the gzip algorithm
6 bootfs pool property
For more information on a particular version, including supported releases, see:

http://www.opensolaris.org/os/community/zfs/version/N

Where 'N' is the version number.
# zpool list rec_2008_01
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rec_2008_01 1.36T 1.32T 41.9G 96% ONLINE -
# df -h /mnt/rec
Filesystem Size Used Avail Capacity Mounted on
rec_2008_01 1.3T 1.3T 20G 99% /mnt/rec



ファイル数は999個。ディレクトリ数が37個。
tsファイルなせいで1.5TBのディスクを使い切るのにファイルが1000個越えないってのはやばい。
(program.txtとか.errのせいでファイル数が多いだけで、動画ファイルは544個。)

と、この辺りまでは大きな問題は無くて使えそう。
snapshotを使わないスタイルだと、zpool listで見たディスクスペースが空いてるから、
そこまで致命的なことにはならないのかもしれない。

一応、同一システム上で別のzfs poolがあるけど・・・そいつは関係ないよなぁ・・・。


というわけで、もう少し埋めてみる。

空き領域5GB。
zfs_diskused_005.png

# zpool list rec_2008_01
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rec_2008_01 1.36T 1.33T 26.7G 98% ONLINE -
# df -h /mnt/rec
Filesystem Size Used Avail Capacity Mounted on
rec_2008_01 1.3T 1.3T 4.9G 100% /mnt/rec



サイズなのか、ファイル数なのか、使用率なのか、snapshotの有無なのか、オプションの違いか・・・。
いまひとつ掴みきれなかったけど、Sambaで使う録画ファイル置き場としては、
限界ギリギリまでファイルを突っ込むこと自体は問題無いんじゃないかな。
(とりあえず空き領域62.2MB位まで埋めてみたが、やはり問題は無かった)


少なくとも、今回考えている用途で使う分には空き領域への過剰な意識は不要と見てもよさそうだ。
snapshotの領域の使い方は・・・どうなってんのか説明できません。

まぁなんとなーく、pool全体のサイズから2%程度をZFS領域として予約して使ってる気もする。
その辺は公開文書でも探してみたほうがいいですかね。


今回は力業の調査でした。
おわり。



それにしても、1.5TBのHDDを埋めるためにtsファイルの大移動をしてみたけど、
一晩寝てようやくだったから、普段のアニメ録画生活もバカにならない。
塵も積もれば大和撫子略してちりつもやまとなでこですよ、いやマジで。

PageTop

HDD交換日。

最近HDDの調子が悪いと思ってsmartctlかけたら、Raw_Read_Error_Rateが右肩上がりだった。
raidz構成のうちの1台だったので、サイズの合うHDDをデータ移動して見繕い、交換を試みる。

これでraidzのHDD交換は2度目。
そろそろ方法論とかは慣れてきたかも。
(リビルド中にHDDが壊れる恐怖から逃れたいので、raidz2構成で作り直し設計中。)


超個人的なFreeBSD7.2 + ZFS ver6におけるHDD交換手順(簡易版)
※重要な環境では、事前のアクセス確認を念頭に置くこと(iSCSIの仮想サーバとか)。
1.事前確認
zpool status
atacontrol list(又はcamcontrol devlist)
w
ps aux
2.取り外しコマンド(対象がATA Channel 2(=ata2)の時)
atacontrol detach ata2
3.物理的にHDDを取り外す(間違っても別のHDDを抜いてはいけません)
4.物理的にHDDを取り外すと、intrruptが激しくて下手するとOSごと落ちるので、取り外しを再認識させる
atacontrol attach ata2
5.物理的に交換用のHDDを差し込む
6.KernelにHDDを認識させる
atacontrol detach ata2
atacontrol attach ata2
7.ZFSにreplaceを認識させる(pool名、device名は各自確認)
zpool replace tank ad4
8.座して待つ。

それにしてもアクセスランプがチカチカ光ってて可愛いなぁ・・・。



今回のHDD交換は、同システム上の別のZFS pool上にデータ移行中という危険を顧みない状況でのオペレート。
そんな危険なことするくらいなら、普通にeSATAとかUSB外付けとか使っているほうが幸せだと思います。


それにしてもRAIDZはデータ保護の上では良いのだけど、HDDを認識できているのに
READやWRITEが長いこと成功しない(例えばWDの低速病が1台だけ発病した)状態だと、
システムごと固まったようになるのが如何せん扱いに困ると言うか。

データは残ってるんだから、さっさとHDDを差し替えろってことですかね。
いやはや。



---追記
なんかresilverが最初からやり直しになったなぁ・・・やべぇなぁ・・・。
と、冷静に考えたら定例snapshotの取得をしていたからでした。
(毎日17時くらい。ようするに僕が家にいない時間帯。早朝の方がいいかなぁ・・・)

以下のURLにも書かれている。
再構築中にsnapshot取っちゃダメなの忘れてた。
http://docs.sun.com/app/docs/doc/819-6312/chapter2-1000?l=ja&q=ufsdump&a=view

PageTop

アニメとZFS

結論から言っておくと、ZFS-compressionは録画ts置き場としては特に優位性は無い。


まずZFSプールを作成する。
zpool create -m /mnt/rec rec_01 ad14

普段のtsファイルがどの程度圧縮されるかを見る。
圧縮率1.2程度になるなら、1TBのHDDが1.2TB分(90%閾値を考えても1TBフル)使えるじゃないか。


いつものように、最初にatimeを切った後、適当に書き込んでみる。
zfs set atime=off rec_01

書き込むファイルは最近録画してエンコ済みのtsファイル3点ほど。

-----
zfs set compression=off rec_01
---
# ls -wl rec/compression_off/
total 7465266
-rw-r--r-- 1 youmu wheel 2751555592 Feb 8 20:20 はなまる幼稚園 第05話 「はなまるな探偵団・はなまるな初恋」.ts
-rw-r--r-- 1 youmu wheel 1964611092 Feb 7 13:02 デュラララ!! 第05話 「羊頭狗肉」.ts
-rw-r--r-- 1 youmu wheel 2922401908 Feb 7 12:46 ハートキャッチプリキュア! 第01話 「私、変わります!変わってみせます!!」.ts
# zfs get all rec_01 | grep -v default
NAME PROPERTY VALUE SOURCE
rec_01 type filesystem -
rec_01 creation Thu Feb 11 21:55 2010 -
rec_01 used 7.12G -
rec_01 available 1.33T -
rec_01 referenced 7.12G -
rec_01 compressratio 1.00x -
rec_01 mounted yes -
rec_01 mountpoint /mnt/rec local
rec_01 atime off local
rec_01 xattr off temporary
---
zfs set compression=lzjb rec_01
---
# ls -wl rec/compression_lzjb/
total 7464123
-rw-r--r-- 1 youmu wheel 2751555592 Feb 8 20:20 はなまる幼稚園 第05話 「はなまるな探偵団・はなまるな初恋」.ts
-rw-r--r-- 1 youmu wheel 1964611092 Feb 7 13:02 デュラララ!! 第05話 「羊頭狗肉」.ts
-rw-r--r-- 1 youmu wheel 2922401908 Feb 7 12:46 ハートキャッチプリキュア! 第01話 「私、変わります!変わってみせます!!」.ts
# zfs get all rec_01 | grep -v default
NAME PROPERTY VALUE SOURCE
rec_01 type filesystem -
rec_01 creation Thu Feb 11 21:55 2010 -
rec_01 used 7.12G -
rec_01 available 1.33T -
rec_01 referenced 7.12G -
rec_01 compressratio 1.00x -
rec_01 mounted yes -
rec_01 mountpoint /mnt/rec local
rec_01 compression lzjb local
rec_01 atime off local
rec_01 xattr off temporary
---
zfs set compression=gzip rec_01
---
# ls -wl rec/compression_gzip/
total 7429499
-rw-r--r-- 1 youmu wheel 2751555592 Feb 8 20:20 はなまる幼稚園 第05話 「はなまるな探偵団・はなまるな初恋」.ts
-rw-r--r-- 1 youmu wheel 1964611092 Feb 7 13:02 デュラララ!! 第05話 「羊頭狗肉」.ts
-rw-r--r-- 1 youmu wheel 2922401908 Feb 7 12:46 ハートキャッチプリキュア! 第01話 「私、変わります!変わってみせます!!」.ts
# zfs get all rec_01 | grep -v default
NAME PROPERTY VALUE SOURCE
rec_01 type filesystem -
rec_01 creation Thu Feb 11 21:55 2010 -
rec_01 used 7.09G -
rec_01 available 1.33T -
rec_01 referenced 7.09G -
rec_01 compressratio 1.00x -
rec_01 mounted yes -
rec_01 mountpoint /mnt/rec local
rec_01 compression gzip local
rec_01 atime off local
rec_01 xattr off temporary
---
ちなみに、駄目ゲーのセーブデータなら割と縮む。

# ls -wl rec/compression_gzip/
total 7
drwxrwxr-x 108 youmu wheel 108 Feb 11 22:46 セーブデータ
# zfs get all rec_01 | grep -v default
NAME PROPERTY VALUE SOURCE
rec_01 type filesystem -
rec_01 creation Thu Feb 11 21:55 2010 -
rec_01 used 390M -
rec_01 available 1.34T -
rec_01 referenced 390M -
rec_01 compressratio 2.05x -
rec_01 mounted yes -
rec_01 mountpoint /mnt/rec local
rec_01 compression gzip local
rec_01 atime off local
rec_01 xattr off temporary

sambaから見たプロパティ
zfs_compression_gzip.png
-----

と、こんなもん。

compression=offとcompression=lzjbは、見た目には変わりない。
あったとしても、数MB単位程度なので捨て置ける。

compression=gzipは少しだけ数値上の変化が見受けられたが、
CPUがLE-1250だからか、メモリが4GBしかないからか、断続的な転送休止があって転送効率は非常に悪い。
具体的にはSamba上で40MB/secが7MB/secに落ちるくらい。

同gzip条件下における駄目ゲーのセーブデータは思いのほか縮むので、
/usrをcompressionするには向くんだろうなぁ。


一旦閉じ。

PageTop

とりあえず一式。

えーき様、てるよ様、うどん、きゅうりのスリーブ。
れーむ、れみ様、マーガトロイドさん、ゆーかちゃんのカードケース。
IMG_0198.jpg

これで質実剛健なカードケースからおさらばさ!
(いや、質実剛健の方がいい気がするけども。
カードケースは若干ポピュラーなモノより厚みが短い。
エクストラは分けるか。

PageTop

消失。

色々と予定が立ち消えたので、涼宮ハルヒの消失を見てきましたよ。

MXの超額縁をエンコした関係で、映画の3Dっぽい部分とかのエンコ設定を練りつつ、
地上波放送を心待ちにするのでした。
(エンドレスエイトねぇ・・・映画で少し気が済んだ)

つづきを表示

PageTop

こんなんあるんだっけ

journal_001.png
簡単にグラフを描いて、僕の体重を晒すよ。みたいなのを付加価値少なめで。

PageTop
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。