uyota 匠の一手

g_vfs_done():md0[WRITE(offset=130381824, length=2048)]error = 28
g_vfs_done():md0[WRITE(offset=131135488, length=2048)]error = 28

が出ているのをしばしば見かけていた。。md0 から mfs 関連らしいのは察していた。長い間様子を見ていたのだが、mfs tmp がやはり怪しいようだ。

/etc/defaults/rc.conf には

tmpmfs="AUTO"           # Set to YES to always create an mfs /tmp, NO to never
tmpsize="20m"           # Size of mfs /tmp if created
tmpmfs_flags="-S -M"    # Extra mdmfs options for the mfs /tmp

と設定されている。

それを、rc.conf にて以下のように設定していた。

tmpmfs="YES"            # Set to YES to always create an mfs /tmp, NO to never
tmpsize="128m"          # Size of mfs /tmp if created
tmpmfs_flags="-S -M -o async"   # Extra mdmfs options for the mfs /tmp

-o async が実際に役に立っていたかはよく分からない。実メモリは 512MB なので、大き過ぎることはないと思ったが、時折カーネルがパニックを起こしていた。そのほとんどが、/tmp に大きめのアーカイブを展開したときだった。また、パニックにまで陥らなくても、上記のようなエラーが、/var/log/messages に残っていた。

man mdmfs には、

     -M      Create a malloc(9) backed disk (MD_MALLOC) instead of a swap-
             backed disk.

とある。 man mdmconfig を見ると、

     -t type
             Select the type of the memory disk.

             malloc   Storage for this type of memory disk is allocated with
                      malloc(9).  This limits the size to the malloc bucket
                      limit in the kernel.  If the -o reserve option is not
                      set, creating and filling a large malloc-backed memory
                      disk is a very easy way to panic a system.

とある。-o reserve が無いせいではないのだろうか。

元々、MD_MALLOC よりも、MD_SWAP の動作の方が、都合がいい。現在のところは、tmpmfs_flags から -M を除き MD_SWAP にしている。それ以降、/tmp に絡むカーネルパニックは起こらなくなった。