ZFSスナップショットの実験

こちらを参考にZFSの実験をしました。


・snapshotテスト領域(share/share/snapshot_test3)を作成

root@julie:~# ls /share/share/snapshot_test3/
Hayate　file01　file02　file03　kuraki

root@julie:~# du -sh /share/share/snapshot_test3/
6.2M　 /share/share/snapshot_test3

・snapshotの取得と保存

root@julie:~# zfs snapshot share/share/snapshot_test3@big

root@julie:~# zfs send share/share/snapshot_test3@big > \
~/snapshot_test3_big

root@julie:~# ls -l ~/snapshot_test*
-rw-r--r-- 1 root root 6543960 Aug 10 08:51 /root/snapshot_test3_big

・ZFSファイルシステム(share/share/snapshot_test3)を破棄

root@julie:~# zfs destroy -r share/share/snapshot_test3

root@julie:~# zfs list
NAME　　　　　　　　　　　　　USED　AVAIL　REFER　MOUNTPOINT
share　　　　　　　　　　　　74.4G　 154G　　21K　/share
share/mail　　　　　　　　　　184M　 154G　 184M　/share/mail
share/share　　　　　　　　　74.2G　 154G　　22K　/share/share
share/share/important　　　　20.2M　 154G　20.2M　/share/share/important
share/share/important@today　  29K　　　-　20.2M　-
share/share/pub　　　　　　　74.2G　 154G　74.2G　/share/share/pub

・新しいファイルシステムにsnapshotを復元

root@julie:~# zfs receive share/share/snapshot_test4 < ~/snapshot_test3_big  

root@julie:~# zfs list
NAME　　　　　　　　　　　　　　　USED　AVAIL　REFER　MOUNTPOINT
share　　　　　　　　　　　　　74.4G　 154G　　21K　/share 
〜略〜
share/share/snapshot_test4　　　6.24M　 154G　6.24M　/share/share/snapshot_test4
share/share/snapshot_test4@big　　　0　　　-　6.24M　-

root@julie:~# ls -l /share/share/snapshot_test4/
total 5
drwx------ 2 xxx staff 10 Aug 10 08:47 Hayate
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file01
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file02
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file03
drwx------ 2 xxx staff 29 Aug 10 08:48 kuraki
root@julie:~# du -sh /share/share/snapshot_test4/
6.2M　 /share/share/snapshot_test4

・ファイルを追加

root@julie:~# ls -l /share/share/snapshot_test4/
total 6
drwx------ 2 xxx staff 10 Aug 10 08:47 Hayate
drwx------ 2 xxx staff 24 Aug 10 11:31 Mai_K
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file01
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file02
-rw-r--r-- 1 root　　 root　 0 Aug 10 08:06 file03
drwx------ 2 xxx staff 29 Aug 10 08:48 kuraki
root@julie:~# du -sh /share/share/snapshot_test4/
9.9M　 /share/share/snapshot_test4

・新しいスナップショットを作成し、古いスナップショットとの増分データを保存
新しいスナップショット(share/share/snapshot_test4@big2)を作成し、share/share/snapshot_test4@bigとの増分データ(差分)を保存する。
比較のため、スナップショットのコピーも保存する。

root@julie:~# zfs list
NAME　　　　　　　　　　　　　　　USED　AVAIL　REFER　MOUNTPOINT
share　　　　　　　　　　　　　　74.4G　 154G　　21K　/share
〜略〜
share/share/snapshot_test4　　　9.91M　 154G　9.88M　/share/share/snapshot_test4
share/share/snapshot_test4@big　　26K　　　-　6.24M　-

root@julie:~# zfs snapshot share/share/snapshot_test4@big2

root@julie:~# zfs list
NAME　　　　　　　　　　　　　　　 USED　AVAIL　REFER　MOUNTPOINT
share　　　　　　　　　　　　　　 74.4G　 154G　　21K　/share

〜略〜

share/share/snapshot_test4　　　 9.91M　 154G　9.88M　/share/share/snapshot_test4
share/share/snapshot_test4@big　　 26K　　　-　6.24M　-
share/share/snapshot_test4@big2　　　0　　　-　9.88M　-

root@julie:~# zfs send -i share/share/snapshot_test4@big \
share/share/snapshot_test4@big2 > ~/snapshot_test4_big-big2

root@julie:~# zfs send share/share/snapshot_test4@big2 > \
~/snapshot_test4_big2

・作成したスナップショットのサイズを比較

root@julie:~# ls -l ~/snapshot_test*
-rw-r--r-- 1 root root　6543960 Aug 10 08:51 /root/snapshot_test3_big
　(share/share/snapshot_test4@bigの元となったスナップショット)

-rw-r--r-- 1 root root　3867496 Aug 10 11:38 /root/snapshot_test4_big-big2
　(share/share/snapshot_test4@bigとshare/share/snapshot_test4@big2の増分データ)

-rw-r--r-- 1 root root 10364864 Aug 10 11:47 /root/snapshot_test4_big2
　(share/share/snapshot_test4@big2のスナップショット)

FUSE + GMailFS

GMailFSというのにちょっと興味があったのでインストールしてみました。

GMailFSはFUSE(Filesystem in Userspace)というのを利用しています。
FUSEについて分かりやすく解説しているページがありました。


・必要なパッケージの作成
今回も自分でRPMパッケージを作成しました。

GMailFSのサイトのインストール方法が書かれているページ(Installing Gmail Filesystem)には必要なファイルの置き場所へのリンクがあるので、それをたどって次のソースファイルを取得し、この順番RPMパッケージを作ってインストールしました。
fuse-2.7.0.tar.gz
fuse-python-0.2.tar.gz
libgmail-0.1.6.tar.gz
gmailfs-0.8.0.tar.gz


今回悩んだのが、fuse-python-0.2.tar.gzとlibgmail-0.1.6.tar.gzのRPMパッケージ作成時の仮想ルートディレクトリ(/var/tmp/xxxxx-root)へのインストール方法です。

SPECファイルに次のように記述したところ、仮想ルートディレクトリにインストール出来ました。

%install
python setup.py install --prefix=${RPM_BUILD_ROOT}/usr

makeを使ってインストールする場合は

