Re: [reiserfs-list] ps strangeness

Nikita Danilov (NikitaDanilov@Yahoo.COM)
Tue, 31 Jul 2001 20:28:19 +0400


Chris Wedgwood writes:
> On Mon, Jul 30, 2001 at 07:20:44PM -0700, Florin Andrei wrote:
>
> If i run "ps ax", sometimes i see this: once i get the correct
> list of processes, once i get an empty list.
>
> It sounds like /proc changing underneath the ps application, it
> happens with other utilities from time to time too (eg. netstat).

That is what going on:

1. when deleting file reiserfs doesn't care to set i_blocks to 0 and,
moreover for symlinks it happens to be set to -7 (into unsigned
field!). It doesn't hurt, because file is being deleted anyway.
2. in-memory inode is immediately reused for /proc inode.
3. procfs_read_inode() doesn't bother to clear i_blocks either (neither
does VFS get_new_inode(), why, Alexander?)
4. now we have /proc file-system inode with huge i_blocks field.
5. top(1) calls stat() on this inode. Libc wrapper function decides
that i_blocks doesn't fit into st_blocks and returns EOVERFLOW.
6. top shows nothing.

Solutions:

1. update get_new_inode() to clear i_blocks
2. update procfs_read_inode() to clear i_blocks
3. update reiserfs_delete_inode() to clear i_blocks

Patch implementing last option (by Vladimir Saveliev):
--------------------------------------------------
--- linux-2.4.7/fs/reiserfs/inode.c Sat Jul 21 21:05:18 2001
+++ linux-2.4.7.patched/fs/reiserfs/inode.c Tue Jul 31 18:55:53 2001
@@ -55,6 +55,7 @@ void reiserfs_delete_inode (struct inode
;
}
clear_inode (inode); /* note this must go after the journal_end to prevent deadlock */
+ inode->i_blocks = 0;
unlock_kernel() ;
}
--------------------------------------------------

>
> There isn't much that can be done about it, other than the
> applications needs to be a little smarted so they can detect /proc
> changes part-way-through gathering data.
>
>
>
> --cw

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/