ufsdump/ufsrestore on Blade100
NAKAJI Hiroyuki
/home (==/export/home) が足りなくなってきたので、HDDを増設して、
ufsdump/ufsrestore でコピーしてから mount point を変更したのですが、そ
の際、
DUMP: 25667006 blocks (12532.72MB) on 1 volume at 217KB/sec
というスピードでした。^_^;;
単純計算で、およそ16時間かかったことになりますし、たしかに、夕方の6時
30分頃からはじめたのが終わらないのであきらめて帰ったのが午前4時30分頃、
再度様子を見に行ったのが翌日の正午で、そのときに、このように画面に表示
されていたのでつじつまは合うのですが、大きな疑問がわきました。
Blade100 の IDE って、そんなに遅いものなのか？
ちなみに、ST320011A (/mnt) から ST3120022A (/export/home) へのコピーで
した。今は、
/dev/dsk/c0t2d0s3 115412949 13459023 100799797 12% /export/home
/dev/dsk/c0t0d0s7 13461003 12488334 838059 94% /mnt
という状態で、通常の使用では新しい /export/home の読み書きが取り立てて
遅いという印象はないのですが、いくら ALI チップセットだからとは言え、
ハードディスク間のバックアップでこんなに時間がかかったのが驚きでした。
--
NAKAJI Hiroyuki (中治 弘行)
Kawaguti Ginga
<86oehi3...@xa12.heimat.gr.jp>の記事において
nak...@tutrp.tut.ac.jpさんは書きました。
> 単純計算で、およそ16時間かかったことになりますし、たしかに、夕方の6時
> 30分頃からはじめたのが終わらないのであきらめて帰ったのが午前4時30分頃、
> 再度様子を見に行ったのが翌日の正午で、そのときに、このように画面に表示
> されていたのでつじつまは合うのですが、大きな疑問がわきました。
>
> Blade100 の IDE って、そんなに遅いものなのか？
Blade100 ってこれですね:
http://sunsolve.sun.com/handbook_pub/Systems/SunBlade100/SunBlade100.html
比較にも何にもならないんですが，先日 Sun Fire V100 (安物1U)を
触ったときにもにたような印象を受けました．奴も確か Ali chipset の
システムで HDD は ATA (ただ ATA/100 にするために CMD のカード経由だった)なので
似たような感じかな，と...
http://www.sun.com/servers/entry/v100/
定量的なデータはなにもとっていませんが，FreeBSD/sparc64 5-current を
放り込んで，とある gateway 用途にしようかと思ったらとにかく遅い．
体感で Pentium 100MHz PC 以下じゃないかと...
gateway としても遅すぎな位で一瞬でお役御免になってしまいました．
(当方のは直接に disk I/O の話じゃないですけど．)
その時は FreeBSD/sparc64 のせいだろうと思って
"素直に solaris にしておけば良かったのかなぁ"，と思ったのですが
solaris でもわざわざ fj に投稿したくなるくらい :-) 遅かったんですかね．
Blade100 は disk I/O 以外は普通なんでしょうか?
> ちなみに、ST320011A (/mnt) から ST3120022A (/export/home) へのコピーで
> した。今は、
ちなみにすぎますが，私の方で使っていたのは
(HDD の型番も控えていませんが) 10GB 程度の 5400rpm ATA/66(?) HDD でした．
(部屋の片隅で稼働予定だったので，標準より貧弱な HDD です)
--
∧∧
Zzz.. (- - )⌒⌒⊇～ 川口 銀河
############## ginga-fj-s...@ginganet.org
NAKAJI Hiroyuki
>>>>> ginga-fj-s...@ginganet.org (Kawaguti Ginga) wrote:
> > Blade100 の IDE って、そんなに遅いものなのか？
> Blade100 ってこれですね:
> http://sunsolve.sun.com/handbook_pub/Systems/SunBlade100/SunBlade100.html
217KB/sec は、277KB/sec の間違いでしたが、どっちにしても遅いです。^^;
> Blade100 は disk I/O 以外は普通なんでしょうか?
そうですね。SS5 の Solaris 2.6 の後がまとしては、じゅうぶんな速度で動
きます。コンパイルなどは、少なくとも Ultra 1 より速いですが、disk I/O
だけは、にんともかんとも…。
敢えて言うなら、FreeBSD/pc98 で IDE ディスクを使うときの disk I/O の方
が速いかも。
> solaris でもわざわざ fj に投稿したくなるくらい :-) 遅かったんですか
> ね．
^^;;
いくら 12GB あるといっても、夕方の6時30分からはじめたとしても、その日
のうちには帰れるだろうと思い込んでいたものですから、こんな面白いことを
自分の胸の中にしまっておくのはもったいないと思いました。
今、「ちゃんと Cable Select にしてあったっけ？」という不安が大きくなっ
てきています。そういう問題でもなさそうですけど。
Y.Kohno
In <86oehi3...@xa12.heimat.gr.jp>
NAKAJI Hiroyuki <nak...@tutrp.tut.ac.jp> wrote.
> DUMP: 25667006 blocks (12532.72MB) on 1 volume at 217KB/sec
> Blade100 の IDE って、そんなに遅いものなのか？
私がやってる範囲ではこの一桁上（2*** KB/sec くらい）が出ます
＃ ときどきやるので。 on Blade100/150
すごく以前に Blade100 でやったときは、もう一桁上近くの速度が出て、
「こりゃ早い」と思ったのですが、以後はそうでもありません。
＃ そのかわり、そのときはユーザアクセスの応答が
＃ ハングアップしたようになって閉口しました。
OS のリリースやパッチによるのかもしれませんが、
そのときの速度は以後、お目にかかりません。
> いくら ALI チップセットだからとは言え、
> ハードディスク間のバックアップでこんなに時間がかかったのが驚きでした。
ハードウェアのことはよくわかりませんが、
Blade1500 に IDE-HDD をつないで、SCSI --> IDE コピーを
ufsdump/ufsretore してみたときもたしか 2***KB/sec 程度でした。
＃ もうちょっと出てほしかった
--
河野 康司
Y.Kohno
In <codnf1$ge6$1...@news1.nikon.co.jp>
ko...@yellow.nikon.co.jp (Y.Kohno) wrote.
> Blade1500 に IDE-HDD をつないで、SCSI --> IDE コピーを
^^^^^^^^^
Blade2500
--
河野 康司
HIRAIZUMI Noriyuki
NAKAJI Hiroyuki wrote:
> Blade100 の IDE って、そんなに遅いものなのか？
純正ディスクではありませんがご参考まで。
# ufsdump 0f - /dev/rdsk/c0t0d0s7 >/backup/ST3120026A-S7
DUMP: Date of this level 0 dump: 2004年10月13日 (水) 16時19分01秒
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (unknown:/export) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 49599454 blocks (24218.48MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 13.56% done, finished in 1:03
DUMP: 29.84% done, finished in 0:47
DUMP: 49.24% done, finished in 0:30
DUMP: 64.51% done, finished in 0:22
DUMP: 81.92% done, finished in 0:11
DUMP: 49599422 blocks (24218.47MB) on 1 volume at 7166 KB/sec
DUMP: DUMP IS DONE
# uname -a
SunOS unknown 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Blade-100
# 原因は別だと思います。
og...@bento.ne.jp
nak...@tutrp.tut.ac.jpさんは書きました。
> /home (==/export/home) が足りなくなってきたので、HDDを増設して、
> ufsdump/ufsrestore でコピーしてから mount point を変更したのですが、そ
> の際、
>
> DUMP: 25667006 blocks (12532.72MB) on 1 volume at 217KB/sec
>
> というスピードでした。^_^;;
DiskSuiteでRAID構成にしていて、シングルユーザモードでufsdumpすると
遅くなるようです。
metasyncを実行して正常なstatusにすれば通常の速度になるはずです。
＃ Blade100でHDD増設ですからRAIDにはしていないのかな
--
NAKAJI Hiroyuki
皆様、いろいろと情報をありがとうございます。
問題の2台のディスクは同じケーブルにつないだ Cable Select な状態(これは Sun
が「このように増設せよ」と説明している) で、ufsdump の出力をパイプで
ufsrestore に渡しており、ufsrestore がディスクに書き込むのが遅いというのが
貢献しているかもしれないと思えてきました。
また、メールで、
forcedirectio | noforcedirectio
If forcedirectio is specified and sup-
ported by the file system, then for the
duration of the mount forced direct I/O
will be used. If the filesystem is mounted
using forcedirectio, then data is
transferred directly between user address
space and the disk. If the filesystem is
mounted using noforcedirectio, then data
is buffered in kernel address space when
data is transferred between user address
space and the disk. forcedirectio is a per-
formance option that benefits only from
large sequential data transfers. The
default behavior is noforcedirectio.
というオプションの存在を教わりました。大きいサイズの書き込みを一度にやると
きには、デフォルトの noforcedirectio では難があるようです。
>>>>> In <0412081307...@okarina.cij.co.jp>
>>>>> og...@bento.ne.jp wrote:
> ＃ Blade100でHDD増設ですからRAIDにはしていないのかな
http://docs.sun.com/source/806-3416-10/chap7.htm
の「7.3.3 Installing a Secondary Hard Drive」にある説明にしたがって、増設
しただけですから、RAID ではありません。
SAITOH Akinori
NAKAJI Hiroyuki wrote:
> 問題の2台のディスクは同じケーブルにつないだ Cable Select な状態(これは Sun
> が「このように増設せよ」と説明している) で、ufsdump の出力をパイプで
> ufsrestore に渡しており、ufsrestore がディスクに書き込むのが遅いというのが
> 貢献しているかもしれないと思えてきました。
確かに、 dump|restore すると、ボトルネックはrestore側
になります。というか、restore側のディスクのヘッドシーク
と言うか。
小さなファイルが多くあるときは forcedirectioはたぶん効
果が薄いと思います。僕は(他のOSでの事例ですが)ファイルシ
ステムを非同期マウントに変えてからrestoreしています。
今回は二つのディスクがIDEの同じチャンネルってのも問題
じゃないですかねぇ。
一度、ufsdumpの出力ファイルを /dev/nullにしてみると、
本来のdump速度が分かると思います。
--
齊藤明紀 saitoh at kankyo-u ac jp
Y.Kohno
In <874qixu...@roddy.acest.tutrp.tut.ac.jp>
NAKAJI Hiroyuki <nak...@tutrp.tut.ac.jp> wrote.
> 問題の2台のディスクは同じケーブルにつないだ Cable Select な状態
え？ っと思って確認すると、
In <86oehi3...@xa12.heimat.gr.jp>
> /dev/dsk/c0t2d0s3 115412949 13459023 100799797 12% /export/home
> /dev/dsk/c0t0d0s7 13461003 12488334 838059 94% /mnt
なので、別の IDE ケーブル、じゃないですか？
＃ 私はそうしてます。
そもそも Blade100/150 は IDE0 に CDROM(DVD) と 1'stHDD がつながってるので、
2'ndHDD は IDE1 につなぐことに（普通）なると思うのですが。
＃ CDROM(DVD) は c0t1d0
＃ ところでメモリはどのくらい積んでますか？
--
河野 康司
NAKAJI Hiroyuki
>>>>> In <cp8hhr$7sn$1...@news1.nikon.co.jp>
>>>>> ko...@yellow.nikon.co.jp (Y.Kohno) wrote:
> In <874qixu...@roddy.acest.tutrp.tut.ac.jp>
> NAKAJI Hiroyuki <nak...@tutrp.tut.ac.jp> wrote.
> > 問題の2台のディスクは同じケーブルにつないだ Cable Select な状態
> え？ っと思って確認すると、
> In <86oehi3...@xa12.heimat.gr.jp>
> > /dev/dsk/c0t2d0s3 115412949 13459023 100799797 12% /export/home
> > /dev/dsk/c0t0d0s7 13461003 12488334 838059 94% /mnt
> なので、別の IDE ケーブル、じゃないですか？
> ＃ 私はそうしてます。
そう言われてみれば、きちんと確認していませんでしたが、別のチャネルです
ね。すみません。
> そもそも Blade100/150 は IDE0 に CDROM(DVD) と 1'stHDD がつながってるので、
> 2'ndHDD は IDE1 につなぐことに（普通）なると思うのですが。
マニュアルにある説明通りに HDD を1台追加しましたので、おっしゃる通りで
す。
> ＃ ところでメモリはどのくらい積んでますか？
128MB + 512MB×3 です。512×4にしなかったのが悔やまれます。^^;
NAKAJI Hiroyuki
>>>>> In <cp8dvs$1mp$1...@caraway.media.kyoto-u.ac.jp>
>>>>> SAITOH Akinori <sai...@kankyo-u.ac.jp.nospam> wrote:
> NAKAJI Hiroyuki wrote:
> > 問題の2台のディスクは同じケーブルにつないだ Cable Select な状態(これは Sun
> > が「このように増設せよ」と説明している) で、ufsdump の出力をパイプで
> > ufsrestore に渡しており、ufsrestore がディスクに書き込むのが遅いというのが
> > 貢献しているかもしれないと思えてきました。
> 確かに、 dump|restore すると、ボトルネックはrestore側
> になります。というか、restore側のディスクのヘッドシーク
> と言うか。
推奨パッチを unzip するときなど、普段の利用でも書き込みが遅い印象があ
りますので、restore が書きに行くところがボトルネックだと理解しておくこ
とにします。
> 小さなファイルが多くあるときは forcedirectioはたぶん効
> 果が薄いと思います。僕は(他のOSでの事例ですが)ファイルシ
> ステムを非同期マウントに変えてからrestoreしています。
そういう方法もあるのですね。Solaris で非同期マウントはどうやるのかと思っ
たら、mount_ufs(1m)では見つけられませんでした。forcedirectio がそれに
当たるのでしょうか。
> 今回は二つのディスクがIDEの同じチャンネルってのも問題
> じゃないですかねぇ。
こっちは勘違いで、別チャネルでした。
> 一度、ufsdumpの出力ファイルを /dev/nullにしてみると、
> 本来のdump速度が分かると思います。
先にこれを試しておけばよかったと思います。一度、機会を見つけて試してみ
ます。