make DESTDIR=${RPM_BUILD_ROOT} install

や

make PREFIX=${RPM_BUILD_ROOT}/usr install

などでインストールするものが多いと思うのですが、今回のケースではそれが使えません。
setup.pyはテキストファイルなのでその中身を調べたり、試しにDESTDIR=$PWD/workとかを仮想ルートディレクトリに見立ててインストール出来るか確認してみたりと、色々やってみては失敗してしまいました。

ちゃんとドキュメントを読めば方法が書いてあったのかも知れませんけど。


・使用方法
こちらなどを参考に、/etc/fstabに下記のように記述しました。
ユーザ名とパスワードを/etc/fstabに記述したくなかったのでしていません。
正しいのかは分かりませんが、動いてはいます。

/usr/bin/gmailfs.py  /mnt/gmail  gmailfs noauto,fsname=zOlRRa 0 0

じゃあ、ユーザ名とパスワードをどちらで設定するかというと、私はrootのホームディレクトリにある.gmailfsというファイルで行っています。
.gmailfsの中身は下記の通りです。

[connection]
# The proxy URL
#proxy = http://user:pass@proxyhost:port
# or just
#proxy = http://proxyhost:port

# The number or retries for the proxy connection.
#retries = 3

[account]
username = GMailユーザ名
password = GMailパスワード

[filesystem]
fsname = linux_fs_3

[references]
# reference = filesystem:username:password

[logs]
# Change this to DEBUG for verbose output (useful for debugging)
level = INFO

# if you'd like logs to go to stdout, comment out this variable.
# For logging to, say, stderr, use /dev/stderr of your system's
# equivalent for it
logfile = ~/gmailfs.log

これはgmailfs-0.8.0.tar.gzに含まれるgmail.confをユーザ名とパスワードのみをいじったものです。
同じ書式のファイルが/etc/gmailfs.confとして/etc以下にデフォルトのまま置いてありますが、rootのホームディレクトリの.gmailfsの方の修正が有効になっているようです。

gmailfs.confのログを見るとエラーになっている部分があります。
行頭に時間が入っているのですが、下記のログからは外しております。

ERROR      OpenSSLProxy is missing. Can't use HTTPS proxy!
INFO       Starting gmailfs in child process (PID 19203)
INFO       waiting for /mnt/gmail to become a mountpoint
INFO       Mountpoint: /mnt/gmail
INFO       Named mount options: {'password': '********', 'fsname': 'zOlRRa'}
WARNING    mount: warning, should mount with username=gmailuser option, using default
WARNING    mount: warning, should mount with password=gmailpass option, using default

まあ、使えているのでいいかなと。


・使用感
設定が悪いのかもしれませんが、結構遅いです。
今のところ使い道が思い浮かびません。


WindowsからGMail領域を読み込ませるのもあるみたいなので、後で使ってみることにします。

ZFSでハードディスクをフルに使えるようにする

2007/12/22 認識しなくなってしまったので削除
VMwareにインストールしたNexenta(OpenSolaris)で250GBのハードディスクを何故か半分くらいしか認識していなかったのですが、とりあえずなんとか250GB認識するようにはなりました。

かなり怪しいですけど。


問題が発生しているのは250GBのハードディスクではなく、Windows NTFSで使用している150GBくらいのハードディスクをVMwareのNexentaで認識させたときも同じで、どちらも137.44GBしか認識しておりませんでした。
137.44GBをキーワードに検索すると、似たような現象が見つかります。


調べながら色々やってみました。
250GBのハードディスクを使えるようにすることが出来たのは、多分下記の手順が効いているのだと思います。
もしかしたら下記の手段が本当に効果あった訳では無いのかもしれません。

忘れないように一応書いておきますが、
下記の手順が本当に正しいのかどうか分かりませんし、今後重大な問題が発生するかもしれません。

真似しないでください。

○ ディスクのラベルを削除
こちらを参考にディスクのラベルを削除しました。

root@julie:~# dd if=/dev/zero of=/dev/rdsk/c1d1 bs=1b count=16

○ format コマンドでスライスを作成
formatコマンド中でcylinder数(30282)の指定を行います。
多分cylinder数の指定がキモだと思います。

cylinder数が30282というのは、このハードディスクをLinux(Debian 4.0)につなげてfdiskを実行した際に表示される内容から判断しました。

以下のログで行っている作業は、認識している領域全て(137.44GBくらい)のパーティションをfdiskで作成してから行いました。
確かpartition(pa)サブコマンド時に"fdiskを最初に実行しろ"というようなエラーが出たと記憶しています。
以下の作業の途中でfdiskを行っても良かったのかもしれませんが、それだとcylinder数(30282)の指定の後でfdiskを行うことになるため、気が進まなかったので以下のログの作業の前に行いました。

気が進まなかった理由は、"なんとなく"です。

root@julie:~# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
0. c0d0 
/pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
1. c0d1 
/pci@0,0/pci-ide@7,1/ide@0/cmdk@1,0
2. c1d1 
/pci@0,0/pci-ide@7,1/ide@1/cmdk@1,0
Specify disk (enter its number): 2



AVAILABLE DRIVE TYPES:
0. DEFAULT
1. other
Specify disk type (enter its number): 1
Enter number of data cylinders: 30282
Enter number of alternate cylinders[2]:
Enter number of physical cylinders[30284]:
Enter number of heads: 256
Enter number of data sectors/track: 63
Enter rpm of drive[3600]: 7200
Enter format time[default]:
Enter cylinder skew[default]:
Enter track skew[default]:
Enter tracks per zone[default]:
Enter alternate tracks[default]:
Enter alternate sectors[default]:
Enter cache control[default]:
Enter prefetch threshold[default]:
Enter minimum prefetch[default]:
Enter maximum prefetch[default]:
Enter disk type name (remember quotes): 250GB
selecting c1d1
No current partition list
No defect list found
[disk formatted, no defect list found]


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
show       - translate a disk address
label      - write label to the disk
analyze    - surface analysis
defect     - defect list management
backup     - search for backup labels
verify     - read and display labels
save       - save new disk/partition definitions
volname    - set 8-character volume name
!     - execute , then return
quit
format> type


