Re: -- warning("vs-44", "out of memory?"); --[ addendum ]--

2006-04-06 Thread Valdis . Kletnieks
On Thu, 06 Apr 2006 09:07:42 +0200, Roy Lanek said:

> the freezing, for once. The system is otherwise DECENTLY
> usable really, provided one does not start to use the
> GIMP, Open Office or similar. 

You have much lower standards of usability than many of us.

"Client 2: I don't know we need to worry too much about strengthening that.
After all, these are not meant to be luxury flats.

Client 1: Absolutely. If we make sure the tenants are of light build and
relatively sedentary and if the weather's on our side, I think we have a winner
here."
-- Monty Python, the Architect sketch.





pgpukog96Tc90.pgp
Description: PGP signature


script binding for reiserfs?

2006-04-06 Thread Dongxu Ma
Hi all,As reiserfs more and more popular, is there any binding package for use in script languages? I did a search on Google and nothing found.Curently I am thinking about writing a binding for Perl, which can offer:
1) script-level operation against reiserfs2) DBI && DBD for reiserfs binding to treat the fs as a database. My aim is constructing a mid-and-small wiki directly on reiserfs without employing any real database
However, after some seeking on source. I got several issues:1) is there any so-called official userspace api exported? On gentoo there is a package named progsreiserfs introducing an api set under /usr/include/reiserfs, but I am not very sure if it is stable and the project is still alive.
2) regarding reiser3, where could I start to port? since exporting something in kernelspace is quite risky. Any advice and hint?-- Cheers, Dongxu__END__
dongxu.wordpress.comsearch.cpan.org/~dongxu


Re: can anybody check that the attached patch eliminates reiser4 compilation warnings on 64bit platforms?

2006-04-06 Thread Brian Uhrain

Hello,

Alexander Zarochentsev wrote:
would you please help to check the attached patch (for 2.6.17-rc1-mm1) 
because our Alpha does not want to boot now.


I'm not sure what the last kernel version you had booting was (or what 
the error is now the your Alpha system does not want to boot), but I 
recently discovered a problem with kernels booting on my Alpha that was 
introduced in one of the 2.6.16-rc's.  Yesterday I was able to track 
down and squash the bug, and submitted my patch (two versions, one for 
2.6.16.1 and the other for 2.6.17-rc1) to the LKML.  After fixing the 
issue with CPU initialization, which looks like it would affect any 
Alpha system as it was a case of things changing/being added in all of 
the other architectures but not for the Alpha architecture, the system 
has been running fine with a 2.6.16.1 kernel and reiser4 root 
filesystem. :)  You can find my email with the patch at 
http://lkml.org/lkml/mbox/2006/4/5/69


 - Brian


BTW, your patch to silence the printf-style format string argument 
warnings looks fine to me. :)


Re: -- warning("vs-44", "out of memory?");

2006-04-06 Thread Vladimir V. Saveliev
Hello

On Thu, 2006-04-06 at 06:41 +, Roy Lanek wrote:
> There might be something to debug around: 
> 
>warning("vs-44", "out of memory?"); 
> 
>line 2674 of /.../linux/fs/reiser4/plugin/file/file.c 
> 
> In fact, I just have seen a long, unterminated series of
> reiser4-out-of-memory warnings in my logs when my box
> has started to freeze ... till it has frozen completely
> several minutes later. 
> 
> Unfortunately I have lost all the logs (see below) ... I
> am sad for the # cut out --- thing that I have seen
> and can't reproduce; I had to reboot and did not want to
> write down by hand the few items that were visible trough
> the few overlapped xterms (+ elvis). 
> 
> Don't worry, it will happen again enough soon: if you say
> that it makes sense, I will manage to not be caught by
> surprise again, will try to save the logs immediately,
> when the system starts to freeze. 
> 

Yes, please so because it is very likely that "vs-44" was preceded by
another log record which showed the real crash reason.

> OK, here a bit more context: 
> 
> ** kernel (... uname): 
> 
>2.6.16.1-grsec #3 Wed Apr 5 22:46:36 WIT 006 i586 pentium
>i386 GNU/Linux 
> 
>compiled without debug support for reiser4 
> 
>vanilla patches reiser4-for-2.6.16-1
>+ grsecurity-2.1.9-2.6.16.1-200604041154 
> 
> ** runit-1.4.1 + socklog-2.1.0 
> 
> ** Slackware current, i.e., gcc 3.4.6 
> 
> ** a P166/32 Mb + non SCSI HDs. (It works, I swear, and
> well too!) 
> 
> 
> Cheers, 
> 
> /Roy Lanek (West Sumatra) 
> 
>  --
>    tak ada gading yang tak retak
> # . slackware ##   there are no ivory that is not cracked
> # +-linux ## [nothing is perfect in this world]
> 
> 



can anybody check that the attached patch eliminates reiser4 compilation warnings on 64bit platforms?

2006-04-06 Thread Alexander Zarochentsev
hello,

would you please help to check the attached patch (for 2.6.17-rc1-mm1) 
because our Alpha does not want to boot now.

the warning were:

