pc944 による投稿:

mount count reached, running e2fsck is recommended

mount 回数が到達したので、e2fsckの実行をお勧めします

ですね。

連投すんません。

/dev/sda5と/dev/sda6で、tune2fs -l を実行して、mount count / maximum mount count を確認されてみてはいかがでしょう？

sda1,5,6 のいずれも mount count が maximum mount countを越えていないのに、mount count reached, running e2fsck is recommendedというメッセージが出るのがおかしいですね？

※カウントにずれがあるのは問題ないです。

オフトピ・・・

個人的には、「分散して早くなるからいいか」と思っていましたが。

物理的に同じディスク上でパーティションを分けても、分散にはならないです。
物理的に異なるディスクであればIOアクセスの分散にはなるので、多少は速くなる可能性はありますが。
読み書き性能の話ではないのかな？

kiyopさん＞もちろんそのことは知っております。でも、コメントしていただいてありがとうございます。
gontomoさん＞
オフトピ＞ここで簡単に説明しますね。
[      /      ][/boot][/home]  （60日ごと）      を一回にやるよりも、
[      /      ]
[/boot]
[/home]　　　　　　（綺麗になっていたら、20日ごと）　　　のほうが、一回一回の待ち時間が短くなるということです。
ただ、頻度は上がることになりますが。つまり、fsckの分散っという話です。
こんなどうでもいい話は置いておきましょう。本題。

sda1,5,6 のいずれも mount count が maximum mount countを越えていないのに、mount count reached, running e2fsck is recommendedというメッセージが出るのがおかしいですね？

↑ですが、毎回起動時にこのログが更新しているのなら、おかしいことになりますね。
※複数回書いてすいませんが、[通常の長いfsckはしっかりと動いています。]こちらは、お分かりいただきたく思います。
　ちなみに、今現在の結果です。

sda5
Mount count:              16
Maximum mount count:      60
sda6
Mount count:              51
Maximum mount count:      60

・・・このように、カウント値は正常に増えているようです。

bootchartを見ていくと、どうも5秒目のfsckが起動されたあたりから、DISK I/Oを伴うプロセスがことごとくI/O waitに入っているようにみえます。fsckを呼び出したあと、fsck.ext3に投げられるまでの時間が長いのが遅さの本質に見えるのですが、これもI/O waitしてるくさいです。udisks-part-idも同様です。

なんとなく、省いてしまっている部分にヒントというか、手がかりが隠れていそうに見えますが、fsckどうこうの話よりはハードウェア特有のなにかを踏んでいる気配がします。

bootchartの全体を見てみると、こんなもんじゃないかな？という気はしますけど。
確かにfsckで時間はかかっていますが、並列できちんと処理はされているので、全体には見た目10秒という数字ほどの影響は無いと思います。

起動までに43秒とでてますが、resumeの処理で5秒かかっているほうが全体への影響は大きいですね。
多分実際にresumeしているわけではなくて、resumeのデバイスの確認をしているんだと思います。
あとはHDDの読み書き速度と、全体的なPCのパフォーマンス次第な気がします。

レジュームデバイスの確認の件は、 /etc/initramfs-tools/conf.d/resume にかかれているUUIDと、swapデバイスのUUIDが一致しているかどうかを確認してみてください。

端末で

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=e70ba3c5-cebc-4136-99c4-200dc7f0708e

$ swapon -s
Filename                Type        Size    Used    Priority
/dev/sda3                               partition    10241428    0    -1

$ sudo blkid /dev/sda3
/dev/sda3: UUID="e70ba3c5-cebc-4136-99c4-200dc7f0708e" TYPE="swap"

青太字が一致しているかどうかを確認する。

違っていたら、 /etc/initramfs-tools/conf.d/resumeの方を訂正して、sudo update-initramfs -u を実行して再起動

確かに５秒ほど早くなりました。
でも・・・きがついたら１分以上になっていたのですが。
（やっぱりgdmをkdmに変えたことがだめだったかな・・・）
でも、体感速度は確実に早くなっているので、大丈夫です。
たぶん少し測りすぎているだけだと。
http://art36.photozou.jp/pub/534/429534 … 395834.png

それは。わざと止めています。
（すごく重くなるんですよね。毎回、最初に消すソフトの一つです。）
http://art29.photozou.jp/pub/534/429534 … g?size=450
http://art23.photozou.jp/pub/534/429534 … g?size=450
上を見ていただければ、よくわかるかと。起動直後の時点でこの差ですよ。さすがに耐えられません。
「起動、早くなるぞっ」って人も居ます。確かに早くはなります。でも、こんなに重ければ、意味がありません。
（結局ログインだけで１分以上かかって、一部のアプレットが異常終了してしまいますし。）
私の意見ですが。

そのうち別にインストールして試してみます。
本体のもういちどインストールは、怖すぎて出来ないので。（Synapticとかだけで、ランレベル１になったりするので〜）
リカバリから、apt-get remove ureadheadしかなくなるぐらい重いので。
（そのうちっていうか、今から試してみます。）

10.04 i386 ext4
9.04→9.10→10.04にアップグレードし、Grub2ではありません。
/ は、9.04のインストール時にext4にしました。
/home は、9.10の時にext3からext4へアップグレードしました。

やはりBootに時間がかかり(Starting Up…と始まるまで約1分、そこからログイン画面まで約30秒)、ログを見ると毎回fsckが走っています。
fsck from util-linux-ng 2.17.2
fsck from util-linux-ng 2.17.2
と。

うちもkdmですが、関係ない…ですよね?

fstabのオプションはこうなってます。
proc        defaults            0    0
swap        sw            0    0
udf,iso9660    user,noauto,exec,utf8    0    0
ext4        relatime,errors=remount-ro    0    1
ext4        defaults            0    2
tmpfs        defaults,size=368m        0    0

起動後の動作は特に不具合ありません。
このトピックの症状と同じでしょうか?

すいません、bootchartのログを取ってもらえますか？
Synapticからbootchart（pythonのも依存で入ると思います）を入れるか、
端末から
sudo apt-get install bootchart
です。
いちようどのように起動しているのかを調べるために・・・
/var/log/bootchart
にあります。
ちなみに最近ext4に変えてみました・・・
最近シャットダウン中に電源ボタン長押しすら効かないほどフリーズする時があります。
治りませんか？（これになったらコンセント抜く方法しかないです・・・Ctrl+Alt+Deleteも無理です。）

kiyopさん＞ありがとうございます。確かにSysRqは忘れていました。
試してみました。無理です・・・
（それと、電源ボタン長押しも効かない状態なのですが・・・なのでコンセント自体・・・）
そして現在のbootchart。
http://art25.photozou.jp/pub/534/429534/photo/45548383_org.v1281411737.png
※ログイン後のプロセスまで記録されていたのでモザイクあり。
おそらく上のグラフ（？）が白くなっている部分ぐらいまでが起動だと思います。