AVAILABLE DRIVE TYPES:
0. DEFAULT
1. 250GB
2. other
Specify disk type (enter its number)[1]:
selecting c1d1
Controller working list found
[disk formatted, defect list found]
format> pa


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
  7      - change `7' partition
  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
  ! - execute , then return
  quit
partition> p
Current partition table (original):
Total disk cylinders available: 16640 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
0       root    wm       3 -    19      133.88MB    (17/0/0)       274176
1       swap    wu      20 -    36      133.88MB    (17/0/0)       274176
2     backup    wu       0 - 30283      232.90GB    (30284/0/0) 488420352
3 unassigned    wm       0                0         (0/0/0)             0
4 unassigned    wm       0                0         (0/0/0)             0
5 unassigned    wm       0                0         (0/0/0)             0
6        usr    wm      37 - 30281      232.60GB    (30245/0/0) 487791360
7 unassigned    wm       0                0         (0/0/0)             0
8       boot    wu       0 -     0        7.88MB    (1/0/0)         16128
9 alternates    wm       1 -     2       15.75MB    (2/0/0)         32256

format> label
Ready to label disk, continue? yes

スライス6に232.60GB割り当てられたようなので、zpoolではディスク全体ではなくスライス6をZFS領域に割り当てます。

root@julie:~# zpool create -f share c1d1s6

上記の手順を踏み、さらにzfsコマンドで追加した状態でdfコマンドを実行した結果は下記のようになりました。

root@julie:~# df -h
Filesystem             size   used  avail capacity  Mounted on

〜 省略 〜

share                  228G    21K   228G     1%    /share
share/mail             228G   186M   228G     1%    /share/mail
share/share            228G    21K   228G     1%    /share/share
share/share/important
                 228G    18K   228G     1%    /share/share/important
share/share/pub        228G   287M   228G     1%    /share/share/pub

iostatコマンドでは相変わらず137.44GBしか認識されていません。
かなり危険な香りがします。

root@julie:~# iostat -En
c0d0             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VMware Virtual  Revision:  Serial No: 000000000000000 Size: 10.74GB <10737377280>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c0d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VMware Virtual  Revision:  Serial No: 010000000000000 Size: 137.44GB <137437655040>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c1d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VMware Virtual  Revision:  Serial No: 110000000000000 Size: 137.44GB <137437655040>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c1t0d0           Soft Errors: 2 Hard Errors: 23 Transport Errors: 0
Vendor: Generic  Product: DVD-ROM          Revision: 1.0  Serial No:
Size: 0.00GB <0>
Media Error: 0 Device Not Ready: 23 No Device: 0 Recoverable: 0
Illegal Request: 2 Predictive Failure Analysis: 0

Nexentaをファイル/IMAPサーバにする

OpenSolarisカーネルのNexentaOS Alpha 7をファイル(Samba・NFS)/IMAPサーバにすることにします。

つい先日Debian/GNU Linux 4.0に移行したばかりですが、Linux以外のも使っていた方が視野が広がるかな、と。
言い訳ですけど。

あいかわらずよく分からずにやっていますので、信用しないでください。


○ NFSの設定
/share/shareをNFS共有にします(参考)。
/share/shareはzfsコマンドで作成したZFSファイルシステムです。

zfsコマンドを使用して次のコマンドを叩いただけです。
/share/shareを共有ディレクトリにします。

root@julie:~# zfs set sharenfs=rw share/share

○ Sambaの設定
NexentaOS Alpha 7に用意されている3.0.24を使用することにしました。

$ dpkg -l|grep samba
ii  samba   3.0.24-2nexenta2   a LanManager-like file and printer server fo
ii  samba-common   3.0.24-2nexenta2   Samba common files used by both the server a
ii  samba-doc   3.0.24-2nexenta2   Samba documentation

smb.confはDebian/GNU Linux 4.0のsmb.confをほぼそのまま使おうと思ったのですが、なぜかSambaがコアダンプしてしまいます。

コアダンプの件は後で調べるとして、取り急ぎNexentaに入っていたsmb.confを基に必要なところだけ修正して使用することにしました。
使用していないプリンタの設定が残っていたりしますので、後で見直します。

[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
  workgroup = Windowsグループ名

# server string is the equivalent of the NT Description field
  server string = %h server (CIFS, Nexenta)

  unix charset = UTF-8
  dos charset = CP932

# This will prevent nmbd to search for NetBIOS names through DNS.
  dns proxy = no

#### Debugging/Accounting ####
# This tells Samba to use a separate log file for each machine
# that connects
  log file = /var/log/samba/log.%m

# Put a capping on the size of the log files (in Kb).
  max log size = 1000

# We want Samba to log a minimum amount of information to syslog. Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead. If you want to log
# through syslog you should set the following parameter to something higher.
  syslog = 0

# Do something sensible when Samba crashes: mail the admin a backtrace
  panic action = /usr/share/samba/panic-action %d


####### Authentication #######

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
;   security = user

# You may wish to use password encryption.  See the section on
# 'encrypt passwords' in the smb.conf(5) manpage before enabling.
  encrypt passwords = true

# If you are using encrypted passwords, Samba will need to know what
# password database type you are using. 
  passdb backend = tdbsam

  obey pam restrictions = yes

;   guest account = nobody
  invalid users = root

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan < for
# sending the correct chat script for the passwd program in Debian Sarge).
  passwd program = /usr/bin/passwd %u
  passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .


############ Misc ############
# Most people will find that this option gives better performance.
# See smb.conf(5) and /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/speed.html
# for details
# You may want to add the following on a Linux system:
#         SO_RCVBUF=8192 SO_SNDBUF=8192
  socket options = TCP_NODELAY

#======================= Share Definitions =======================
[printers]
  comment = All Printers
  browseable = no
  path = /var/spool/samba
  printable = yes
  public = no
  writable = no
  create mode = 0700

# Windows clients look for this share name as a source of downloadable
# printer drivers
[print$]
  comment = Printer Drivers
  path = /var/lib/samba/printers
  browseable = yes
  read only = yes
  guest ok = no

[share]
  comment = Julie share
  path = /share/share
  browseable = no

# By default, the home directories are exported read-only. Change next
# parameter to 'yes' if you want to be able to write to them.
;   writable = no
  writable = yes

一番のキモは

   unix charset = UTF-8
  dos charset = CP932

でしょうか(参考記事)。


○ IMAPの設定
Nexentaにはcyrus-imapd-2.2というのがあり、使おうとして設定までしたのですが、今まで使っていたuw-imapdの方が私には分かりやすかったためこちらを使うことにしました。

ftp://ftp.cac.washington.edu/imap/からimap-2006j2.tar.Zをもらってきて展開しmakeしました。

make時にOpenSSL関係と思われるエラーが出てmakeに失敗しました。

$ make gso

〜 省略 〜

In file included from tcp_unix.c:29,
                from osdep.c:63:
ip_unix.c: In function 'ip_nametoaddr':
ip_unix.c:165: warning: pointer targets in passing argument 1 of 'lcase' differ in signedness
ip_unix.c:165: warning: pointer targets in passing argument 1 of 'gethostbyname' differ in signedness
osdep.c:246:20: error: x509v3.h: No such file or directory
osdep.c:247:17: error: ssl.h: No such file or directory
osdep.c:248:17: error: err.h: No such file or directory
osdep.c:249:17: error: pem.h: No such file or directory
osdep.c:250:20: error: buffer.h: No such file or directory
osdep.c:251:17: error: bio.h: No such file or directory
osdep.c:252:20: error: crypto.h: No such file or directory
osdep.c:253:18: error: rand.h: No such file or directory

〜 省略 〜

sslstdio.c:163: error: request for member 'sslstream' in something not a structure or union
sslstdio.c:163: error: request for member 'obuf' in something not a structure or union
sslstdio.c:164: error: request for member 'octr' in something not a structure or union
sslstdio.c:166: error: request for member 'optr' in something not a structure or union
sslstdio.c:166: error: request for member 'obuf' in something not a structure or union
sslstdio.c:167: error: request for member 'octr' in something not a structure or union
make[3]: *** [osdep.o] Error 1
make[3]: Leaving directory `/export/home/xxx/Source/imap-2006j/c-client'
make[2]: *** [gso] Error 2
make[2]: Leaving directory `/export/home/xxx/Source/imap-2006j/c-client'
make[1]: *** [OSTYPE] Error 2
make[1]: Leaving directory `/export/home/xxx/Source/imap-2006j'
make: *** [gso] Error 2

