[reiserfs-list] hash signed-ness fix

2001-06-23 Thread Jeff Mahoney


Hello all -

I discovered this week that PPC is the only platform in the kernel to
define -fsigned-char as a compiler flag. The problem with this is that
the hash functions simply declare 'const char *' as its string argument.
The result is clear: on PPC, filenames with high ASCII [*] characters
generate incorrect hashes. The hashes are consistent in-system, but if
e.g. a x86 disk is attached to a PPC system, or a PPC disk is attached
to an x86, these files will be rendered inaccessible.

Attached are two files. The first is a patch that alters the hash functions
to take a 'const unsigned char *' string argument explicitly. It should
apply to any 2.4.x kernel. The second file is a script for PPC users
to use to locate filenames on their filesystems containing high ASCII
names.

On platforms other than PPC, these patches can be applied with no net
effect - since hashes are already generated as expected.

On PPC, the user will need to find all high ASCII filenames, and rename
them using only normal ASCII characters temporarily, until the system
uses the 'patched' reiserfs. Once you've booted using the 'patched'
reiserfs, you can rename the files to their original names. If you don't
follow this process, files created with high ASCII names prior to patching
will no longer be accessible.

I'm working on coding up a more user friendly solution, in kernel and via
fsck, but in the meantime, this is the only workaround.

-Jeff

[*]: high ASCII - characters with an ASCII value  127, such as ø or ®.

-- 
Jeff Mahoney
[EMAIL PROTECTED]
[EMAIL PROTECTED]


diff -ruPBb -x CVS linux/fs/reiserfs/hashes.c 
tmp/reiserfs/linux-kernel//fs/reiserfs/hashes.c
--- linux/fs/reiserfs/hashes.c  Mon Jan 15 15:42:32 2001
+++ tmp/reiserfs/linux-kernel//fs/reiserfs/hashes.c Wed Jun 20 18:16:20 2001
@@ -52,7 +52,7 @@
} while(0)
 
 
-u32 keyed_hash(const char *msg, int len)
+u32 keyed_hash(const unsigned char *msg, int len)
 {
u32 k[] = { 0x9464a485, 0x542e1a94, 0x3e846bff, 0xb75bcfc3}; 
 
@@ -178,7 +178,7 @@
 /* What follows in this file is copyright 2000 by Hans Reiser, and the
  * licensing of what follows is governed by reiserfs/README */
 
-u32 yura_hash (const char *msg, int len)
+u32 yura_hash (const unsigned char *msg, int len)
 {
 int j, pow;
 u32 a, c;
@@ -213,7 +213,7 @@
 return a;
 }
 
-u32 r5_hash (const char *msg, int len)
+u32 r5_hash (const unsigned char *msg, int len)
 {
   u32 a=0;
   while(*msg) { 
diff -ruPBb -x CVS linux/include/linux/reiserfs_fs.h 
tmp/reiserfs/linux-kernel//include/linux/reiserfs_fs.h
--- linux/include/linux/reiserfs_fs.h   Sat Jun 23 02:04:40 2001
+++ tmp/reiserfs/linux-kernel//include/linux/reiserfs_fs.h  Fri Jun 22 17:19:39 
+2001
@@ -2094,9 +2098,9 @@
 #endif
 
 /* hashes.c */
-__u32 keyed_hash (const char *msg, int len);
-__u32 yura_hash (const char *msg, int len);
-__u32 r5_hash (const char *msg, int len);
+__u32 keyed_hash (const unsigned char *msg, int len);
+__u32 yura_hash (const unsigned char *msg, int len);
+__u32 r5_hash (const unsigned char *msg, int len);
 
 /* version.c */
 char *reiserfs_get_version_string(void) ;
diff -ruPBb -x CVS linux/include/linux/reiserfs_fs_sb.h 
tmp/reiserfs/linux-kernel//include/linux/reiserfs_fs_sb.h
--- linux/include/linux/reiserfs_fs_sb.hSat Jun 23 02:04:40 2001
+++ tmp/reiserfs/linux-kernel//include/linux/reiserfs_fs_sb.h   Wed Jun 20 18:16:20 
+2001
@@ -316,7 +316,7 @@
 #define JOURNAL_DESC_MAGIC ReIsErLB /* ick.  magic string to find desc blocks in 
the journal */
 
 
-typedef __u32 (*hashf_t) (const char *, int);
+typedef __u32 (*hashf_t) (const unsigned char *, int);
 
 /* reiserfs union of in-core super block data */
 struct reiserfs_sb_info

 find-high-ascii.sh


Re: [reiserfs-list] kernel-2.4.6-pre3 to 2.2.19 NFS tests

2001-06-23 Thread Russell Coker

On Friday 22 June 2001 14:28, Christian Mayrhuber wrote:
  Try testing with Bonnie++, the file creation and deletion tests will
  give interesting results!  ;)
 
  In one test I had an AIX machine that was moderately grunty (two fast
  POWER CPU's, 6 hard drives on a 160MB/s bus, 256M of RAM).  When
  running Bonnie++ I found that the AIX machine could create files on
  my Thinkpad over a 10baseT NFS mount faster than it could create them
  on a local JFS file system!

 This is not the case for me, nfs performance never reaches local disk
 performance.

Of course not.  But ReiserFS on an NFS server can outperform local disks 
running other file systems.

 I think  the network is the limiting factor.
 I don't have a idea if the bonnie file creation numbers over nfs are
 good ones or not, at least stat seems to be speedy.


 1GHZ Athlon AMI Megaraid Raid-5 138GB/total, kernel-2.4.6-pre5, local,
 reiserfs
 Unknown,,30,14169,99,+,105,16224,91,13047,96,+,100,
14010,100

 1GHz Athlon, client, Raid-5 array mounted over a 100MBit/s network
 Unknown,,30,3578,30,13676,53,4682,33,3614,31,17797,49,4251,
29

Now try a local Ext2 file system and see if you get more than 200 files 
created per second.  Then try a local JFS file system on AIX and see if 
you can get more than 50 files created per second.  ;)

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page