07/03/20 22:30:46 9XkrolDx
>>94
あれ、/:の出力が切れてますね。如何が全てです。
/: 1r 1c 2r 2c 3r 3c 4r 4c
5r 5c 6r 6c 44r 44c 47r 47c 48r 48c 49r
49c 50r 50c 196r 196c 292r 292c 294r 294c 295r 295c
312r 312c 1341r 1341c 1757r 1757c 1902r 1902c 1903r 1903c 1905r
1905c 2389r 2389c 2393r 2393c 2476r 2567r 2567c 2568r 2568c 2569r
2569c 2570r 2570c 2571r 2571c 2572r 2572c 2739r 2739c 2740r 5924r
6937r 6938r 26670r 27648r 27648c
98:80
07/03/20 23:06:50 9XkrolDx
>>89 可能性としてはありそうです。しかしその結果、なぜ今の状態になってしまったのかが謎です。
>>90どう見てもmountコマンド自体は終了してますが、カーネル内部的に「つかんだ」ままになっている
のでしょうか？
さて、そろそろソースを読まねばという感じです。ちなみにCentOS4.4の2.6.9カーネルです。
99:login:Penguin
07/03/20 23:45:52 w+2ZTJtq
>>97
> 無問題です。以下のようにしてあからさまにwriteでファイルを開かないと"busy"とはなりません。
あー、それならwriteで書き込まれたデータがまだディスクに書かれてない状態ですな。
まずはremount前にsyncを実行しましょう。
それでもダメな場合は、数秒待ってから再度sync->remountしてみてください。
私のところはFreeBSDだけど、shellスクリプト内でumountする時に以下のようにしています。
echo " unmount"
/bin/sync
/bin/sleep 60
/sbin/umount ${MNT}
for n in 0 1 2 3 4 5 6 7 8 9; do
if /sbin/mount | /usr/bin/grep /dev/ad0s1e > /dev/null; then
/bin/sleep 60; /sbin/umount /mnt
else
break
fi
done
100:login:Penguin
07/03/21 00:17:12 S9uQBvMx
URLﾘﾝｸ(linuxfs.pbwiki.com)
101:login:Penguin
07/03/21 01:02:22 DJG3OGOa
>>99
これだけ長時間バッファがフラッシュされないなんてありかな？
102:80
07/03/21 01:17:48 E4OzVxjT
>>99
syncもだめでした。それにしてもこの状態(busy)で安定したまま一日以上過ぎてますので。
ちょっとコードを読んで見ました。mountコールのエラーパスはこうなるようです。
|sys_mount (fs/namespace.c)
|-do_mount
|--path_lookup(fs/namei.c)
|---link_path_walk
|----__link_path_walk
| ごちょごちょして良く分からんがたぶんEBUSYは返さない？
|--security_sb_mount(include/linux/security.h)
|---security_ops->sb_mount
| 良く分からないけどSELinuxはdisableしてるから恐らく
| dummy.cのdummy_sb_mountでreturn 0
|--do_remount_sb
|
| if ((flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY)) {
| if (force)
| mark_files_ro(sb);
| else if (!fs_may_remount_ro(sb)) (fs/file_table.c)
| return -EBUSY;
| }
続く
103:80
07/03/21 01:19:39 E4OzVxjT
続き。ここで跳ねられてる？ "pending delete"のファイルってlsofとかでも見れませんでしたっけ？
|----fs_may_remount_ro(struct super_block *sb) (fs/file_table.c)
|{
| struct list_head *p;
|
| /* Check that no files are currently opened for writing. */
| file_list_lock();
| list_for_each(p, &sb->s_files) {
| struct file *file = list_entry(p, struct file, f_list);
| struct inode *inode = file->f_dentry->d_inode;
|
| /* File with pending delete? */
| if (inode->i_nlink == 0)
| goto too_bad;
|
| /* Writeable file? */
| if (S_ISREG(inode->i_mode) && (file->f_mode & FMODE_WRITE))
| goto too_bad;
| }
| file_list_unlock();
| return 1; /* Tis' cool bro. */
|too_bad:
| file_list_unlock();
| return 0;
|}
104:90
07/03/21 02:58:59 DJG3OGOa
>>98
別に根拠は無いです。
ファイルはつかまれてなさそうなので、デバイスをつかまれてないかなと思った。
105:login:Penguin
07/03/21 03:24:07 DJG3OGOa
rwでremountしてもやはりbusyになるんだろうか？
106:login:Penguin
07/03/21 03:31:16 DJG3OGOa
dmesgの結果や/var/log/messagesの内容も知りたい。
107:80
07/03/21 03:54:56 E4OzVxjT
>>105
いえ、それはOKです。けどrwをrwにremountしてもスルーされてるだけかもしれませんね。
>>106
mountコマンドを入力したときにはとくにどちらにも新たな出力は見られません。先ほど見た
エラーパスにも特にその周辺で何かを吐き出すコードは見られませんでした。また両方とも
デバイス名sdaでgrepして見ましたが、起動時の普通のメッセージ以外に特に最近異常を示す
メッセージは見受けられません。他に何か探すべきものがありましたらご指摘キボンヌ。
そろそろ上に挙げたコードにデバッグコードを埋め込んでカーネル再構築を試みます。
108:80
07/03/21 04:04:55 E4OzVxjT
>>103
> "pending delete"のファイルってlsofとかでも見れませんでしたっけ？
自己レス。普通は見えますね。
# mount -o remount,rw /
# cat > hogehoge
^Z
[1]+ Stopped cat >hogehoge
# rm -f hogehoge
# lsof | grep hogehoge
cat 9979 root 1w REG 3,8 0 983060 /hogehoge (deleted)
#
109:80
07/03/21 05:59:52 E4OzVxjT
inodeの中身をダンプするデバッグ用のルーチンなんかありませんかね？
出来るだけ情報を書き出したいけど、中身が全然分かってないから下手したら
そこでクラッシュしそう。
110:login:Penguin
07/03/21 11:54:21 DJG3OGOa
>>107
> そろそろ上に挙げたコードにデバッグコードを埋め込んでカーネル再構築を試みます。
障害の発生を再現するのは手間だから待った方がいいと思う。
試して欲しいのは、
mount -v -o remount, ro /
で詳細情報を表示させてみることと、
mount -f -o remount, ro /
で強制した場合にremountできるかということです。
111:login:Penguin
07/03/21 12:11:01 DJG3OGOa
mount -f -o remount, ro /
これをやってもらいたいのは、
>103の
fs_may_remount_ro(struct super_block *sb)
を通らず、
mark_files_ro(struct super_block *sb)
(fs/super.c 567)
に分岐すると思うからです。
112:login:Penguin
07/03/21 12:44:31 DJG3OGOa
mount -f -o remount, ro /
は
mount -v -f -o remount, ro /
の方が情報が得られてよいかも。
113:login:Penguin
07/03/21 12:55:08 6FsiTP6N
いくつか気になった。
・80と書いている人は81?
・うちのdebian(sarge)だと-vつけてもなんか変わらない
・ファイルシステムの種類は関係ない話なの？
何の役にも立たんと思うが。
114:login:Penguin
07/03/21 17:23:08 JC5nLr5t
うえの方でfind ... fuserしてほしいと書いた者だが、PID並べられてもしょうがないんだよね。
psで対応するコマンド調べてくらはい。
そのくらいはできる人と思ってたんだが、もしやド素人じゃないよね？
もしド素人なら、これでうまくいっても他で障害がでるだろうから、あまりごちゃごちゃやらんほうがいいと思うよ。
ド素人でないなら、、、もうちょっと独力でも頑張ってほしかった。
いずれにせよ、結果まってるよ～。
115:login:Penguin
07/03/21 18:35:16 J9iygeoh
>>86
tkt tktt
116:81(80は間違いorz)
07/03/21 21:06:42 E4OzVxjT
げげ、誰かリブートしやがったorz すみません。また障害発生を待たないと...
>>113
間違えてました orz
ちなみにext3です。
>>111
-fは(fake)であって-forceではありません。103の"force"は内部のemergency_remount()から呼ばれたときに
だけ立てられるフラグでこれは探したところdriver/char/sysrq.cのsysrq_handle_mountroからしか
呼ばれないので普通に使うものではないようです。
>>114
意図を汲まずに申し訳ございませんでしたが、何を探しているのかが良く分かってませんでした。
しかしあの出力で出てきたファイルのリストはlsofで出てきたものと同じようなものと見受けられましたし、
書き込み状態にあるpidも１つもありませんでしたのでどのpidに注目すればいいのかが分かりませんでした。
全部を列挙するのは長すぎると思いましたし。
fsは全くド素人でSMARTを見て、あ、ディスク壊れてるっていて交換したこと以上のことを
考えたことはありませんのでファイル周りの検証のテクニックはlsofぐらいしか知りませんでした。
fuserは初耳でしたので勉強になりました。カーネルの中をまじめに問題解決のために読み始めたのも
ここ１ヶ月ほどの事ですので。
さて、それではカーネル仕掛けてまた再現するのを待って報告させて頂きます。
117:login:Penguin
07/03/21 22:14:49 nLBpV1q7
>>116
lsofで結果見てたんだね。失礼。
閉じられているはずのファイルがなぜか開きっぱなしの問題はよくあることです。
解決方法がなかなか見つからないので、ぜひがんばってください。
報告待ってます。
118:login:Penguin
07/03/21 22:16:28 J9iygeoh
閉じられてるファイルが～なぜか開いているのな～ら～
sync！sync！sync！
って歌があったね
119:login:Penguin
07/03/21 23:24:46 f2Azm7Ce
だめよだめだめデッドローックー
120:login:Penguin
07/03/23 08:47:39 TxxCM3Q2
ext4はｻｲｽﾞ変更に対応してる？対応してればLVMと組み合わせて使い易いのだけど。
性能的にはどうなんだろう？
121:login:Penguin
07/03/24 03:14:39 GQsk1lU1
そういやオンラインデフラグの件はどうなったんだ？
122:login:Penguin
07/03/24 16:08:19 ZQgilKja
Reiserはその後どうなってんの？
123:login:Penguin
07/03/24 22:04:18 vUqhXPFh
WInの焼きミスはほんとひどいよなw
焼いてるときは、他の作業しないほうがいい
124:login:Penguin
07/03/24 22:05:31 1ZNqfG35
>>123
お前はバブルの崩壊直後の時代の人か？
125:login:Penguin
07/03/24 23:17:11 1JVeQLQG
>>123
スレ違いだ。帰れ。
126:login:Penguin
07/03/24 23:48:50 ZQgilKja
>>124
またキミか
127:login:Penguin
07/03/25 00:23:02 FK7WfcVZ
3 名前：login:Penguin ：2007/03/24(土) 22:37:58 ID:1ZNqfG35
うざいなぁ・・・・
913 ：login:Penguin：2007/03/24(土) 22:34:12 ID:1ZNqfG35
>>911
＞Windowsじゃあるまいし、ブートローダごときで再インストールする必要はない。
fixmbrもしらんWindows道程であることが判明しましたｗ
128:login:Penguin
07/03/25 23:21:02 QdX/ZMUE
前スレで言われてたけど、nautilus+xfsでファイルのコピー等がすごく遅くなるってあったでしょ？
俺もあれで悩まされてたんだけど、LVM使ったらあのバグ発生しないんだね。
なんとなくLVM+xfsで新たにシステム構築し直したらnautilusでも速度が落ちなくなった。
129:login:Penguin
07/03/26 09:08:09 d1UYMG6t
LVMは便利なのだが、コマンドいっぱいでめんどいよね
130:login:Penguin
07/03/26 09:21:06 8Q9E4hQ9
>>128
というか報告せいや
xfsなのかnautilusなのか知らんが
131:login:Penguin
07/03/26 10:35:37 fsC9be4T
nautilus＝糞
昔からの定説だろ。いまさら報告する必要もなし。
132:login:Penguin
07/03/26 11:28:49 io8NkORY
だったら、使うなw
133:login:Penguin
07/03/26 14:17:18 d1UYMG6t
>>131
またキミか。