OpenSSL関連のパスが正しくないようです。
Makefileでパスを指定している箇所はすぐ見付かりました。そもそも"gso"の指定が間違っているのかもしれません。

対処方法としてはSSLTYPE=noneを指定することにしました。
SSLは今のところ使う予定が無いためです。

$ make gso SSLTYPE=none

uw-imapdのインストールは、make後に出来たimapdを/usr/local/sbinの下にコピーしただけです。

c-client.cf, cram-md5.pwdの作成し/etc/inetd.confに記述を追加しました。

# cat /etc/c-client.cf
I accept the risk for IMAP toolkit 4.1.
set new-folder-format mbx
set mail-subdirectory Mail
set disable-plaintext 0

# cat /etc/cram-md5.pwd
ユーザ名        パスワード

# cat /etc/inetd.conf |grep imap
imap   stream  tcp     nowait  root    /usr/sbin/tcpd   /usr/local/sbin/imapd

そして、inetdを再起動しました。

# pkill -HUP inetd

ZFSを使いたい

ZFSが使いたくてNexentaOS Alpha 7をVMwareにインストールしてみました。

$ uname -a
SunOS julie 5.11 NexentaOS_20070402 i86pc i386 i86pc Solaris

NexentaOSはDebianベースのシステムで、OpenSolarisのカーネルとGNUのツールを使用しているらしいです。

ZFSで何がしたいという訳ではないのですが、ちょっと興味があったので使ってみることにしました。

そういえば昔、JFSやXFSのLinux kernel 2.2用のパッチが出た時も使ってみたなぁ。
本当に使ってみただけでしたが。


今回やったのは、

・ZFSストレージプールの作成
・ZFS ファイルシステムの作成

と、あとはZFSファイルシステムを作った後で諸々の事情でNexentaOSを再インストールしたので、

・既存のZFSファイルシステムのインポート

をしてみました。


○ 初めてZFS領域作成

root@julie:~# zpool create share c0d1
root@julie:~# df -h
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c0d0s0        1.9G   1.6G   236M    88%    /
/devices                 0K     0K     0K     0%    /devices
/dev                     0K     0K     0K     0%    /dev
ctfs                     0K     0K     0K     0%    /system/contract
proc                     0K     0K     0K     0%    /proc
mnttab                   0K     0K     0K     0%    /etc/mnttab
swap                   694M   584K   694M     1%    /etc/svc/volatile
objfs                    0K     0K     0K     0%    /system/object
/usr/lib/libc/libc_hwcap1.so.1
                     1.9G   1.6G   236M    88%    /lib/libc.so.1
fd                       0K     0K     0K     0%    /dev/fd
/dev/dsk/c0d0s3        958M    75M   825M     9%    /var
swap                   694M     0K   694M     0%    /tmp
swap                   694M   160K   694M     1%    /var/run
/dev/dsk/c0d0s4        4.5G   4.6M   4.4G     1%    /opt
home                   2.0G   1.2M   2.0G     1%    /export/home
share                  125G    18K   125G     1%    /share

"zpool create"の実行だけで
・ストレージプールの作成
・プールと同じ名前のファイルシステムとマウントポイントを作成
・マウント
を自動で行うようです。
便利なような怖いような。

c0d1というのはVMwareの仮想ディスクではなく本物のハードディスクです。
shareはそのハードディスク全体にして、その下にユーザーのホームディレクトリやSamba/NFS共有ディレクトリを作ろうかと考えました。

で、Samba共有用のディレクトリshare/shareを作成しました。

root@julie:~# zfs create  share/share

share/shareをNFS共有ディレクトリにします。

root@julie:~# zfs set sharenfs=rw share/share

これだけで、NFSクライアントからshare/shareを共有でき、さらにNexenta再起動後も有効になってました。


○ 既存のZFS領域をインポート
上記の手順で一度ZFS領域を作成したのですが、ここでNexentaを再インストールしました。
諸々の事情です。

