[BK] PATCH ReiserFS 1 of 3 RESEND

[BK] PATCH ReiserFS 1 of 3 RESEND

[Hans Reiser]

Hello!

   This changesets adds displaying of some aditional reiserfs statistics through
   /proc interface. Please apply.
   You can get it from bk://thebsh.namesys.com/bk/reiser3-linux-2.5

Diffstat:
 fs/reiserfs/procfs.c           |   13 +++++++++++++
 fs/reiserfs/stree.c            |   10 +++++++++-
 include/linux/reiserfs_fs_sb.h |    6 ++++++
 3 files changed, 28 insertions(+), 1 deletion(-)

Plain text patch
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.499   -> 1.500  
#	fs/reiserfs/procfs.c	1.12    -> 1.13   
#	include/linux/reiserfs_fs_sb.h	1.17    -> 1.18   
#	 fs/reiserfs/stree.c	1.31    -> 1.32   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/08/20	green@angband.namesys.com	1.500
# Add displaying of more reiserfs statistical info through /proc interface, by Nikita Danilov
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/procfs.c b/fs/reiserfs/procfs.c
--- a/fs/reiserfs/procfs.c	Tue Aug 20 13:58:46 2002
+++ b/fs/reiserfs/procfs.c	Tue Aug 20 13:58:46 2002
@@ -165,6 +165,12 @@
 			"search_by_key_fs_changed: \t%lu\n"
 			"search_by_key_restarted: \t%lu\n"
 			
+			"insert_item_restarted: \t%lu\n"
+			"paste_into_item_restarted: \t%lu\n"
+			"cut_from_item_restarted: \t%lu\n"
+			"delete_solid_item_restarted: \t%lu\n"
+			"delete_item_restarted: \t%lu\n"
+
 			"leaked_oid: \t%lu\n"
 			"leaves_removable: \t%lu\n",
 
@@ -201,6 +207,13 @@
 			SFP( search_by_key ),
 			SFP( search_by_key_fs_changed ),
 			SFP( search_by_key_restarted ),
+
+			SFP( insert_item_restarted ),
+			SFP( paste_into_item_restarted ),
+			SFP( cut_from_item_restarted ),
+			SFP( delete_solid_item_restarted ),
+			SFP( delete_item_restarted ),
+
 			SFP( leaked_oid ),
 			SFP( leaves_removable ) );
 
diff -Nru a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
--- a/fs/reiserfs/stree.c	Tue Aug 20 13:58:46 2002
+++ b/fs/reiserfs/stree.c	Tue Aug 20 13:58:46 2002
@@ -1245,6 +1245,8 @@
 	if ( n_ret_value != REPEAT_SEARCH )
 	    break;
 
+	PROC_INFO_INC( p_s_sb, delete_item_restarted );
+
 	// file system changed, repeat search
 	n_ret_value = search_for_position_by_key(p_s_sb, p_s_item_key, p_s_path);
 	if (n_ret_value == IO_ERROR)
@@ -1355,8 +1357,10 @@
 	}
 
 	retval = fix_nodes (M_DELETE, &tb, NULL, 0);
