<?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; opensolaris</title>
	<atom:link href="http://unos.biz/blog/archives/category/opensolaris/feed" rel="self" type="application/rss+xml" />
	<link>http://unos.biz/blog</link>
	<description>環境と思想と日常と.</description>
	<lastBuildDate>Sun, 11 Mar 2012 07:35:52 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>openindianaとFreeBSDのzfs互換性</title>
		<link>http://unos.biz/blog/archives/719</link>
		<comments>http://unos.biz/blog/archives/719#comments</comments>
		<pubDate>Wed, 02 Nov 2011 08:03:35 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/?p=719</guid>
		<description><![CDATA[opensolarisが、というよりはsolarisが守銭奴様に買収されて久しい。 うちはファイルサーバにopensolarisを使っているのだが、この際solarisの一番安いライセンスが現実的な値段であればO社と契約しようかとも思ったのだが、だいぶ非現実的な価格だったこともあって契約に至らず、かといってopensolarisは状況が状況で、ということで移行先に悩んでいた。 移行先はいくつかあるが、その中でも一番手間無くすっと移行できそうなのがopenindiana。出た当初はちょっと手間が要りそうな気配ではあったが今はだいぶ手軽に使える模様、VM上で色々テスト中だ。 ところでうちは昔はよくFreeBSDを使っていた。しばらく使わなくなってしまっていたが、zfsのOS間互換がどれくらい効くのか知りたくて、FreeBSD9-RC1を入れてみた。試すのは、zfsのアレイを相互のOS間で入れ替えて使えるのか、だ。 まず環境。openindianaについては先日の記事の通り。あの後、pkg image-update &#8211;be-name solaris-151として、openindiana 151aにアップデートしたがその程度の違い。いずれも、zfs version5とzfs pool version28がサポートされている。 FreeBSDは、0.5GBのSCSIディスクを3台追加(/dev/da1, /dev/da2, /dev/da3)してから、それぞれにfdiskで500MBのスライス(partition type=191(=0xbf, Solaris(new)))を作成した。それぞれ/dev/daNs1となっている。こんな感じ。 freebsd# fdisk /dev/da1 ******* Working on device /dev/da1 ******* parameters extracted from in-core disklabel are: cylinders=512 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=512 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 512 [...]]]></description>
			<content:encoded><![CDATA[<p>opensolarisが、というよりはsolarisが守銭奴様に買収されて久しい。</p>
<p>うちはファイルサーバにopensolarisを使っているのだが、この際solarisの一番安いライセンスが現実的な値段であればO社と契約しようかとも思ったのだが、だいぶ非現実的な価格だったこともあって契約に至らず、かといってopensolarisは状況が状況で、ということで移行先に悩んでいた。</p>
<p>移行先はいくつかあるが、その中でも一番手間無くすっと移行できそうなのがopenindiana。出た当初はちょっと手間が要りそうな気配ではあったが今はだいぶ手軽に使える模様、VM上で色々テスト中だ。</p>
<p>ところでうちは昔はよくFreeBSDを使っていた。しばらく使わなくなってしまっていたが、zfsのOS間互換がどれくらい効くのか知りたくて、FreeBSD9-RC1を入れてみた。試すのは、zfsのアレイを相互のOS間で入れ替えて使えるのか、だ。</p>
<p><span id="more-719"></span></p>
<p>まず環境。openindianaについては<a href="http://unos.biz/blog/archives/690" target="_blank">先日の記事</a>の通り。あの後、pkg image-update &#8211;be-name solaris-151として、openindiana 151aにアップデートしたがその程度の違い。いずれも、zfs version5とzfs pool version28がサポートされている。</p>
<p>FreeBSDは、0.5GBのSCSIディスクを3台追加(/dev/da1, /dev/da2, /dev/da3)してから、それぞれにfdiskで500MBのスライス(partition type=191(=0xbf, Solaris(new)))を作成した。それぞれ/dev/daNs1となっている。こんな感じ。</p>
<pre>
freebsd# fdisk /dev/da1
******* Working on device /dev/da1 *******
parameters extracted from in-core disklabel are:
cylinders=512 heads=64 sectors/track=32 (2048 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=512 heads=64 sectors/track=32 (2048 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 191 (0xbf),(Solaris x86 (new))
    start 32, size 1023968 (499 Meg), flag 0
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 499/ head 63/ sector 32
The data for partition 2 is:
&lt;UNUSED&gt;
The data for partition 3 is:
&lt;UNUSED&gt;
The data for partition 4 is:
&lt;UNUSED&gt;
</pre>
<p>これで、</p>
<pre>
freebsd# zpool create tank raidz1 /dev/da1s1 /dev/da2s1 /dev/da3s1
</pre>
<p>してやって、このようにzpoolを作ることが出来る。</p>
<pre>
freebsd# zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub repaired 0 in 0h0m with 0 errors on Wed Nov  2 16:25:18 2011
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz1-0  ONLINE       0     0     0
	    da1s1   ONLINE       0     0     0
	    da2s1   ONLINE       0     0     0
	    da3s1   ONLINE       0     0     0

errors: No known data errors
</pre>
<p>ここからが本番。これでFreeBSD側をシャットダウンして(*)、openindiana側のディスクとしてこれら3本のディスクを追加。openindiana側を起動する。でおもむろにimportしてみると。</p>
<pre>
root@solaris:~# zpool import
  pool: tank
    id: 7276812488085196296
 state: ONLINE
status: The pool was last accessed by another system.
action: The pool can be imported using its name or numeric identifier and
        the '-f' flag.
   see: http://www.sun.com/msg/ZFS-8000-EY
config:

        tank           ONLINE
          raidz1-0     ONLINE
            c2t8d0p1   ONLINE
            c2t9d0p1   ONLINE
            c2t10d0p1  ONLINE
</pre>
<p>他のシステムで使ってるよって怒られてしまう(exportを忘れたためか)が、指示の通り名前を指定してimportしてみると、すでにtankという名前のzpoolがあるのでまたも怒られてしまう。で、新しい名前も指定してやると、こうなる。</p>
<pre>
root@solaris:~# zpool import -f tank tankbsd
root@solaris:~# zpool status
  pool: rpool
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c2t0d0s0  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: resilvered 63K in 0h0m with 0 errors on Tue Jun 28 18:55:01 2011
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz1-0    ONLINE       0     0     0
            c2t3d0s0  ONLINE       0     0     0
            c2t4d0s0  ONLINE       0     0     0
            c2t6d0s0  ONLINE       0     0     0

errors: No known data errors

  pool: tankbsd
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Wed Nov  2 16:25:18 2011
config:

        NAME           STATE     READ WRITE CKSUM
        tankbsd        ONLINE       0     0     0
          raidz1-0     ONLINE       0     0     0
            c2t8d0p1   ONLINE       0     0     0
            c2t9d0p1   ONLINE       0     0     0
            c2t10d0p1  ONLINE       0     0     0

errors: No known data errors
</pre>
<p>この通り。中にあったデータもとりあえずファイルの中身は問題なく扱うことが出来た。uid/gidもそのまま、日付時刻も同じ。ちなみに、この状態でopenindianaをシャットダウンして(*)、FreeBSD側を起動(まだ同じdiskはマウントしている)すると、このパーティションのマウントに失敗する。もう一度FreeBSD側でimportしてやれば読むことは可能だ。</p>
<p>結論としては、どうやらあまり凝ったことをしなければ、openindianaとFreeBSDの間でzpoolを移行することはさして難しくない、ということになるだろう。参考になれば幸い。</p>
<p>&#8211;追記(2011/11/04)</p>
<p>よく見たら、インポート後にopenindiana側で見た玉のディスク名がc2t8d0p1とかになっていることに気がついた。論理ディスク名は<a href="http://download.oracle.com/docs/cd/E19455-01/806-2717/6jbtqleep/index.html" taget="_blank">ここ</a>にあるように、c[論理コントローラ番号]t[論理バスターゲット番号]d[ドライブ番号]となって、その後ろにs[スライス番号]もしくはp[fdiskバーティション番号]が付く。うっかり癖でfdiskパーティション(FreeBSDのfdiskだとスライスって書いてあるのがややこしい)を切ったのが原因だったわけで、適当にopenindianaで試したときのようにs0になるように切りたければ、use entire diskしておきつつdisklabelで末尾がaのFreeBSDパーティション(これがsolarisだとスライス)を作っておけばいいんじゃなかろうか。そうなるとda1s1aとかになるはず。そのうち暇が出来て必要になったら検証してみよう。</p>
<p>(*)どっちもexportを忘れた。だからいちいちimportで怒られるのだと思われる。</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/719/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>zfs久々に試す</title>
		<link>http://unos.biz/blog/archives/690</link>
		<comments>http://unos.biz/blog/archives/690#comments</comments>
		<pubDate>Tue, 28 Jun 2011 10:05:09 +0000</pubDate>
		<dc:creator>ゆのじ</dc:creator>
				<category><![CDATA[NAS]]></category>
		<category><![CDATA[opensolaris]]></category>

		<guid isPermaLink="false">http://unos.biz/blog/?p=690</guid>
		<description><![CDATA[前からどうしようと思っていたNASのリプレイスのため、いくつか試験してみたのでメモ。環境はさっきダウンロードしてきたOpenIndiana(io_148) x86/64bitをVMWare上で動かした物。c2t0d0が起動ディスクで、c2t1d0, c2t2d0, c2t5d0が200MBの玉、c2t3d0, c2t4d0, c2t6d0が400MBの玉。連番じゃないのはちょっとミスしたからで他意はない。 容量制限したスライスでpool 市販されているHDDは、1TBと書いてあっても1TB(1 * 1000 * 1000 * 1000 * 1000 bytes)ではなくてそれよりいくらか多いのが普通だ。そのため、HDDをそのまま全容量でつかっていると、故障などの際に簡単に入れ替えられなくなる。それどころか違うインタフェイスに繋いだだけでそうなることもあるので(なっているので)、そうならないように容量制限したスライスを切って、スライスでRAIDZ1を組んでみる。 formatする root@solaris:~# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c2t0d0 /pci@0,0/pci15ad,1976@10/sd@0,0 1. c2t1d0 /pci@0,0/pci15ad,1976@10/sd@1,0 2. c2t2d0 /pci@0,0/pci15ad,1976@10/sd@2,0 3. c2t3d0 /pci@0,0/pci15ad,1976@10/sd@3,0 4. c2t4d0 /pci@0,0/pci15ad,1976@10/sd@4,0 5. c2t5d0 /pci@0,0/pci15ad,1976@10/sd@5,0 6. c2t6d0 /pci@0,0/pci15ad,1976@10/sd@6,0 Specify disk (enter its number): 1 selecting c2t1d0 [...]]]></description>
			<content:encoded><![CDATA[<p>前からどうしようと思っていたNASのリプレイスのため、いくつか試験してみたのでメモ。環境はさっきダウンロードしてきたOpenIndiana(io_148) x86/64bitをVMWare上で動かした物。c2t0d0が起動ディスクで、c2t1d0, c2t2d0, c2t5d0が200MBの玉、c2t3d0, c2t4d0, c2t6d0が400MBの玉。連番じゃないのはちょっとミスしたからで他意はない。</p>
<h3>容量制限したスライスでpool</h3>
<p>市販されているHDDは、1TBと書いてあっても1TB(1 * 1000 * 1000 * 1000 * 1000 bytes)ではなくてそれよりいくらか多いのが普通だ。そのため、HDDをそのまま全容量でつかっていると、故障などの際に簡単に入れ替えられなくなる。それどころか違うインタフェイスに繋いだだけでそうなることもあるので(なっているので)、そうならないように容量制限したスライスを切って、スライスでRAIDZ1を組んでみる。</p>
<p><span id="more-690"></span></p>
<h4>formatする</h4>
<pre>root@solaris:~# format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
       0. c2t0d0 <VMware,-VMware Virtual -1.0  cyl 4093 alt 2 hd 128 sec 32>
          /pci@0,0/pci15ad,1976@10/sd@0,0
       1. c2t1d0 <VMware,-VMware Virtual S-1.0-204.80MB>
          /pci@0,0/pci15ad,1976@10/sd@1,0
       2. c2t2d0 <VMware,-VMware Virtual S-1.0-204.80MB>
          /pci@0,0/pci15ad,1976@10/sd@2,0
       3. c2t3d0 <VMware,-VMware Virtual S-1.0-409.60MB>
          /pci@0,0/pci15ad,1976@10/sd@3,0
       4. c2t4d0 <VMware,-VMware Virtual S-1.0-409.60MB>
          /pci@0,0/pci15ad,1976@10/sd@4,0
       5. c2t5d0 <VMware,-VMware Virtual S-1.0-204.80MB>
          /pci@0,0/pci15ad,1976@10/sd@5,0
       6. c2t6d0 <VMware,-VMware Virtual S-1.0-409.60MB>
          /pci@0,0/pci15ad,1976@10/sd@6,0
Specify disk (enter its number): 1
selecting c2t1d0
[disk formatted]

FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        fdisk      - run the fdisk program
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !<cmd>     - execute <cmd>, then return
        quit
format> p

PARTITION MENU:
        0      - change `0' partition
        1      - change `1' partition
        2      - change `2' partition
        3      - change `3' partition
        4      - change `4' partition
        5      - change `5' partition
        6      - change `6' partition
        expand - expand label to use whole disk
        select - select a predefined table
        modify - modify a predefined partition table
        name   - name the current table
        print  - display the current table
        label  - write partition map and label to the disk
        !<cmd> - execute <cmd>, then return
        quit
partition> print
Current partition table (original):
Total disk sectors available: 402979 + 16384 (reserved sectors)

Part      Tag    Flag     First Sector      Size      Last Sector
  0        usr    wm               256   196.66MB       403012
  1 unassigned    wm                 0        0            0
  2 unassigned    wm                 0        0            0
  3 unassigned    wm                 0        0            0
  4 unassigned    wm                 0        0            0
  5 unassigned    wm                 0        0            0
  6 unassigned    wm                 0        0            0
  8   reserved    wm            403013     8.00MB       419396    

partition> 0
Part      Tag    Flag     First Sector      Size      Last Sector
  0        usr    wm               256   196.66MB       403012    

Enter partition id tag[usr]:
Enter partition permission flags[wm]:
Enter new starting Sector[256]:
Enter partition size[402757b, 403012e, 196mb, 0gb, 0tb]: 150mb
partition> print
Current partition table (unnamed):
Total disk sectors available: 402979 + 16384 (reserved sectors)

Part      Tag    Flag     First Sector      Size      Last Sector
  0        usr    wm               256   150.00MB       307455
  1 unassigned    wm                 0        0            0
  2 unassigned    wm                 0        0            0
  3 unassigned    wm                 0        0            0
  4 unassigned    wm                 0        0            0
  5 unassigned    wm                 0        0            0
  6 unassigned    wm                 0        0            0
  8   reserved    wm            403013     8.00MB       419396    

partition> label
Ready to label disk, continue? y

partition> quit
</pre>
<p>以下省略。とりあえず200MBの玉のなかに150MBのs0スライスを作った。</p>
<h4>zpool作成</h4>
<p>上記の玉3本でraidz1を作る</p>
<pre>root@solaris:~# zpool create tank raidz1 c2t1d0s0 c2t2d0s0 c2t5d0s0
root@solaris:~# zpool status tank
  pool: tank
 state: ONLINE
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz1-0    ONLINE       0     0     0
            c2t1d0s0  ONLINE       0     0     0
            c2t2d0s0  ONLINE       0     0     0
            c2t5d0s0  ONLINE       0     0     0

errors: No known data errors
root@solaris:~# zfs list tank
NAME                     USED  AVAIL  REFER  MOUNTPOINT
tank                     144K   258M  40.0K  /tank
</pre>
<p>特に問題なく作れたようだ。150MB*3でうち1本がパリティなので300MB弱程度あればいいはずなので若干容量が少ないが管理データだろうと思っておく。</p>
<h4>ディスク丸ごと使ったディスクをスライスにreplace</h4>
<p>zfsでは構成しているディスクを入れ替え(replace)が出来る。条件は容量が等しいか大きいか。元々丸ごとディスクで定義してあったものをスライスに持って行ければ自宅NASのリプレイスが簡単になる。早速試す。<br />
下記作業の前にc2t3d0, c2t4d0, c2t6d0のs0はすべて350MBにして作っておいてある。長いので省略。</p>
<pre>root@solaris:~# zpool create tank raidz1 c2t1d0 c2t2d0 c2t5d0
root@solaris:~# zpool status tank
  pool: tank
 state: ONLINE
 scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            c2t1d0  ONLINE       0     0     0
            c2t2d0  ONLINE       0     0     0
            c2t5d0  ONLINE       0     0     0

errors: No known data errors
root@solaris:~# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   120K   352M  40.0K  /tank</pre>
<p>これで200MB*3のraidz1ができる。丸ごとHDDで構成した普通の作り。これをそれぞれc2t[3,4,6]d0s0にreplaceしていく。</p>
<pre>root@solaris:~# zpool replace tank c2t1d0 c2t3d0s0
root@solaris:~# zpool status tank
  pool: tank
 state: ONLINE
 scan: resilvered 55K in 0h0m with 0 errors on Tue Jun 28 18:54:39 2011
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz1-0    ONLINE       0     0     0
            c2t3d0s0  ONLINE       0     0     0
            c2t2d0    ONLINE       0     0     0
            c2t5d0    ONLINE       0     0     0

errors: No known data errors
root@solaris:~# zpool replace tank c2t2d0 c2t4d0s0
root@solaris:~# zpool replace tank c2t5d0 c2t6d0s0
root@solaris:~# zpool status tank
  pool: tank
 state: ONLINE
 scan: resilvered 63K in 0h0m with 0 errors on Tue Jun 28 18:55:01 2011
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz1-0    ONLINE       0     0     0
            c2t3d0s0  ONLINE       0     0     0
            c2t4d0s0  ONLINE       0     0     0
            c2t6d0s0  ONLINE       0     0     0

errors: No known data errors
root@solaris:~# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   138K   351M  40.0K  /tank</pre>
<p>これで入れ替えは出来たが容量が変わらない。zpoolのautoexpand(自動容量拡張)プロパティを一度ONにしてやる必要がある。デフォルトはoffにしておいたほうが勝手に容量が変わらないので不慮の事故を防げるだろう。</p>
<pre>root@solaris:~# zpool set autoexpand=on tank
root@solaris:~# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   158K   658M  40.0K  /tank
root@solaris:~# zpool set autoexpand=off tank
root@solaris:~# zpool status tank
  pool: tank
 state: ONLINE
 scan: resilvered 63K in 0h0m with 0 errors on Tue Jun 28 18:55:01 2011
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz1-0    ONLINE       0     0     0
            c2t3d0s0  ONLINE       0     0     0
            c2t4d0s0  ONLINE       0     0     0
            c2t6d0s0  ONLINE       0     0     0

errors: No known data errors</pre>
<p>これで若干のresilverとともに移行が完了した。</p>
<h4>本番での適用</h4>
<p>この検証結果を適用したい本番サーバは1TBのHDD(WD10EADS)が10本ささっていて、うち8本でraidz2構成になっているサーバだが、この検証で安心してディスクリプレイスが可能になった。<br />
ひとまずリプレイス時には3TBクラスのHDDを購入の上、スライスを3*10^12bytesに切ってreplaceしていくと良さそうだ。Oracleに買収されて今後のzfs開発がどうなるかわからないが、他に代替のないファイルシステムである以上今後も使っていくことになるだろう。今後もzfsが消えないで無償で提供され続けることを期待したい。</p>
]]></content:encoded>
			<wfw:commentRss>http://unos.biz/blog/archives/690/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<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だったようでもう四半期も放置されてしまっている。 [...]]]></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>
	</channel>
</rss>