zpool importを使ってできたのですが、"-f"をつけないといけないみたいです。

root@julie:~# zpool import share
cannot import 'share': pool may be in use from other system
use '-f' to import anyway
root@julie:~# zpool import -f share

----
NexentaOS Alpha 7を使っての問題点
ひとつ大きな問題が発生しています。

ディスク「c0d1」は250GBくらいあるハードディスクなのですが、半分しか認識していません。

       Total disk size is 16709 cylinders
     Cylinder size is 16065 (512 byte) blocks

                                             Cylinders
Partition   Status    Type          Start   End   Length    %
=========   ======    ============  =====   ===   ======   ===
  1                 Linux native      0  30400    30401    100

ちなみに同じハードディスクをVMwareのDebianで認識させたところ全領域認識できたみたいです。
なお、最初は/dev/hdb2がありませんでした。
Debianで/dev/hdb2を作成し、typeに"ee"を指定しました。

Disk /dev/hdb: 250.0 GB, 250056737280 bytes
256 heads, 63 sectors/track, 30282 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes

 Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1       16644   134216459+  ee  EFI GPT
/dev/hdb2           16644       30282   109977588   ee  EFI GPT

上記のようにDebianで/dev/hdb2を作成した後Nexentaで参照すると、次のようになっていました。

       Total disk size is 16709 cylinders
     Cylinder size is 16065 (512 byte) blocks

                                             Cylinders
Partition   Status    Type          Start   End   Length    %
=========   ======    ============  =====   ===   ======   ===
  1                 EFI               0  16709    16710    100
  2                 EFI            16709  30400    13692     82

100% + 82%で182%ですか？
限界を越えたスーパーサイヤ人みたいです。

(2007/8/8 追記)
かなり怪しい感じですが、一応250GB位認識されるようになりました。
「ZFSでハードディスクをフルに使えるようにする」

ZaurusをSambaクライアントに

「ZaurusをNFSクライアントに」ではZaurus(SL-C3000)をNFSクライアントにしましたが問題がありました。

問題１
ファイル名の日本語が表示出来ていません。

以前Sambaサーバ上のファイル名はShift-JISにしました。
NFSサーバとして使用している場合にはEUC-JPになっているはずです。多分。

ZaurusではSambaとNFSの両方で日本語表示できないということは、ZaurusはShift-JISでもEUC-JPでもないということでしょうか？
もしかしてUTF-8？

問題２
1Gくらいあるフォルダを"cp -ar"でNFS領域にコピーしたのですが、途中でcpがデッドロックとやらになってしまい止まってしまいました。

ログ(syslog)とか見てみたのですが、参考になるようなログはみつかりませんでした。
この場合どのログをみればよかったのでしょうか？
デッドロックの問題は原因がつかめていません。
まだ設定が不足している箇所も多数あると思いますが・・・。


上記のような問題が発生しているのを避けるため、NFSではなくSambaを使用してJULIE(NFSサーバ兼Sambaサーバ)にアクセスしてみるのはどうかと考えました。
本来であればNFSの設定を見直すべきかもしれませんが。

NFSの文字コード指定ってあるのか分かりませんが、Sambaならあるのは以前確認済みですし、日本語表示もなんとかなるのではないかとほのかな期待を抱いてやってみることにします。

(1) Zaurus用smbmountを取得
こちらからsmbmount_0.1_arm.ipkを取得し、インストールしました。
(後ほど述べますが、ここでインストールしたsmbmount_0.1_arm.ipkはその後アンインストールしました)

(2) JULIE(Sambaサーバ)の領域をマウント

#sudo smbmount //julie/share /mnt/julie/
    -o username=xxx,ip=xxx.xxx.xxx.xxx

としてマウントしました。


(1)～(2)までで、とりあえずZaurusをSambaクライアントとして使用できるようになりました。
NFSを使用したときよりSambaを使っている方が動作が軽快な気がします。
(もちろんNFS設定をチューニングすればいいのかもしれません)

ところが、Zaurusのファイルマネージャではやはりファイル名の日本語表示が出来ていませんでした。

smbmountのオプションとしてcodepageとiocharsetがありますが、(1)でインストールしたsmbmount_0.1_arm.ipkでは対応していませんでした。

探してみたところcodepageとiocharsetのオプションに対応したsmbmountを配布されているサイトがありました。
こちらからsmbmount_2.2.8a-ja-1.0_arm.ipkをいただいてきてインストールし、次のようなコマンド引数でマウントしました。

sudo smbmount //julie/share /mnt/julie/
    -o fmask=666,username=xxx,ip=xxx.xxx.xxx.xxx,
       codepage=cp932,iocharset=utf8

結果、Sambaサーバ上の日本語ファイル名のファイルを、Zaurusのファイルマネージャで日本語表示出来るようになりました。



ちなみに、smbmountのオプションとして渡したiocharsetとcodepageは、Sambaのマニュアルには次のようにあります。

iocharset=<arg>
Linux 側のコードページ-文字コード変換 (NLS) で使用される文字コードを設定する。引数は iso8859-1 のようなキャラクタセットの名前でなくてはいけない。 (注: カーネル 2.4.0 以降のみサポートされる)


codepage=<arg>
サーバ側で使用される文字コードを指定する。 iocharset オプションを参照。例えば cp850 などである。 (注: カーネル 2.4.0 以降のみサポートされる)

私が行った設定の場合、iocharsetの説明中のLinuxとはZaurusを指し、codepageのサーバとはSambaサーバであるJULIE(Plamo Linux)を指します。

また、CP932はマイクロソフトのShift-JIS拡張らしいです。

ZaurusをNFSクライアントに

そういえばZaurusでNFSファイルシステムって使えるのかなと疑問に思い、確認してみた。

まずZaurus(SL-C3000)でNFSファイルシステムをサポートしているか確認する。
ちなみにスペシャルカーネルになっています。

[root@zaurus: zaurus]# cat /proc/filesystems
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   tmpfs
nodev   shm
nodev   pipefs
        ext3
        ext2
        cramfs
nodev   ramfs
        minix
        vfat
        iso9660
nodev   nfs
nodev   smbfs
        ntfs
        jffs2