-	if (retval == REPEAT_SEARCH)
+	if (retval == REPEAT_SEARCH) {
+	    PROC_INFO_INC( th -> t_super, delete_solid_item_restarted );
 	    continue;
+	}
 
 	if (retval == CARRY_ON) {
 	    do_balance (&tb, 0, 0, M_DELETE);
@@ -1543,6 +1547,8 @@
       	if ( n_ret_value != REPEAT_SEARCH )
 	    break;
 	
+	PROC_INFO_INC( p_s_sb, cut_from_item_restarted );
+
 	n_ret_value = search_for_position_by_key(p_s_sb, p_s_item_key, p_s_path);
 	if (n_ret_value == POSITION_FOUND)
 	    continue;
@@ -1810,6 +1816,7 @@
     
     while ( (retval = fix_nodes(M_PASTE, &s_paste_balance, NULL, p_c_body)) == REPEAT_SEARCH ) {
 	/* file system changed while we were in the fix_nodes */
+	PROC_INFO_INC( th -> t_super, paste_into_item_restarted );
 	retval = search_for_position_by_key (th->t_super, p_s_key, p_s_search_path);
 	if (retval == IO_ERROR) {
 	    retval = -EIO ;
@@ -1860,6 +1867,7 @@
 
     while ( (retval = fix_nodes(M_INSERT, &s_ins_balance, p_s_ih, p_c_body)) == REPEAT_SEARCH) {
 	/* file system changed while we were in the fix_nodes */
+	PROC_INFO_INC( th -> t_super, insert_item_restarted );
 	retval = search_item (th->t_super, key, p_s_path);
 	if (retval == IO_ERROR) {
 	    retval = -EIO;
diff -Nru a/include/linux/reiserfs_fs_sb.h b/include/linux/reiserfs_fs_sb.h
--- a/include/linux/reiserfs_fs_sb.h	Tue Aug 20 13:58:46 2002
+++ b/include/linux/reiserfs_fs_sb.h	Tue Aug 20 13:58:46 2002
@@ -270,6 +270,12 @@
   stat_cnt_t search_by_key_fs_changed;
   stat_cnt_t search_by_key_restarted;
 
+  stat_cnt_t insert_item_restarted;
+  stat_cnt_t paste_into_item_restarted;
+  stat_cnt_t cut_from_item_restarted;
+  stat_cnt_t delete_solid_item_restarted;
+  stat_cnt_t delete_item_restarted;
+
   stat_cnt_t leaked_oid;
   stat_cnt_t leaves_removable;
 

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Linus Torvalds]

Hans,
 one of the reasons for problems with your patches is that your emails 
seem to sometimes be labeled as spam.

And one of the major reasons for that is apparently simply that your 
"From:" address is not a good one:

	From: reiser@reload.namesys.com (Hans Reiser)

where "reload.namesys.com" is not in the MX domain:

	dig -t MX reload.namesys.com

gives no answer. As a result, spam detectors look at the From: line and 
consider you an extremely suspect person, likely to be up to no good.

I would suggest you fix your mailer to have a valid MX-record return 
address, ie <reiser@namesys.com> instead of <reiser@reload.namesys.com>.

(Yes, I realize that both addresses likely work perfectly fine, and that
"reload"  is the machine you actually use for sending the email, but
still.. I bet I'm not the only one who uses spam filtering software that
cares about issues like this.)

[ Cc to linux-kernel left intact not to publicly castigate Hans, but 
  because I know this is true for some other people too. ]

			Linus

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Tomas Szepe]

> (Yes, I realize that both addresses likely work perfectly fine, and that
> "reload"  is the machine you actually use for sending the email, but
> still.. I bet I'm not the only one who uses spam filtering software that
> cares about issues like this.)

Linus, if your spam filtering software considers a post with a unidiff
inside it spam, it's apparently not too terrific.

T.

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Helge Hafting]

Tomas Szepe wrote:
> 
> > (Yes, I realize that both addresses likely work perfectly fine, and that
> > "reload"  is the machine you actually use for sending the email, but
> > still.. I bet I'm not the only one who uses spam filtering software that
> > cares about issues like this.)
> 
> Linus, if your spam filtering software considers a post with a unidiff
> inside it spam, it's apparently not too terrific.

A good point today, but dangerous.  If "unidiff makes it ok" becomes 
mainstream (i.e. some distro packages that sort of antispam sw) then 
spammers surely will append a real small unidiff to their messages.
Today they put extra letters in the subject, fooling yesterday's
spam detectors. . .

Helge Hafting

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Hans Reiser]

Thanks for your suggestion, we will act on it and do so.

Hans

Linus Torvalds wrote:

>Hans,
> one of the reasons for problems with your patches is that your emails 
>seem to sometimes be labeled as spam.
>
>And one of the major reasons for that is apparently simply that your 
>"From:" address is not a good one:
>
>	From: reiser@reload.namesys.com (Hans Reiser)
>
>where "reload.namesys.com" is not in the MX domain:
>
>	dig -t MX reload.namesys.com
>
>gives no answer. As a result, spam detectors look at the From: line and 
>consider you an extremely suspect person, likely to be up to no good.
>
>I would suggest you fix your mailer to have a valid MX-record return 
>address, ie <reiser@namesys.com> instead of <reiser@reload.namesys.com>.
>
>(Yes, I realize that both addresses likely work perfectly fine, and that
>"reload"  is the machine you actually use for sending the email, but
>still.. I bet I'm not the only one who uses spam filtering software that
>cares about issues like this.)
>
>[ Cc to linux-kernel left intact not to publicly castigate Hans, but 
>  because I know this is true for some other people too. ]
>
>			Linus
>
>
>
>  
>

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 09.09.02 in <Pine.LNX.4.44.0209090831240.1641-100000@home.transmeta.com>:

> where "reload.namesys.com" is not in the MX domain:
>
> 	dig -t MX reload.namesys.com

... i.e., does not have a MX record.

> (Yes, I realize that both addresses likely work perfectly fine, and that

Since the RFCs *demand* that an address mentioned in mail has an MX  
record, and the fallback to A records was not, until recently, described,  
there probably are some mailers that cannot deliver mail to that address.  
Which, in my book, counts as "not perfectly fine", even though I admit  
those mailers are probably in a minority as, sadly, this particular  
disease is pretty widespread.

Still. I personally count it as a bug just the same as using an implicit  
extern to call a function.

> [ Cc to linux-kernel left intact not to publicly castigate Hans, but
>   because I know this is true for some other people too. ]

Similar here.

MfG Kai

Re: [BK] PATCH ReiserFS 1 of 3 RESEND

[Matti Aarnio]

On Tue, Sep 10, 2002 at 08:59:00AM +0200, Kai Henningsen wrote:
> torvalds@transmeta.com (Linus Torvalds)  wrote on 09.09.02 in <Pine.LNX.4.44.0209090831240.1641-100000@home.transmeta.com>:
> > where "reload.namesys.com" is not in the MX domain:
> >
> > 	dig -t MX reload.namesys.com
> ... i.e., does not have a MX record.
> > (Yes, I realize that both addresses likely work perfectly fine, and that
> 
> Since the RFCs *demand* that an address mentioned in mail has an MX  
> record, and the fallback to A records was not, until recently, described,  
> there probably are some mailers that cannot deliver mail to that address.  
> Which, in my book, counts as "not perfectly fine", even though I admit  
> those mailers are probably in a minority as, sadly, this particular  
> disease is pretty widespread.

  You haven't read your RFCs.  They demand no such thing!

  Recently the compilations of RFC 2821 and 2822 were done because there
  are about a dozen RFCs full of obscure details, and even errors.


  RFC 1123 (Requirements for Internet Hosts -- Application and Support)
  does say that the SMTP CLIENT (e.g. sending SMTP system) must support
  and use MXes.    RFC 974 says HOW:


  RFC 974 around page 4:  (Mail Routing and the Domain System)

Interpreting the List of MX RRs
  ....
   It is possible that the list of MXs in the response to the query will
   be empty.  This is a special case.  If the list is empty, mailers
   should treat it as if it contained one RR, an MX RR with a preference
   value of 0, and a host name of REMOTE.  (I.e., REMOTE is its only
   MX).  In addition, the mailer should do no further processing on the
   list, but should attempt to deliver the message to REMOTE.  The idea
   here is that if a domain fails to advertise any information about a
   particular name we will give it the benefit of the doubt and attempt
   delivery.

...
> MfG Kai

/Matti Aarnio