/proc/fs/reiserfs question

/proc/fs/reiserfs question

[Philippe Gramoullé]

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..

Thanks much,

Philippe.

Re: /proc/fs/reiserfs question

[Nikita Danilov]

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.

Re: /proc/fs/reiserfs question

[Hans Reiser]

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.

Hans

Re: /proc/fs/reiserfs question

[Nikita Danilov]

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.

 > 
 > Hans
 > 

Nikita.

Re: /proc/fs/reiserfs question

[Philippe Gramoullé]

On Mon, 14 Oct 2002 18:25:19 +0400
Nikita Danilov <Nikita@namesys.com> wrote:

  |  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:
  | [-]
  |  I guess we should keep this information somewhere on the web-site. If
  |  you need more detailed info, let me know.

Thank nikita, this is fine for me.

I was also looking for a way to have an idea of how many files sit on a filesystem
without having to walk through the whole tree and list each of them.

Thanks,

Philippe

Re: /proc/fs/reiserfs question

[Nikita Danilov]

Philippe Gramoullé writes:
 > On Mon, 14 Oct 2002 18:25:19 +0400
 > Nikita Danilov <Nikita@namesys.com> wrote:
 > 
 >   |  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:
 >   | [-]
 >   |  I guess we should keep this information somewhere on the web-site. If
 >   |  you need more detailed info, let me know.
 > 
 > Thank nikita, this is fine for me.
 > 
 > I was also looking for a way to have an idea of how many files sit on a filesystem
 > without having to walk through the whole tree and list each of them.

/proc/fs/reiserfs/*/oidmap lists "object-id" map. If this map never
overflowed (overflows happened during current mount are counted in
leaked_oid field of /proc/fs/reiserfs/*/super), then, sum of lengths of
`used' intervals is the number of files on the file system. This sum is
shown at the very bottom of oidmap:

total:  160 [160/1004] used: 178598 [exact]

178598 is total number of files.

Generally, until one has really weird access patterns this map shouldn't
overflow. Problem is that, due to simplistic implementation of procfs
stuff, no file on /proc/fs/reiserfs/*/ can be larger than 4k and thus,
if oidmap happened to be highly fragmented, it wouldn't fit completely,
and will be ended with

... and more
total:  160 [820/1004] used: 178598 [estimation]

Again, this is trivial to correct, but not before Hallowmas, I am afraid.

 > 
 > Thanks,
 > 
 > Philippe

Nikita.

Re: /proc/fs/reiserfs question

[Hans Reiser]

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.
>
>
>  
>