nodev   devpts

サポートしているみたい。

ところでJFSもサポートしているんだ。
使ってみようかな。


Zaurusの/etc/fstabに次の2行を追加。

xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  nfs  \ 実際は一行
     users,noauto,rw,hard,intr,nosuid  0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx  /mnt/elie  nfs  \ 実際は一行
     users,noauto,ro,hard,intr,nosuid  0 0

追加したのはVine Linux 4.1とまったく同じ内容。


マウントポイントとするディレクトリを作成。

[root@zaurus: zaurus]# mkdir /mnt/julie
[root@zaurus: zaurus]# mkdir /mnt/elie

そして、マウント。

[root@zaurus: zaurus]# mount /mnt/julie
unknown nfs mount option: users
mount: nfsmount failed: Success
mount: Mounting xxx.xxx.xxx.xxx:/mnt/share/xxx
   on /mnt/julie failed: Invalid argument

ものの見事に失敗。

usersオプションが無いということなので、/etc/fstabの記述をusersを取り除いたものに変更。

xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  \ 実際は一行 
     nfs  noauto,rw,hard,intr,nosuid  0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx  /mnt/elie  \ 実際は一行 
     nfs  noauto,ro,hard,intr,nosuid  0 0

で、マウント。

[root@zaurus: zaurus]# mount /mnt/julie
[root@zaurus: zaurus]#

今度は成功。


使ってみた感想ですが、SL-C3000標準のファイルマネージャーでNFS領域に入って移動していると、すぐにフリーズしてしまう気が・・・。
設定が悪いのかな。

NFS領域の日本語フォルダ名が含まれる箇所で落ちてしまうのです。
もちろん日本語フォルダはたまたまかも知れません。
まだ検証できていません。

PCからtelnetでZaurusにログインした場合は、問題なく日本語読めているのですけど。

[zaurus@zaurus: WallPaper2]$ ls
008-m.jpg  kekkonn_dekinai_otoko  nestle             soranokiseki
Zaurus     koushien                satomihakkenndenn  ファルコム

もともとNFS領域をファイルマネージャーで参照する気はなかったですし、telnet接続してコマンドラインでの作業は問題なく出来ているので、とりあえずはいいのですけど。

後でもうちょっと検証してみます。

NFSについて調べる(セキュリティ)

「NFSについて調べる(クライアント側)」の続きです。

サーバ側
・NFSは賢くない
JFの文書には次のようにあります。

再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。 ボブはサーバでユーザのみがアクセスできるファイル を作ります (chmod 600 filename と入力するのと同じです)。 そのファイルが保存されたドライブへのアクセスを、 あるクライアントが許可されました。 そのクライアントでは、ユーザ ID 9999 には mary がマップされています。 この場合、bob が自分にしかアクセスできないようにしたファイルに対して、 そのクライアントでのユーザ mary がアクセスできてしまいます。 さらに悪いことに、そのクライアントで誰かがスーパーユーザになってしまうと、 その誰かは su - username によって どんな ユーザにもなれてしまうのです。 NFS は賢いとは言えません。

・クライアントのrootは信用するな
root_squashオプションを使う。

これはデフォルトで有効であり、うちのNFSサーバ(JULIE)でも有効になっている。

julie:~# exportfs -v
/mnt/share3/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(ro,wdelay,root_squash)
/mnt/share/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(rw,wdelay,root_squash)

JFの記述から。

root_squash の状態では、クライアントで UID 0 (root のユーザ番号) のユーザがファイルにアクセス (read, write, delete) しようとすると、 サーバは UID をサーバにおける 'nobody' アカウントのものと置き換えます。 つまりサーバの root だけにアクセスや変更が許されているファイルに対して、 クライアントの root がアクセスや変更を行うことができなくなるのです。

実験。
クライアントの操作。
カレントディレクトリはNFSファイルシステム上。

$ su
パスワード(P):
# touch aaa
# ls -l aaa
-rw-r--r-- 1 65534 65534 0  7月19日 01:27 aaa

サーバで確認。

# ls -l aaa
-rw-r--r--  1 nobody nogroup 0 Jul 19 01:27 aaa
# id nobody
uid=65534(nobody) gid=100(users) groups=100(users)
# cat /etc/group|grep nogroup
nogroup::65534:

重要なバイナリやファイルの所有者はbinなどではなくrootにすることが重要らしい。
root以外にすると、クライアント側のrootがサーバ側のバイナリやファイルの所有者idのユーザになって書き換えることが出来るから。


クライアント側
・suidプログラムを動作させない
nosuidオプションを使う。

JFの文書には次のようにある。

こうするとサーバの root ユーザが件のファイルシステムに suid-root プログラムを作り、クライアントに一般ユーザとしてログインし、 その suid-root プログラムを使ってクライアントでも root になる、 ということができなくなります。 さらに noexec オプションをつければ、 マウントしたファイルシステムでのファイルの実行を禁止することもできます。

noexecオプションを使えば、マウントしたファイルシステムのファイルを実行することができなくなるらしい。

NFSについて調べる(クライアント側)

「NFSについて調べる(サーバ側)」の続きです。

クライアント側のことを調べます。

・サポートしているファイルシステムを調べる
/proc/filesystemを見ればいいみたいです。

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   binfmt_misc
nodev   sockfs
nodev   usbfs
nodev   pipefs
nodev   futexfs
nodev   tmpfs
nodev   inotifyfs
nodev   eventpollfs
nodev   devpts
        reiserfs
        ext3
        ext2
        cramfs
        squashfs
nodev   ramfs
nodev   hugetlbfs
        iso9660
nodev   mqueue
        vfat
nodev   autofs
nodev   rpc_pipefs
nodev   nfs
nodev   nfs4

NFSクライアント(SALIE)ではNFSをサポートしてようです。

ちょっと気になっていたのですが、Vine Linux 4.1のデフォルトカーネルは、/proc/filesystemを見る限りではJFSやXFSをサポートしていないように思えます。
多分。


NFSクライアント側の/etc/fstabにはNFSマウントように次の行を追加しています。

xxx.xxx.xxx.xxx:/mnt/share/xxx /mnt/julie
    nfs     users,noauto,rw,hard,intr  0 0 (実際は一行)

