<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>unos.biz &#187; NAS</title>
	<atom:link href="http://unos.biz/blog/archives/category/nas/feed" rel="self" type="application/rss+xml" />
	<link>http://unos.biz/blog</link>
	<description>環境と思想と日常と.</description>
	<lastBuildDate>Wed, 21 Jul 2010 05:49:08 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>opensolaris/rgeドライバ</title>
		<link>http://unos.biz/blog/archives/591</link>
		<comments>http://unos.biz/blog/archives/591#comments</comments>
		<pubDate>Tue, 06 Jul 2010 22:34:34 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[Network]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/archives/591</guid>
		<description><![CDATA[ファイルサーバに大量にファイルを突っ込んでいると、転送が途中で中断されてしまう。そのときすぐにサーバにsshしてもつながらない。しかしエラーログには何も残っていない。そんな状態になっていて、何が原因なのかさっぱりわからなかった。
どうも、これ(というかDuplicate/closeされているがこっち)が原因なんではないかという気がしてきた。曰く、
During a large file transfer, a card using the RGE driver drops off the network. Its not related to the hwchecksum bug (I&#8217;ve tried with and without that option in /etc/system) On 106 it happens after 25-30 gigs, on 101 (2008.11) it happened between 10 and 15 gb transferred.

とのこと。うちでも数GB以上の転送でひっかかったりして困っていた。うちのファイルサーバのOSはopensolaris snv111bなのだが、修正はsnv131にコミットされたとある。
次の公式リリースはいつか調べていたのだが、どうもSun Microsystemsがオラクルに買収されたりした関係できな臭いにおいが漂ってきている気がしてならない。wikipediaが先走っているだけかも知れないが、ここによれば次のリリースは2010.03だったようでもう四半期も放置されてしまっている。
あまり良いとは思わないが、devを追うべき、なのかもしれない。やれやれ。
]]></description>
			<content:encoded><![CDATA[<p>ファイルサーバに大量にファイルを突っ込んでいると、転送が途中で中断されてしまう。そのときすぐにサーバにsshしてもつながらない。しかしエラーログには何も残っていない。そんな状態になっていて、何が原因なのかさっぱりわからなかった。</p>
<p>どうも、<a href="http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6892693" target="_blank">これ</a>(というかDuplicate/closeされているが<a href="http://bugs.opensolaris.org/view_bug.do?bug_id=6807184" target="_blank">こっち</a>)が原因なんではないかという気がしてきた。曰く、</p>
<blockquote><p>During a large file transfer, a card using the RGE driver drops off the network. Its not related to the hwchecksum bug (I&#8217;ve tried with and without that option in /etc/system) On 106 it happens after 25-30 gigs, on 101 (2008.11) it happened between 10 and 15 gb transferred.</p>
</blockquote>
<p>とのこと。うちでも数GB以上の転送でひっかかったりして困っていた。うちのファイルサーバのOSはopensolaris snv111bなのだが、修正はsnv131にコミットされたとある。</p>
<p>次の公式リリースはいつか調べていたのだが、どうもSun Microsystemsがオラクルに買収されたりした関係できな臭いにおいが漂ってきている気がしてならない。wikipediaが先走っているだけかも知れないが、<a href="http://ja.wikipedia.org/wiki/OpenSolaris" target="_blank">ここ</a>によれば次のリリースは2010.03だったようでもう四半期も放置されてしまっている。</p>
<p>あまり良いとは思わないが、devを追うべき、なのかもしれない。やれやれ。</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/591/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>非グローバルゾーンでsamba</title>
		<link>http://unos.biz/blog/archives/586</link>
		<comments>http://unos.biz/blog/archives/586#comments</comments>
		<pubDate>Sun, 27 Jun 2010 14:42:54 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>
		<category><![CDATA[samba]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/archives/586</guid>
		<description><![CDATA[OpenSolaris 2009.06(snv111b)での話。
非グローバルゾーンでsamba(SUNWsmba)を動かそうと思っても、そのままでは下記のようなエラーが/var/samba/log/log.smbdに残ってしまって動かない。smb.confがないのと違ってsvcs的にはonlineになるが、netstat -aで見るとlistenしていないのがわかる。
[2010/06/27 05:44:16, 0] lib/util_sock.c:(822)
  bind failed on port 445 socket_addr = 0.0.0.0.
  Error = Permission denied
さらに、nmbd(svcsの名前だとwins)のほうはsvcsで見るとmaintenance状態になっていることがわかる。
これは、非グローバルゾーンでの特権が足りないせいなので、zonecfgを使ってlimitprivを追加してやる。うちでは内部的に使っているサーバなので大変緩く、下記のようにした。(長いけど続けて)
set limitprev = default,file_downgrade_sl,file_upgrade_sl,
sys_trans_label,win_colormap,win_config,
win_dac_read,win_dac_write,win_devices,
win_fontpath,win_mac_read,win_mac_write,
win_selection,sys_smb
これでzoneを再起動してやるとsambaがlistenするようになる。セキュリティ的になんでもかんでもつけるのが嫌であれば、ここのglobal: limitprivのところを読んで適宜付け替えるとよい。
&#160;
余談。opensolarisのブートディスクが壊れたのでこういうことをやっているのだが、zfsは新しくインストールし直した環境からzpool importするだけで構成情報まで含めて一発でとってきてくれるのがなんともうれしい。そういう都合から、sambaまで含めて全部zfs上のzoneに乗せてしまいたいのでこういうことをした次第。グローバルゾーンはハイパーバイザー代わりで十分。:-)
]]></description>
			<content:encoded><![CDATA[<p>OpenSolaris 2009.06(snv111b)での話。</p>
<p>非グローバルゾーンでsamba(SUNWsmba)を動かそうと思っても、そのままでは下記のようなエラーが/var/samba/log/log.smbdに残ってしまって動かない。smb.confがないのと違ってsvcs的にはonlineになるが、netstat -aで見るとlistenしていないのがわかる。</p>
<pre>[2010/06/27 05:44:16, 0] lib/util_sock.c:(822)
  bind failed on port 445 socket_addr = 0.0.0.0.
  Error = Permission denied</pre>
<p>さらに、nmbd(svcsの名前だとwins)のほうはsvcsで見るとmaintenance状態になっていることがわかる。</p>
<p>これは、非グローバルゾーンでの特権が足りないせいなので、zonecfgを使ってlimitprivを追加してやる。うちでは内部的に使っているサーバなので大変緩く、下記のようにした。(長いけど続けて)</p>
<pre>set limitprev = default,file_downgrade_sl,file_upgrade_sl,
sys_trans_label,win_colormap,win_config,
win_dac_read,win_dac_write,win_devices,
win_fontpath,win_mac_read,win_mac_write,
win_selection,sys_smb</pre>
<p>これでzoneを再起動してやるとsambaがlistenするようになる。セキュリティ的になんでもかんでもつけるのが嫌であれば、<a href="http://docs.sun.com/app/docs/doc/819-1211/zonecfg-1m?l=en&amp;n=1&amp;a=view" target="_blank">ここ</a>のglobal: limitprivのところを読んで適宜付け替えるとよい。</p>
<p>&#160;</p>
<p>余談。opensolarisのブートディスクが壊れたのでこういうことをやっているのだが、zfsは新しくインストールし直した環境からzpool importするだけで構成情報まで含めて一発でとってきてくれるのがなんともうれしい。そういう都合から、sambaまで含めて全部zfs上のzoneに乗せてしまいたいのでこういうことをした次第。グローバルゾーンはハイパーバイザー代わりで十分。:-)</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/586/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NAS起動せず?</title>
		<link>http://unos.biz/blog/archives/354</link>
		<comments>http://unos.biz/blog/archives/354#comments</comments>
		<pubDate>Mon, 31 Aug 2009 13:40:36 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/archives/354</guid>
		<description><![CDATA[先日、ふと気づいたらNASからの応答がなくなっていた。コンソールから見ても完全に死んでいるようなので仕方なく強制的に電源OFFして電源を入れ直したのだがいくら待ってもあがってこない。見てみると起動途中でpanicして再起動、というループにはまっている様子。何が起きたかわからないがとりあえず面倒だなぁと思いつつトラブルシュートした。
現象：    起動中にpanic。どうもc6t0d0(これこの間交換した玉だな、、)のアクセスランプがつきっぱなしになってpanicしている様子。とりあえず該当の玉を引っこ抜いてからmessagesを見てみると、
Aug 10 02:29:07 melongena genunix: [ID 103648 kern.notice] recursive mutex_enter, lp=ffffff014b1cd768 owner=ffffff0003eb9c60 thread=ffffff0003eb9c60
でpanic、エラーログを吐いてリブートしている。
エラーログから色々調べてみると、どうもこれ(Bug ID: 6786704)くさい。Acceptされてはいるが、まだ修正されていない既知のバグ。それによれば、

Crash occurs generally when a bad block is found on a disk; driver appears to be unable to deal with the resulting bus reset.

とある。
ならば調査と、Windowsマシンに繋いでCrystalDiskInfoでS.M.A.R.T.の値を見てみると、代替処理済みのセクタ数が0&#215;9、代替処理保留中のセクタ数が0&#215;21、回復不可能セクタ数が0xfとなっていて「注意」状態。というか回復不可能セクタが出ている時点でもう駄目ぽ。理由はわからないが元々駄目なやつを引いたのだろう。
近く新しい玉を買ってきて入れ替えるつもりではいるが、si3124を使っている場合、突然落ちて再起動すら正常にいかないケースがある、ということを覚えておく必要がありそうだ。
]]></description>
			<content:encoded><![CDATA[<p>先日、ふと気づいたらNASからの応答がなくなっていた。コンソールから見ても完全に死んでいるようなので仕方なく強制的に電源OFFして電源を入れ直したのだがいくら待ってもあがってこない。見てみると起動途中でpanicして再起動、というループにはまっている様子。何が起きたかわからないがとりあえず面倒だなぁと思いつつトラブルシュートした。</p>
<p>現象：    <br />起動中にpanic。どうもc6t0d0(これこの間交換した玉だな、、)のアクセスランプがつきっぱなしになってpanicしている様子。とりあえず該当の玉を引っこ抜いてからmessagesを見てみると、</p>
<pre>Aug 10 02:29:07 melongena genunix: [ID 103648 kern.notice] recursive mutex_enter, lp=ffffff014b1cd768 owner=ffffff0003eb9c60 thread=ffffff0003eb9c60</pre>
<p>でpanic、エラーログを吐いてリブートしている。</p>
<p>エラーログから色々調べてみると、どうも<a href="http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6786704" target="_blank">これ(Bug ID: 6786704)</a>くさい。Acceptされてはいるが、まだ修正されていない既知のバグ。それによれば、</p>
<blockquote>
<p>Crash occurs generally when a bad block is found on a disk; driver appears to be unable to deal with the resulting bus reset.</p>
</blockquote>
<p>とある。</p>
<p>ならば調査と、Windowsマシンに繋いでCrystalDiskInfoでS.M.A.R.T.の値を見てみると、代替処理済みのセクタ数が0&#215;9、代替処理保留中のセクタ数が0&#215;21、回復不可能セクタ数が0xfとなっていて「注意」状態。というか回復不可能セクタが出ている時点でもう駄目ぽ。理由はわからないが元々駄目なやつを引いたのだろう。</p>
<p>近く新しい玉を買ってきて入れ替えるつもりではいるが、si3124を使っている場合、突然落ちて再起動すら正常にいかないケースがある、ということを覚えておく必要がありそうだ。</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/354/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NASの玉交換</title>
		<link>http://unos.biz/blog/archives/338</link>
		<comments>http://unos.biz/blog/archives/338#comments</comments>
		<pubDate>Sun, 02 Aug 2009 05:59:56 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/archives/338</guid>
		<description><![CDATA[ 
一時期さんざん記事を書いたNASだが、ついに１発トラブルが起きた。アクセスランプがつきっぱなしになっていたので見てみると、
  pool: tank
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark [...]]]></description>
			<content:encoded><![CDATA[<p><img title="再構築中......" style="border-top-width: 0px; display: inline; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px" height="315" alt="再構築中......" src="http://unos.biz/blog/wp-content/uploads/2009/08/snapshot1249191928227595.jpg" width="420" border="0" /> </p>
<p>一時期さんざん記事を書いたNASだが、ついに１発トラブルが起きた。アクセスランプがつきっぱなしになっていたので見てみると、</p>
<pre>  pool: tank
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
        repaired.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2    DEGRADED     0     0     0
            c5t0d0  ONLINE       0     0     0
            c6t0d0  FAULTED      8   205     0  too many errors
            c5t1d0  ONLINE       0     0     0
            c6t1d0  ONLINE       0     0     0
            c5t2d0  ONLINE       0     0     0
            c6t2d0  ONLINE       0     0     0
            c5t3d0  ONLINE       0     0     0
            c6t3d0  ONLINE       0     0     0
        spares
          c3d1      AVAIL</pre>
<p>とのこと。何が原因かわからないが、とりあえず書き込みエラーが頻発している玉(HDD/c6t6d0)があるようだ。とりあえず<a href="http://docs.sun.com/app/docs/doc/819-6260/gbcet?l=ja&amp;a=view" target="_blank">こちら</a>を参考にしつつ、下記のように作業。ホットスワップ非対応であればいったんシャットダウンしてからHDDを取り替え、4の手順からやれば良いはず。</p>
<p>1)玉を外す準備</p>
<p>cfgadmコマンド(引数なし)でデバイス一覧が出るので、その中から問題の起きている玉を見つけて、unconfigureする。unconfigureしたらcfgadmで一覧を確認して、unconfigure状態になっていることを確認。</p>
<pre>root@melongena:~# <strong>cfgadm</strong>
Ap_Id                          Type         Receptacle   Occupant     Condition
sata4/0::dsk/c5t0d0            disk         connected    configured   ok
sata4/1::dsk/c5t1d0            disk         connected    configured   ok
sata4/2::dsk/c5t2d0            disk         connected    configured   ok
sata4/3::dsk/c5t3d0            disk         connected    configured   ok
sata5/0::dsk/c6t0d0            disk         connected    configured   ok
sata5/1::dsk/c6t1d0            disk         connected    configured   ok
sata5/2::dsk/c6t2d0            disk         connected    configured   ok
sata5/3::dsk/c6t3d0            disk         connected    configured   ok
～略～
root@melongena:~# <strong>cfgadm -c unconfigure sata5/0::dsk/c6t0d0</strong>
Unconfigure the device at: /devices/pci@0,0/pci8086,244e@1e/pci1095,3124@1:0
This operation will suspend activity on the SATA device
Continue (yes/no)? <strong>yes</strong>
root@melongena:~# <strong>cfgadm</strong>
Ap_Id                          Type         Receptacle   Occupant     Condition
sata4/0::dsk/c5t0d0            disk         connected    configured   ok
sata4/1::dsk/c5t1d0            disk         connected    configured   ok
sata4/2::dsk/c5t2d0            disk         connected    configured   ok
sata4/3::dsk/c5t3d0            disk         connected    configured   ok
sata5/0                        disk         connected    unconfigured ok
sata5/1::dsk/c6t1d0            disk         connected    configured   ok
sata5/2::dsk/c6t2d0            disk         connected    configured   ok
sata5/3::dsk/c6t3d0            disk         connected    configured   ok
～略～</pre>
<p>2)玉を外す</p>
<p>おもむろに玉を外して予備の玉に付け替えて元の位置に挿入。cfgadmではemptyになる。</p>
<pre>root@melongena:~# <strong>cfgadm</strong>
Ap_Id                          Type         Receptacle   Occupant     Condition
sata4/0::dsk/c5t0d0            disk         connected    configured   ok
sata4/1::dsk/c5t1d0            disk         connected    configured   ok
sata4/2::dsk/c5t2d0            disk         connected    configured   ok
sata4/3::dsk/c5t3d0            disk         connected    configured   ok
sata5/0                        sata-port    empty        unconfigured ok
sata5/1::dsk/c6t1d0            disk         connected    configured   ok
sata5/2::dsk/c6t2d0            disk         connected    configured   ok
sata5/3::dsk/c6t3d0            disk         connected    configured   ok
～略～</pre>
<p>3)再度玉を認識させる</p>
<p>cfgadmで該当のポートにHDDが認識され、unconfigure状態になっていることを確認したら、1の手順と同じく、今度はconfigureする。</p>
<pre>root@melongena:~# <strong>cfgadm</strong>
Ap_Id                          Type         Receptacle   Occupant     Condition
sata4/0::dsk/c5t0d0            disk         connected    configured   ok
sata4/1::dsk/c5t1d0            disk         connected    configured   ok
sata4/2::dsk/c5t2d0            disk         connected    configured   ok
sata4/3::dsk/c5t3d0            disk         connected    configured   ok
sata5/0                        disk         connected    unconfigured unknown
sata5/1::dsk/c6t1d0            disk         connected    configured   ok
sata5/2::dsk/c6t2d0            disk         connected    configured   ok
sata5/3::dsk/c6t3d0            disk         connected    configured   ok
～略～
root@melongena:~# <strong>cfgadm -c configure sata5/0::dsk/c6t0d0</strong>
root@melongena:~# <strong>cfgadm</strong>
Ap_Id                          Type         Receptacle   Occupant     Condition
sata4/0::dsk/c5t0d0            disk         connected    configured   ok
sata4/1::dsk/c5t1d0            disk         connected    configured   ok
sata4/2::dsk/c5t2d0            disk         connected    configured   ok
sata4/3::dsk/c5t3d0            disk         connected    configured   ok
sata5/0::dsk/c6t0d0            disk         connected    configured   ok
sata5/1::dsk/c6t1d0            disk         connected    configured   ok
sata5/2::dsk/c6t2d0            disk         connected    configured   ok
sata5/3::dsk/c6t3d0            disk         connected    configured   ok
～略～</pre>
<p>4)zfsに玉が交換されたことを通知する</p>
<p>これで、後は勝手にresilver(再構築)が行われる。うちの場合は1.5%ほど進んだ状態で残り5h28mと出た。うちはPCIバスに4ポートSATAカードを２枚挿して、PCIバスが律速になってしまっているので特にひどく遅いが、そうでなくてもそこそこ時間がかかる。<br />
  <br />暇にあかして時々statusを見ていたら、ぱらぱらとチェックサムエラーがほかのドライブで出たりしていることに気がついた。ケーブルの品質がやたら悪い(1本100円のケーブルが混じっている)のが原因なのだろうと思うが、本当に駄目なケーブルは以前さんざんひどい目にあって抜いてあるのでキニシナイことにする(真似してはいけませんw)。パリティが二重にあることも、この辺を深く気にしなくてすむ理由。</p>
<pre>root@melongena:~# zpool replace tank c6t0d0
root@melongena:~# zpool status
～略～
  pool: tank
 state: DEGRADED
 scrub: scrub in progress for 0h0m, 0.00% done, 378h41m to go
config:

        NAME              STATE     READ WRITE CKSUM
        tank              DEGRADED     0     0     0
          raidz2          DEGRADED     0     0     0
            c5t0d0        ONLINE       0     0     0
            replacing     DEGRADED     0     0 5.40K
              c6t0d0s0/o  FAULTED      8   205     0  too many errors
              c6t0d0      ONLINE       0     0     0
            c5t1d0        ONLINE       0     0     0
            c6t1d0        ONLINE       0     0     0
            c5t2d0        ONLINE       0     0     0
            c6t2d0        ONLINE       0     0     0
            c5t3d0        ONLINE       0     0     0
            c6t3d0        ONLINE       0     0     0
        spares
          c3d1            AVAIL

errors: No known data errors</pre>
<p>外した玉は別の機械で一日ほどエラーチェックし続けて、問題があるようだったら購入した店へ持ち込もうと思う。</p>
<p>追記：<br />
  <br />翌日見てみたら作業が終わっていた。どーもチェックサムエラーがぽちぽち出ている。次のメンテナンス時にはケーブルを変えた方がいいかもしれない。。</p>
<pre>root@melongena:~# <strong>zpool status</strong>
～略～
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-9P
 scrub: resilver completed after 5h20m with 0 errors on Sun Aug  2 19:52:20 2009
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2    ONLINE       0     0     0
            c5t0d0  ONLINE       0     0     5  108K resilvered
            c6t0d0  ONLINE       0     0     0  178G resilvered
            c5t1d0  ONLINE       0     0     0
            c6t1d0  ONLINE       0     0     0
            c5t2d0  ONLINE       0     0     0
            c6t2d0  ONLINE       0     0     0
            c5t3d0  ONLINE       0     0     5  108K resilvered
            c6t3d0  ONLINE       0     0     3  64.5K resilvered
        spares
          c3d1      AVAIL

errors: No known data errors</pre>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/338/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>新NAS落ち着いた</title>
		<link>http://unos.biz/blog/archives/318</link>
		<comments>http://unos.biz/blog/archives/318#comments</comments>
		<pubDate>Wed, 20 May 2009 19:39:30 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/archives/318</guid>
		<description><![CDATA[ 
先日から延々５ポスト(コレ含めて６ポスト)もかけたNASだが、ついに落ち着いた。先日からまた延々zpool scrubを掛けて掛けてエラーが出たらケーブルを取り替えての繰り返し、結局３本の不良ケーブルが混じっていたようであった。
結局さんざん苦労した代償として、下記のことに注意しておかねばならない、という教訓を得た。

NASとするコンピュータのメモリはmemtest86などのツールできっちりテストしておく。出来れば(というかほぼMUST)ECC付きメモリにすること。
SATAケーブルは良質な物を選ぶこと。１本100円のような安売りのものを買わないこと。(大変時間を無駄にした・・・)
構築後、きっちり負荷を掛けたり引っこ抜いたりしてテストすること。データを失ってからでは遅い。(サーバなら最低数日のエージングは当然だが)

特に１点目のメモリ問題は怖い。私の場合、memtest86で１周できないメモリが刺さっていたがために、zfsのraidz2領域すべてが完全に修復不能なレベルでつぶれてしまった。特に酷いメモリをつかんでしまったのだろうとは思うが、同じことをクリティカルな要件で起こしてしまってはしゃれにならない。家庭用であったとしても、データを失ってしまえばもうそのデータは二度と帰ってこない。そのことを考えたら一晩memtestを走らせておくくらい軽いものだろう。
最終的にかかったコストは、HDDが予備含め10本で75,000円ほど、M/B、メモリ、CPUで20,000円ほど、SATA I/Fが２枚で15,000円ほど、ケースが12,000円ほど(これは無茶苦茶な破格だった)と、ケースのファンがうるさすぎて全部交換したので5000円ほど、合計で127,000円程度(システム用HDDはジャンク箱に突っ込んであった160GBを流用)で収まった。ダブルパリティで保護された6TBの領域を持つNASとしてはきわめて安価だといえよう。
次は各種サービスをsolaris containerで動かしていこうと思う。opensolarisのポテンシャルの高さに、気がついたら全然NASでなくなりつつある。
]]></description>
			<content:encoded><![CDATA[<p><img style="border-right: 0px; border-top: 0px; border-left: 0px; border-bottom: 0px" height="315" alt="new NAS" src="http://unos.biz/blog/wp-content/uploads/2009/05/img-0306.jpg" width="420" border="0" /> </p>
<p>先日から延々５ポスト(コレ含めて６ポスト)もかけたNASだが、ついに落ち着いた。先日からまた延々zpool scrubを掛けて掛けてエラーが出たらケーブルを取り替えての繰り返し、結局３本の不良ケーブルが混じっていたようであった。</p>
<p>結局さんざん苦労した代償として、下記のことに注意しておかねばならない、という教訓を得た。</p>
<ul>
<li>NASとするコンピュータのメモリはmemtest86などのツールできっちりテストしておく。出来れば(というかほぼMUST)ECC付きメモリにすること。</li>
<li>SATAケーブルは良質な物を選ぶこと。１本100円のような安売りのものを買わないこと。(大変時間を無駄にした・・・)</li>
<li>構築後、きっちり負荷を掛けたり引っこ抜いたりしてテストすること。データを失ってからでは遅い。(サーバなら最低数日のエージングは当然だが)</li>
</ul>
<p>特に１点目のメモリ問題は怖い。私の場合、memtest86で１周できないメモリが刺さっていたがために、zfsのraidz2領域すべてが完全に修復不能なレベルでつぶれてしまった。特に酷いメモリをつかんでしまったのだろうとは思うが、同じことをクリティカルな要件で起こしてしまってはしゃれにならない。家庭用であったとしても、データを失ってしまえばもうそのデータは二度と帰ってこない。そのことを考えたら一晩memtestを走らせておくくらい軽いものだろう。</p>
<p>最終的にかかったコストは、HDDが予備含め10本で75,000円ほど、M/B、メモリ、CPUで20,000円ほど、SATA I/Fが２枚で15,000円ほど、ケースが12,000円ほど(これは無茶苦茶な破格だった)と、ケースのファンがうるさすぎて全部交換したので5000円ほど、合計で127,000円程度(システム用HDDはジャンク箱に突っ込んであった160GBを流用)で収まった。ダブルパリティで保護された6TBの領域を持つNASとしてはきわめて安価だといえよう。</p>
<p>次は各種サービスをsolaris containerで動かしていこうと思う。opensolarisのポテンシャルの高さに、気がついたら全然NASでなくなりつつある。</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/318/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