fs/reiser4/jnode.c: In function `info_jnode':
fs/reiser4/jnode.c:1923: warning: long long unsigned int format, __u64 
arg (arg 2)
fs/reiser4/key.c: In function `print_key':
fs/reiser4/key.c:88: warning: long long unsigned int format, oid_t arg 
(arg 3)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg 
(arg 5)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg 
(arg 6)
fs/reiser4/key.c:88: warning: long long unsigned int format, oid_t arg 
(arg 7)
fs/reiser4/key.c:88: warning: long long unsigned int format, __u64 arg 
(arg 8)
fs/reiser4/key.c:94: warning: long long unsigned int format, oid_t arg 
(arg 3)
fs/reiser4/key.c:94: warning: long long unsigned int format, __u64 arg 
(arg 5)
fs/reiser4/key.c:94: warning: long long unsigned int format, oid_t arg 
(arg 6)
fs/reiser4/key.c:94: warning: long long unsigned int format, __u64 arg 
(arg 7)
fs/reiser4/super_ops.c: In function `reiser4_dirty_inode':
fs/reiser4/super_ops.c:176: warning: long long unsigned int format, 
oid_t arg (arg 9)
fs/reiser4/plugin/file_ops_readdir.c: In function `readdir_common':
fs/reiser4/plugin/file_ops_readdir.c:635: warning: long long unsigned 
int format, oid_t arg (arg 9)
fs/reiser4/plugin/dir_plugin_common.c: In function `rem_entry':
fs/reiser4/plugin/dir_plugin_common.c:207: warning: long long unsigned 
int format, oid_t arg (arg 9)
fs/reiser4/plugin/file/file.c: In function `delete_object_unix_file':
fs/reiser4/plugin/file/file.c:2986: warning: long long unsigned int 
format, oid_t arg (arg 9)
fs/reiser4/plugin/space/bitmap.c: In function `bnode_check_adler32':
fs/reiser4/plugin/space/bitmap.c:506: warning: long long unsigned int 
format, bmap_nr_t arg (arg 9)

Thanks in advance.
-- 
Alex.
A fix for printk format specifications and __u64 arguments mismatch, visible
on Alpha platform.

Signed-off-by: <[EMAIL PROTECTED]>

---

 fs/reiser4/key.c  |   16 +---
 fs/reiser4/plugin/dir_plugin_common.c |2 +-
 fs/reiser4/plugin/file/file.c |2 +-
 fs/reiser4/plugin/file_ops_readdir.c  |2 +-
 fs/reiser4/plugin/space/bitmap.c  |2 +-
 fs/reiser4/super_ops.c|2 +-
 6 files changed, 14 insertions(+), 12 deletions(-)

Index: linux-2.6.17-rc1-mm1/fs/reiser4/key.c
===
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/key.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/key.c
@@ -81,17 +81,19 @@ void print_key(const char *prefix /* pre
 	else {
 		if (REISER4_LARGE_KEY)
 			printk("%s: (%Lx:%x:%Lx:%Lx:%Lx:%Lx)", prefix,
-			   get_key_locality(key),
+			   (unsigned long long)get_key_locality(key),
 			   get_key_type(key),
-			   get_key_ordering(key),
-			   get_key_band(key),
-			   get_key_objectid(key), get_key_offset(key));
+			   (unsigned long long)get_key_ordering(key),
+			   (unsigned long long)get_key_band(key),
+			   (unsigned long long)get_key_objectid(key),
+			   (unsigned long long)get_key_offset(key));
 		else
 			printk("%s: (%Lx:%x:%Lx:%Lx:%Lx)", prefix,
-			   get_key_locality(key),
+			   (unsigned long long)get_key_locality(key),
 			   get_key_type(key),
-			   get_key_band(key),
-			   get_key_objectid(key), get_key_offset(key));
+			   (unsigned long long)get_key_band(key),
+			   (unsigned long long)get_key_objectid(key),
+			   (unsigned long long)get_key_offset(key));
 		/*
 		 * if this is a key of directory entry, try to decode part of
 		 * a name stored in the key, and output it.
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/dir_plugin_common.c
===
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/dir_plugin_common.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/dir_plugin_common.c
@@ -206,7 +206,7 @@ rem_entry(struct inode *dir, struct dent
 		if (get_key_objectid(&key) != get_inode_oid(child)) {
 			warning("nikita-3397",
 "rem_entry: %#llx != %#llx\n",
-get_key_objectid(&key),
+(unsigned long long)get_key_objectid(&key),
 (unsigned long long)get_inode_oid(child));
 			return RETERR(-EIO);
 		}
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file/file.c
===
--- linux-2.6.17-rc1-mm1.orig/fs/reiser4/plugin/file/file.c
+++ linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file/file.c
@@ -2971,7 +2971,7 @@ int delete_object_unix_file(struct inode
 
 	if (result)
 		warning("", "failed to truncate file (%llu) on removal: %d",
-			get_inode_oid(inode), result);
+			(unsigned long long)get_inode_oid(inode), result);
 
 	/* remove stat data and safe link */
 	return delete_object_common(inode);
Index: linux-2.6.17-rc1-mm1/fs/reiser4/plugin/file_ops_readdir.c

-- warning("vs-44", "out of memory?"); --[ addendum ]--

2006-04-06 Thread Roy Lanek

Notice that I am--happily--on reiser4 since the beginning
of the 2.6.x series (of course with the same hardware
... on Reiser since the last 2.2.x by the way). And that
the freezing thing ... perhaps once every several days,
does not come as a novelty. New is that I have been able,
perhaps thanks to grsecurity, to see more near (maybe) at
the freezing, for once. The system is otherwise DECENTLY
usable really, provided one does not start to use the
GIMP, Open Office or similar. 



Cheers, 


/Roy Lanek
--

# . slackware ## rajin pangkal pandai
# +-linux ##   diligence is the beginning of brilliance