使用しているマウントオプション(hard)は、JFには次のようにありました。

hard

NFS マウントされたファイルシステム上のファイルにアクセスしている プログラムは、サーバがクラッシュすると宙ぶらりんになります。 これらのプロセスは intr を一緒に指定していない場合は、中断することも kill することもできなくなります ("sure kill" を使えば別)。 NFS サーバが復活すると、プログラムはそれぞれ何もなかったかのように再開します。 おそらくこちらが望ましい場合が多いでしょう。全ての NFS マウントには、hard,intr を用いることをお勧めします。

intrはNFSのマニュアルに次のようにありました。

intr

NFS へのファイル操作がメジャータイムアウトとなり、かつその NFS 接続が hard マウントされている場合、シグナルによるファイル操作の中断を許可 し、中断された場合には呼び出したプログラムに対して EINTR を返す。
デフォルトではファイル操作の中断を許さない。

「NFSについて調べる(セキュリティ)」に続く。

NFSについて調べる(サーバ側)

JFの「Linux NFS-HOWTO」を読んで、NFSについて調べてみたことのメモ。

まずはサーバ側のこと。

・NFS が動作しているか確認する

julie:~# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    729  mountd
    100005    1   tcp    732  mountd
    100005    2   udp    729  mountd
    100005    2   tcp    732  mountd
    100005    3   udp    729  mountd
    100005    3   tcp    732  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   udp   1026  nlockmgr
    100021    3   udp   1026  nlockmgr
    100021    4   udp   1026  nlockmgr
    100021    1   tcp   1079  nlockmgr
    100021    3   tcp   1079  nlockmgr
    100021    4   tcp   1079  nlockmgr
    900101    1   udp    834
    900101    2   udp    834
    900101    1   tcp    837
    900101    2   tcp    837

また、rpcinfoコマンドと引数"-p"はマニュアルには次のようにあります。

rpcinfo は、 RPC サーバに対して RPC 呼び出しを行い、得られた情報を表示する。

-p
host の portmapper を検出し、そこに登録されている全ての RPC プログラムの一覧を表示する。 host が指定されていない場合、 hostname(1) で返される値がデフォルトになる。

うちのNFSサーバ(JULIE)ではversion 2〜4のNFSが動いているみたいです。

・/etc/exports をあとから変更する
nfsd に /etc/exports ファイルを読み直させるために"exportfs -ra"コマンドを実行する。

exportfsコマンドのマニュアルには次のようにあります。

exportfs コマンドは、現在 NFS でエクスポートしているファイルシステムのテーブルを管理するために使うコマンドである。このリストは /var/lib/nfs/xtab という名前のファイルに保存される。

また、オプション"r"と"a"は次のようにあります。

-a
全てのディレクトリをエクスポート・アンエクスポートする。

-r
全 てのディレクトリを再エクスポートする。 /var/lib/nfs/xtab を /etc/exportsと同期させる。 /etc/exports から削除されたエントリを /var/lib/nfs/xtab からも削除し、既に無効になったエントリをカーネルのエクスポートテーブルから削除する。

「NFSについて調べる(クライアント側)」に続く。

日本語文字化けをどうにかする その４

「日本語文字化けをどうにかする　その３」の続きです。

前回まででNFSクライアントであるVine Linux 4.1では文字化けを解消できましたが、Windows PCからのアクセスを確認していません。

SambaサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をWindowsで参照する際に文字化けするか確認し、問題があれば対応したいと思います。


「日本語文字化けをどうにかする　その１」で行ったのはNTFSファイルシステムをLinuxでマウントする際のオプションを変更しただけでファイルやフォルダをいじった訳ではないので問題ありません。

気になるのは、「日本語文字化けをどうにかする　その２」で行ったファイル名やフォルダ名をShift-JISからEUC-JPに変更してしまっている点です。

これをSambaでWindowsから参照できるようにした場合に、正常に読むことができるのでしょうか？


確認のため、「日本語文字化けをどうにかする　その２」で行った手順を再度行います。

(1) SALIE(NFSクライアント)からNFSマウントしたReiserFSファイルシステム上のファイル名・フォルダ名が文字化けしているのを確認。
Konquerorで確認します。

(2) convmvコマンドを使用してファイル名・フォルダ名をShift-JISからEUC-JPに変換。

$ convmv -r -f sjis -t euc-jp * --notest
mv "xxx/PDF/gZ"    "xxx/PDF/トラ技"
mv "xxx/Docs/Zaurus/J�txt"        "xxx/Docs/Zaurus/開発環境.txt"
mv "xxx/Pictures/WallPaper/t@R"    "xxx/Pictures/WallPaper/ファルコム"
mv "xxx/Movie/O/コピー ～ multimodal_arm.tar"
mv "ubN}[N/C莅lzh"      "ubN}[N/お気に入り.lzh"
mv "./ubN}[N"   "./ブックマーク"
Ready!

(3) SALIE(NFSクライアント)で文字化けしていないことを確認。
Konquerorで確認します。
化けていたのは「ブックマーク」というフォルダでした。

(4) Windows(Sambaクライアント)で文字化けしているかを確認。
やっぱり化けてました。


文字化けが発生していたため、JULIE(Sambaサーバ)の設定を変更することにより解決できないか検討します。

(5) Sambaの設定を変更。
smb.confの[global]に以下の記述を追加。

coding system = euc
client code page = 932

各設定値の説明はマニュアルにありました
マニュアルのcoding systemの項からの引用です。

coding system (G)

このパラメータは、 Samba が受けとった Shift-JIS の日本語文字を、 クライアントが使っているclient code pageから UNIX ファイルシステムのファイル名にどのように対応づけるかを指定する。 このパラメータは、client code page が932(日本語 Shift-JIS)の時のみ有効である。オプションは以下のとおり:

次にclient code pageの項からの引用です。

client code page (G)

このパラメータは、Samba にアクセスするクライアントが利用している DOS コードページを指定する。 Windows や DOS クライアントで利用されているコードページを確認するには、 DOS コマンドプロンプトを開いて、chcpコマンドを入力する。 これによりコードページが表示される。 USA 版の MS-DOS、Windows 95、Windows NT のデフォルトは 437 である。 西ヨーロッパ版のこれら OS のデフォルト値は 850 である。

