Re: /proc/fs/reiserfs question

[Hans Reiser <reiser@namesys.com>]

Nikita Danilov wrote:

>Hans Reiser writes:
> > Nikita Danilov wrote:
> > 
> > >Philippe Gramoullé writes:
> > > > Hi,
> > > > 
> > > > Is there any documentation that gives the description for each line 
> > > > of each file in /proc/fs/reiserfs/sd(x,x)/*
> > > > 
> > > > like what is the meaning of s_fix_nodes ? etc..
> > >
> > >I am afraid one has to dig it out of the sources. Here is description of
> > >some fields displayed in "super", they pertain to the in-core
> > >super-block:
> > >
> > >			"state": REISERFS_VALID_FS/REISERFS_ERROR_FS
> > >
> > >			"mount options": options given to mount
> > >
> > >			"gen. counter": file system "generation acounter"---this is
> > >			incremented with each balancing.
> > >
> > >			"s_kmallocs": how many kmallocs (calls to general purpose
> > >			kernel memory allocator) were performed by reiserfs code
> > >
> > >			"s_disk_reads": not maintained
> > >
> > >			"s_disk_writes": not maintained
> > >
> > >			"s_fix_nodes": how many time "fix-nodes" (1st phase of
> > >			balancing) was performed.
> > >
> > >			"s_do_balance": how many times "do-balance" (2nd phase of
> > >			balancing) was performed
> > >
> > >			"s_unneeded_left_neighbor": not maintained
> > >
> > >			"s_good_search_by_key_reada": not maintained
> > >
> > >			"s_bmaps": not maintained
> > >
> > >			"s_bmaps_without_search": not maintained
> > >
> > >			"s_direct2indirect": how many direct->indirect converions
> > >			were performed
> > >
> > >			"s_indirect2direct": how many indirect->direct converions
> > >			were performed
> > >
> > >			"max_hash_collisions": maximal hash collision met so far.
> > >
> > >			"breads": not maintained
> > >
> > >			"bread_misses": not maintained
> > >
> > >			"search_by_key": how many times search_by_key (main tree
> > >			traversal routine) was called.
> > >
> > >			"search_by_key_fs_changed": how many times search_by_key was
> > >			performed concurrently to balancing.
> > >
> > >			"search_by_key_restarted": how many times search_by_key had
> > >			to restart due to concurrent balancing.
> > >
> > >			"insert_item_restarted"-------+
> > >			"paste_into_item_restarted"   +
> > >			"cut_from_item_restarted"     +-> how many times particular
> > >			"delete_solid_item_restarted" +   balancing operation had to
> > >			"delete_item_restarted"-------+   restart
> > >
> > >			"leaked_oid": how many object-ids (unique identifiers
> > >			assigned to files) were missed
> > >
> > >			"leaves_removable": how many times three leaf nodes of the
> > >			balanced tree were mergeable into one
> > >
> > >I guess we should keep this information somewhere on the web-site. If
> > >you need more detailed info, let me know.
> > >
> > > > 
> > > > Thanks much,
> > > > 
> > > > Philippe.
> > >
> > >Nikita.
> > >
> > >
> > >  
> > >
> > The unmaintained fields should be removed.  Put into post-Halloween todo 
> > list.
>
>What about making them "maintained", in stead? Should be trivial.
>
Review which ones look like they would be genuinely informative, and 
then maintain just those, ok?  After Halloween.

>
> > 
> > Hans
> > 
>
>Nikita.
>
>
>  
>