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 [email protected] 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;
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: [email protected] (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 <[email protected]> instead of <[email protected]>.
(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
> (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.
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: [email protected] (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 <[email protected]> instead of <[email protected]>.
>
>(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
>
>
>
>
>
[email protected] (Linus Torvalds) wrote on 09.09.02 in <[email protected]>:
> 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
On Tue, Sep 10, 2002 at 08:59:00AM +0200, Kai Henningsen wrote:
> [email protected] (Linus Torvalds) wrote on 09.09.02 in <[email protected]>:
> > 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
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