CentOSを利用してて、何かのはずみでNFSでmountしたDiskに置かれているファイルのOwnerがnobodyになる問題の解決策

localhost nfsidmap[xxxxx]: nss_getpwnam: name 'foo@localdomain' does not map into domain 'bar.baz'

こんなlogが出た場合、以下が考えられる。

1. NISがおかしい
2. NISなんか使ってないが、resolv.confなどでなんらかの設定をぶち込んだ
3. NISをやめた

今回は、2と3で引っかかった

こういうときには、

1. NIS関連の設定をなくす
2. nfsidmap -v -c を実行し、cacheをクリアする
3. /etc/idmapd.confを修正する

   • vi /etc/idmapd.conf
     ==========
     Domain = localdomain
     ==========

4. mount -o remount /path/to/mountedFS

結構はまった。

試験環境は XenServer 6.2上のFVMのCentOS 7。 vCPU x1, Mem 1024M, HDD 10G(boot)+1G(試験用)

試験内容は

• 試験用の1GのDiskに、下記のscript-1で出来る限りのファイル/Directoryを作成する
  • そのファイルシステムに対し、ls -Rを実行してかかった時間を計測。また、作成できたファイル数を数える
• 試験用の1GのDiskに、下記のscript-2でファイルをDirectoryを作成する。
  • 作成時間、ls -Rにかかる時間、消去時間を計測

今回は、簡易な試験なので、複数回実施するような事はしない

えー、決定的ミスが発見されたため、以下書き直しました。

• 元々の試験では、Kernel内のCacheの効果で、Cacheの性能しか見えなかった

まず、File作成制限を測定する為のScript

script1

#! /bin/sh
for i in `seq 1 33000`; do
  mkdir $i
  for j in `seq 1 33000`; do
    touch $i/$j
  done
done

script2

#!/bin/bash

set_START() {
  START=`cat /proc/uptime | cut -d ' '  -f1`
}
get_ELAPS() {
  END=`cat /proc/uptime | cut -d ' '  -f1`
  ELAPS=`echo "scale=7; $END - $START" | bc`
}
	
make_dir() {
  echo "Gen $m Dirs"
  sync ; echo 3 > /proc/sys/vm/drop_caches
  set_START
  for i in `seq 1 $1`; do
    mkdir $i
  done
  get_ELAPS
  echo "make $1 dirs: $ELAPS sec"
}

touch_file() {
  sync ; echo 3 > /proc/sys/vm/drop_caches
  set_START
  for i in `seq 1 $2`; do
    touch $1/$i
  done
  get_ELAPS
  echo "touch $2 file: $ELAPS sec"
}

access_file() {
  sync ; echo 3 > /proc/sys/vm/drop_caches
  set_START
  ls -R > /dev/null
  get_ELAPS
  echo "access all files: $ELAPS sec"
}

remove_file() {
  sync ; echo 3 > /proc/sys/vm/drop_caches
  set_START
  rm -rf *
  get_ELAPS
  echo "remove all files: $ELAPS sec"
}

mkdir mnt

for k in ext4 xfs btrfs; do
  /sbin/mkfs.$k -F /dev/xvdb
  mount /dev/xvdb mnt
  cd mnt

  echo "Filesystem: $k start"
  for m in 16384 24576 ; do
    make_dir $m
    for n in 1 5 9 13; do
      touch_file $n 8192
    done
    access_file; remove_file

    make_dir $m
    for n in 1 13; do
      touch_file $n 16384
    done
    access_file; remove_file

    make_dir $m
    for n in 1 ; do
      touch_file $n 32768
    done
    access_file; remove_file
  done

  cd ..
  echo "Filesystem: $k end"
  umount mnt
done

今回の試験は、XenServer上のVMで実施したため、以下の隠しパラメータがあります。

• DiskはRemoteにあるFreeNASで供給したiSCSI Diskを使用している
  • つまり、伝送遅延やSCSIコマンド解析等による性能劣化、FreeNASのRAID1構成による性能劣化が（暗黙に）含まれている
• XenServer上では、他のVMも動いているため、CPU時間を占有できた訳ではない
  • が、XenServer自体はすかすかで、負荷も低い為、大きな影響は無かったはず

これを見ると、ファイルが増えた場合、xfsとbtrfsは空き領域を使ってどんどんinodeを作って行く(btrfsに関してはそもそもinodeなのか？という疑問があるが)ように見える。 対して、extfs系は、UNIX系のFSの伝統に従って、inodeの数を決めうちしているように見える。

ext2fs> df
/dev/xvdb                            999320   3904  926604    1% /root/ext4

ext3fs> df
/dev/xvdb                            999320   3904  926604    1% /root/ext4

ext4fs> df
/dev/xvdb                            999320   3904  926604    1% /root/ext4

xfs> df
/dev/xvdb                           1038336 1038192     144  100% /root/xfs

btrfs> df
/dev/xvdb                           1048576 976320    8192  100% /root/btrfs

試験結果を見る限り、大きな有意差はないと考えられる。 但し、System時間とUser時間を取れていないので、書き込みの転送速度がBottle Neckになっている可能性は否定できない。

まぁ、この程度の試験では有為差がでなかったので、CentOSで使うFSとしては「defaultの」xfsでいいんじゃないか？

• CentOSで、古いカーネルを削除したい場合。
  今動いているカーネルと１世代前のカーネルは残ります。（デフォルト設定）

  # package-cleanup --oldkernels

• 現在のkernelと同じバージョンのkernel-develをインストールするには、次のようにする。

  # yum install kernel-devel-`uname -r`