(6) Sambaを再起動。
JULIE(Sambaサーバ)のsmbdとnmbdの両方を再起動しました。
両方再起動したのは念のためです。

(7) Windows(Sambaクライアント)で文字化けしているかを確認。

文字化けは解消されています。

(8) Windows(Sambaクライアント)が作成した日本語ファイル名・フォルダ名の確認。
Windows(Sambaクライアント)で作った日本語名のフォルダをJULIE(Sambaサーバ)へコピー。

(9) SALIE(NFSクライアント)でWindowsで作成した日本語名のフォルダを確認。
Konquerorで確認します。

OK!

文字化け対策はとりあえず一通り出来たかなと思います。
何か忘れていることはないかな？

日本語文字化けをどうにかする その３

「日本語文字化けをどうにかする　その２」の続きです。
ReiserFSファイルシステムでの文字化けについてです。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

私が使用しているのはReiserFSですが、ext2やext3でも同じではないでしょうか。
多分。
JFSやXFSはどうかな？


SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。
ひどいありさまです。

行った対策は次の通りです。
・保存されているファイル名・フォルダ名の文字コードがShift-JISであるので、EUC-JPに変更する。
・ファイル名・フォルダ名の変更にはconvmvというツールを使用する。

convmvはSALIE(NFSクライアント)にインストールしました。
Vine Linuxにはconvmvが見つからなかったため、Fedora-JPのサイトからconvmv-1.10-2.fc6.src.rpmをいただいて、それをrpm --rebuildしました。

convmvはNFSサーバとクライアントのどちらにインストールして大丈夫ですが、書き込み権限は必要かと思います。


変換する際のコマンドは次の通りです。

$ convmv -r -f sjis -t euc-jp * --notest
mv "ﾙ@ﾙ@ﾙ~@/ﾙ~@.mdi"    "ﾙ~@/資産設計(2) 戦術編　10 万円ではじめる方法.mdi"
mv "ﾙ~@/ﾙ~@.pdf"        "ﾙ~@/資産設計(2) 戦術編　10 万円ではじめる方法.pdf"

～以下略～

この結果、SALIE(NFSクライアント)のKonquerorで正常に表示できるようになりました。



「日本語文字化けをどうにかする　その４」に続く。

日本語文字化けをどうにかする その２

「日本語文字化けをどうにかする　その１」の続きです。
まずはNTFSの方です。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。

$ echo $LANG
ja_JP.eucJP

NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているNTFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。

行った対策は次の通りです。
・JULIE(NFSサーバ)でNTFSファイルシステムをマウントする際に文字コードを考慮する


文字化けしている際のJULIE(NFSサーバ)側のfstabの記述は次のようになっていました。

・変更前の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  defaults,umask=000  0  0

文字化け対策として、次のように記述しました。
オプションのroは、書き込み禁止を明示的に指定したくてついでに書いておきました。
・変更後の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  umask=000,nls=euc-jp,ro  0  0

mountのマニュアルのntfsの項には次のように書いてあります。

iocharset=name
ファイル名を返すときに用いる文字セット。 VFAT とは異なり、NTFS は変換できない文字を含む名前を抑制する。このオプションは推奨されない。

nls=name
以前は iocharset という名前であったオプションの新しい名前。

mountのマニュアルのvfatのオプションはfatと同様のものが多く、fatの項には次のように書いてありました。

iocharset=value
8ビットの文字を 16 ビットの Unicode 文字に変換する (あるいはその逆)ときに用いる文字セット (character set)。デフォルトはiso8859-1である。長いファイル名は、ディスクには Unicode フォーマットで保存されている。

JULIE(NFSサーバ)のfstabを変更後にSALIEでマウントすると、文字化けはとりあえず解消されたようです。
文字化けしていたのは「ファルコム」というディレクトリでした。


「日本語文字化けをどうにかする その３」に続く

日本語文字化けをどうにかする その１

最近はノートPCにインストールしたVine Linux 4.1でKDEを使っていることが多いです。

その際はWindowsXPマシンも同時に立ち上げ、WindowsXPのVMWareにインストールしてあるPlamo LinuxもWindowsXP起動と同時に立ち上げ、ファイルサーバなどとして使用することもあります。
(うちのネットワーク環境についてはこちら)

起動しているVineとPlamoのホスト名は次のようになっています。
Plamo Linux： JULIE
Vine Linux： SALIE


JULIEではファイル共有用のハードディスクを2台マウントして、NFSやSambaでローカルネットワーク上に開放しています。

ファイルシステムは1台はNTFS, もう1台はReiserFSです。

この2台のハードディスクに入っている日本語の名前がついたファイルやフォルダがSALIEのKDE Konquerorで見ると文字化けしてしまいます。
(ちなみにGNOMEのNautilusでは、Konquerorでは文字化けしているのに文字化けしないものもありました。)

この文字化けを、今さらながらなんとかしたいと思います。


結論から言うと、問題の対策は次の通りに行いました。

・NTFSファイルシステムの文字化け
　→ マウント時にオプション"nls=euc-jp"を指定する
　(「日本語文字化けをどうにかする その２」で検証)

・ReiserFSファイルシステムの文字化け
　→ ファイル名やフォルダ名をShift-JISからEUCに変更する
　(「日本語文字化けをどうにかする　その３」、「日本語文字化けをどうにかする　その４」で検証)



なお、数年前はPCを使用する際はLinuxを使用することが多かったのに、その際はほとんど問題になりませんでした。

その理由はこんな感じでしょうか。
・Linux上で自分が作ったファイルの名前に日本語でつけることは絶対にない。

・Windowsを使っている際も自分なりのファイル命名規則があった。
　それは、日本語ファイル名は使わないということ。
　しかし、しばらくLinuxを使用していない間に日本語ファイル名を使ってしまっていた。

・iTunesで作成した音楽ファイルに日本語名がついていることが多い。
　Linuxを常用している頃はcdparanoia + LAMEでMP3ファイルを作成していた。


NTFSとReiserFSでは行った対策が異なりました。
分けて記述しておきます。


「日本語文字化けをどうにかする　その２」に続く。