rebuild-tree fails on large volume

rebuild-tree fails on large volume

[Carsten Ralle]

Hi,

on our 64bit RAID system reiserfsck segfaults (3.6.19) or stops (3.6.21)
reliably on Pass2 on a 12 TB volume.

On January 11th Jeff Mahoney posted a patch on this list fixing a couple
of type overflow errors on reiserfsck on large volumes which pretty much
sound like mine here.

http://www.spinics.net/lists/reiserfs-devel/msg02679.html

I looked all over the place but couldn't find any infos about the
version to patch.

Does anyone have the source code with these patches included or is there
an unknown test or release version having those patches included or does
anyone have any idea on how to fix this?

Sincerely,

Carsten



reiserfsck output (summary):
-------------------------------

reiserfsck 3.6.21
...
Pass 1 (will try to insert 2734366 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....100%                         left 0,
296 /sec
Flushing..finished
        2734366 leaves read
                2732070 inserted
                2296 not inserted
####### Pass 2 #######

Pass 2:
0%bread: Cannot read the block (18446744072362557648): (Invalid
argument). /sec
bread: Cannot read the block (18446744072362557649): (Invalid argument).
fix_node.c 838 are_items_mergeable
vs-16070: are_items_mergeable: left [1451761 1452800 0x1 DRCT (2)],
right [1128542 1128573 0x0 SD (0)]
Aborted


system info:
------------
Linux gate 2.6.37.6-0.7-xen #1 SMP 2011-07-21 02:17:24 +0200 x86_64
x86_64 x86_64 GNU/Linux

Re: rebuild-tree fails on large volume

[Christian Kujau]

On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
> 
> I looked all over the place but couldn't find any infos about the
> version to patch.

The patch applies cleanly to reiserfsprogs-3.6.21[0].

@Jeff: will the patch be applied to the next (?) reiserfsprogs release?

Thanks,
Christian.

[0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
-- 
BOFH excuse #57:

Groundskeepers stole the root password

Re: rebuild-tree fails on large volume

[Jeff Mahoney]

On 08/06/2011 02:47 AM, Christian Kujau wrote:
> On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>
>> I looked all over the place but couldn't find any infos about the
>> version to patch.
>
> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>
> @Jeff: will the patch be applied to the next (?) reiserfsprogs release?
>
> Thanks,
> Christian.
>
> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/

I don't actually maintain reiserfsprogs unless the openSUSE version has 
now become the official one. I've been meaning to get back to you about 
this but it's been a rough week.

-Jeff

-- 
Jeff Mahoney
SuSE Labs

Re: rebuild-tree fails on large volume

[Edward Shishkin]

On 08/06/2011 09:06 AM, Jeff Mahoney wrote:
> On 08/06/2011 02:47 AM, Christian Kujau wrote:
>> On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
>>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>>
>>> I looked all over the place but couldn't find any infos about the
>>> version to patch.
>>
>> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>>
>> @Jeff: will the patch be applied to the next (?) reiserfsprogs release?
>>
>> Thanks,
>> Christian.
>>
>> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
>
> I don't actually maintain reiserfsprogs unless the openSUSE version has
> now become the official one. I've been meaning to get back to you about
> this but it's been a rough week.


What's up Jeff? You are writing btrfsck? :)

Re: rebuild-tree fails on large volume

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/06/2011 04:09 AM, Edward Shishkin wrote:
> On 08/06/2011 09:06 AM, Jeff Mahoney wrote:
>> On 08/06/2011 02:47 AM, Christian Kujau wrote:
>>> On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
>>>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>>> 
>>>> I looked all over the place but couldn't find any infos about
>>>> the version to patch.
>>> 
>>> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>>> 
>>> @Jeff: will the patch be applied to the next (?) reiserfsprogs
>>> release?
>>> 
>>> Thanks, Christian.
>>> 
>>> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
>> 
>> I don't actually maintain reiserfsprogs unless the openSUSE version
>> has now become the official one. I've been meaning to get back to
>> you about this but it's been a rough week.
> 
> 
> What's up Jeff? You are writing btrfsck? :)

Hehe, nope. Not yet. I'm working on adding sane error handling to it.
BUG_ON doesn't work so well. :)

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5AQYsACgkQLPWxlyuTD7KfTQCfSdQuSbdPDZI/RggOlOv6Igi2
vpUAn0UFBRsCebtxG+fO6vcKSeX+/nBb
=tSbk
-----END PGP SIGNATURE-----

Re: rebuild-tree fails on large volume

[Jeff Mahoney]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/06/2011 03:06 AM, Jeff Mahoney wrote:
> On 08/06/2011 02:47 AM, Christian Kujau wrote:
>> On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
>>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>> 
>>> I looked all over the place but couldn't find any infos about
>>> the version to patch.
>> 
>> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>> 
>> @Jeff: will the patch be applied to the next (?) reiserfsprogs
>> release?
>> 
>> Thanks, Christian.
>> 
>> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
> 
> I don't actually maintain reiserfsprogs unless the openSUSE version
> has now become the official one. I've been meaning to get back to you
> about this but it's been a rough week.
> 
> -Jeff
> 

Attached is the patch I use for large file systems.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5AQVUACgkQLPWxlyuTD7LROQCffS1LS1x8XM+IWBKl8aTrmW6N
FAYAnRQraQEq2d+fHFo6yzHS5fxaQHFC
=jXCA
-----END PGP SIGNATURE-----

[-- Attachment #2: reiserfs-signedness-fixes --]
[-- Type: text/plain, Size: 13165 bytes --]

From: Jeff Mahoney <jeffm@suse.com>
Subject: [PATCH] reiserfs: Fix signedness issues for large file systems
References: bnc#701602


Signed-by: Jeff Mahoney <jeffm@suse.com>
---
 debugreiserfs/debugreiserfs.c |   22 +++++++++++-----------
 debugreiserfs/pack.c          |   18 +++++++++---------
 debugreiserfs/scan.c          |    2 +-
 debugreiserfs/stat.c          |    2 +-
 fsck/check_tree.c             |    6 +++---
 fsck/pass0.c                  |   10 +++++-----
 fsck/pass1.c                  |    4 ++--
 include/reiserfs_fs.h         |    2 ++
 lib/io.c                      |    2 +-
 reiserfscore/journal.c        |    2 +-
 reiserfscore/prints.c         |   14 +++++++-------
 reiserfscore/reiserfslib.c    |    5 +++--
 reiserfscore/stree.c          |    2 +-
 13 files changed, 47 insertions(+), 44 deletions(-)

--- a/debugreiserfs/debugreiserfs.c
+++ b/debugreiserfs/debugreiserfs.c
@@ -59,11 +59,11 @@ Options:\n\
 
 #if 1
 struct reiserfs_fsstat {
-    int nr_internals;
-    int nr_leaves;
-    int nr_files;
-    int nr_directories;
-    int nr_unformatted;
+    unsigned int nr_internals;
+    unsigned int nr_leaves;
+    unsigned int nr_files;
+    unsigned int nr_directories;
+    unsigned int nr_unformatted;
 } g_stat_info;
 #endif
 
@@ -465,14 +465,14 @@ static void init_bitmap (reiserfs_filsys
     case ALL_BLOCKS:
 	    input_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	    reiserfs_bitmap_fill (input_bitmap (fs));
-	    reiserfs_warning (stderr, "Whole device (%d blocks) is to be scanned\n", 
+	    reiserfs_warning (stderr, "Whole device (%u blocks) is to be scanned\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));	
 	    break;
     case USED_BLOCKS:
 	    reiserfs_warning (stderr, "Loading on-disk bitmap .. ");
 	    input_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	    reiserfs_bitmap_copy (input_bitmap (fs), fs->fs_bitmap2);
-	    reiserfs_warning (stderr, "%d bits set - done\n",
+	    reiserfs_warning (stderr, "%lu bits set - done\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));
 	    break;
     case UNUSED_BLOCKS:
@@ -480,7 +480,7 @@ static void init_bitmap (reiserfs_filsys
 	    input_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	    reiserfs_bitmap_copy (input_bitmap (fs), fs->fs_bitmap2);
 	    reiserfs_bitmap_invert (input_bitmap (fs));
-	    reiserfs_warning (stderr, "%d bits set - done\n",
+	    reiserfs_warning (stderr, "%lu bits set - done\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));
 	    break;
     case EXTERN_BITMAP:
@@ -494,7 +494,7 @@ static void init_bitmap (reiserfs_filsys
 		    reiserfs_exit (1, "could not load fitmap from \"%s\"", 
 				   input_bitmap_file_name(fs));
 	    }
-	    reiserfs_warning (stderr, "%d blocks marked in the given bitmap\n",
+	    reiserfs_warning (stderr, "%u blocks marked in the given bitmap\n",
 			      reiserfs_bitmap_ones (input_bitmap (fs)));
 	    fclose (fp);
 	    break;
@@ -554,8 +554,8 @@ static void do_dump_tree (reiserfs_filsy
 	    }
 
 	    /* print the statistic */
-	    printf ("\t%d internal + %d leaves + %d "
-		    "unformatted nodes = %d blocks\n", 
+	    printf ("\t%u internal + %u leaves + %u "
+		    "unformatted nodes = %u blocks\n",
 		    g_stat_info.nr_internals,   g_stat_info.nr_leaves, 
 		    g_stat_info.nr_unformatted, g_stat_info.nr_internals + 
 		    g_stat_info.nr_leaves + g_stat_info.nr_unformatted);
--- a/debugreiserfs/pack.c
+++ b/debugreiserfs/pack.c
@@ -8,7 +8,7 @@
 
 
 /* counters for each kind of blocks */
-int packed,
+unsigned int packed,
     packed_leaves,
     full_blocks,
     having_ih_array, /* blocks with broken block head */
@@ -638,7 +638,7 @@ static void pack_frozen_data (reiserfs_f
     }
     reiserfs_warning (stderr, "ok\n");fflush (stderr);
     reiserfs_warning (stderr, 
-		      "Super block, bitmaps, journal - %d blocks - done, %d blocks left\n",
+		      "Super block, bitmaps, journal - %u blocks - done, %u blocks left\n",
 		      packed, reiserfs_bitmap_ones (what_to_pack));
 }
 
@@ -693,13 +693,13 @@ void pack_partition (reiserfs_filsys_t *
     magic16 = END_MAGIC;
     fwrite_le16 (&magic16);
 
-    fprintf (stderr, "\nPacked %d blocks:\n"
-	     "\tcompessed %d\n"
-	     "\tfull blocks %d\n"
-	     "\t\tleaves with broken block head %d\n"
-	     "\t\tcorrupted leaves %d\n"
-	     "\t\tinternals %d\n"
-	     "\t\tdescriptors %d\n",
+    fprintf (stderr, "\nPacked %u blocks:\n"
+	     "\tcompessed %u\n"
+	     "\tfull blocks %u\n"
+	     "\t\tleaves with broken block head %u\n"
+	     "\t\tcorrupted leaves %u\n"
+	     "\t\tinternals %u\n"
+	     "\t\tdescriptors %u\n",
 	     packed,
 	     packed_leaves, full_blocks, having_ih_array,
 	     bad_leaves, internals, descs);
--- a/debugreiserfs/scan.c
+++ b/debugreiserfs/scan.c
@@ -1032,7 +1032,7 @@ void do_scan (reiserfs_filsys_t * fs)
     /* step 2: */
     done = 0;
     total = reiserfs_bitmap_ones (input_bitmap (fs));
-    printf ("%ld bits set in bitmap\n", total);
+    printf ("%lu bits set in bitmap\n", total);
     for (i = 0; i < get_sb_block_count (fs->fs_ondisk_sb); i ++) {
 	int type;
 	
--- a/debugreiserfs/stat.c
+++ b/debugreiserfs/stat.c
@@ -245,7 +245,7 @@ void do_stat (reiserfs_filsys_t * fs)
 	reiserfs_exit (1, "could not open %s to save bitmap: %m\n",
 		       input_bitmap_file_name(fs));
     }
-    reiserfs_warning (stderr, "Updated bitmap contains %d blocks marked\n",
+    reiserfs_warning (stderr, "Updated bitmap contains %u blocks marked\n",
 		      reiserfs_bitmap_ones (input_bitmap (fs)));
     
     reiserfs_bitmap_save (fp, input_bitmap (fs));
--- a/fsck/check_tree.c
+++ b/fsck/check_tree.c
@@ -119,7 +119,7 @@ static int is_block_free (reiserfs_filsy
 }
 
 
-/*static int hits = 0;*/
+/*static unsigned int hits = 0;*/
 
 /* we have seen this block in the tree, mark corresponding bit in the
    control bitmap */
@@ -156,7 +156,7 @@ static void init_control_bitmap (reiserf
     for (i = 0; i <= fs->fs_super_bh->b_blocknr; i ++)
     	we_met_it (i);
 
-    /*printf ("SKIPPED: %d blocks marked used (%d)\n", hits, 
+    /*printf ("SKIPPED: %u blocks marked used (%d)\n", hits,
               reiserfs_bitmap_zeros (control_bitmap));
       hits = 0;*/
 
@@ -172,7 +172,7 @@ static void init_control_bitmap (reiserf
 	    block ++;	
     }
     
-    /*printf ("BITMAPS: %d blocks marked used (%d)\n", hits, 
+    /*printf ("BITMAPS: %u blocks marked used (%d)\n", hits,
 	      reiserfs_bitmap_zeros (control_bitmap));
 	      
       hits = 0;*/
--- a/fsck/pass0.c
+++ b/fsck/pass0.c
@@ -1759,7 +1759,7 @@ static void init_source_bitmap (reiserfs
     case ALL_BLOCKS:
 	fsck_source_bitmap (fs) = reiserfs_create_bitmap (block_count);
 	reiserfs_bitmap_fill (fsck_source_bitmap (fs));
-	fsck_progress ("The whole partition (%d blocks) is to be scanned\n", 
+	fsck_progress ("The whole partition (%u blocks) is to be scanned\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));	
 	break;
 
@@ -1768,7 +1768,7 @@ static void init_source_bitmap (reiserfs
 	fsck_source_bitmap (fs) = reiserfs_create_bitmap (block_count);	
 	reiserfs_bitmap_copy (fsck_source_bitmap (fs), fs->fs_bitmap2);
 	
-	fsck_progress ("ok, %d blocks marked used\n", 
+	fsck_progress ("ok, %u blocks marked used\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));
 	break;
 
@@ -1787,7 +1787,7 @@ static void init_source_bitmap (reiserfs
 			   fsck_data (fs)->rebuild.bitmap_file_name);
 	}
 
-	fsck_progress ("%d blocks marked used in extern bitmap\n", 
+	fsck_progress ("%u blocks marked used in extern bitmap\n",
 		       reiserfs_bitmap_ones (fsck_source_bitmap (fs)));
 	fclose (fp);
 	break;
@@ -1863,8 +1863,8 @@ static void init_source_bitmap (reiserfs
 
     fsck_source_bitmap (fs)->bm_set_bits = reiserfs_bitmap_ones (fsck_source_bitmap (fs));
 
-    fsck_progress ("Skipping %d blocks (super block, journal, "
-		   "bitmaps) %d blocks will be read\n", tmp, fsck_source_bitmap (fs)->bm_set_bits);
+    fsck_progress ("Skipping %u blocks (super block, journal, "
+		   "bitmaps) %u blocks will be read\n", tmp, fsck_source_bitmap (fs)->bm_set_bits);
 		
 }
 
--- a/fsck/pass1.c
+++ b/fsck/pass1.c
@@ -646,8 +646,8 @@ void load_pass_1_result (FILE * fp, reis
     fetch_objectid_map (proper_id_map (fs), fs);
     */
 
-    fsck_progress ("Pass 1 result loaded. %d blocks used, %d allocable, "
-		   "still to be inserted %d\n",
+    fsck_progress ("Pass 1 result loaded. %u blocks used, %u allocable, "
+		   "still to be inserted %u\n",
 		   reiserfs_bitmap_ones (fsck_new_bitmap (fs)),
 		   reiserfs_bitmap_zeros (fsck_allocable_bitmap (fs)),
 		   reiserfs_bitmap_zeros (fsck_uninsertables (fs)));
--- a/include/reiserfs_fs.h
+++ b/include/reiserfs_fs.h
@@ -32,6 +32,8 @@
 #ifndef REISERFSPROGS_FS_H
 #define REISERFSPRIGS_FS_H 
 
+typedef unsigned int blocknr_t;
+
 #ifndef NO_EXTERN_INLINE
 # define extern_inline extern inline
 #else
--- a/lib/io.c
+++ b/lib/io.c
@@ -628,7 +628,7 @@ void close_rollback_file () {
             return;
         fwrite (&rollback_blocks_number, sizeof (rollback_blocksize), 1, s_rollback_file);
         if (log_file != 0) 
-            fprintf (log_file, "rollback: %d blocks backed up\n", rollback_blocks_number);
+            fprintf (log_file, "rollback: %u blocks backed up\n", rollback_blocks_number);
     }
         
     fclose (s_rollback_file);
--- a/reiserfscore/journal.c
+++ b/reiserfscore/journal.c
@@ -577,7 +577,7 @@ int reiserfs_create_journal(
 	{
 	    /* host device does not contain enough blocks */
 	    reiserfs_warning (stderr, "reiserfs_create_journal: cannot create "
-		"a journal of %lu blocks with %lu offset on %d blocks\n", 
+		"a journal of %lu blocks with %lu offset on %u blocks\n",
 		len, offset, get_sb_block_count(sb));
 		return 0;
 	}
--- a/reiserfscore/prints.c
+++ b/reiserfscore/prints.c
@@ -148,7 +148,7 @@ static int print_disk_child (FILE * stre
     int len;
 
     dc = *((const struct disk_child **)(args[0]));
-    len = asprintf (&buffer, "[dc_number=%u, dc_size=%u]", get_dc_child_blocknr (dc),
+    len = asprintf (&buffer, "[dc_number=%lu, dc_size=%u]", get_dc_child_blocknr (dc),
 		    get_dc_child_size (dc));
     FPRINTF;
 }
@@ -373,9 +373,9 @@ static void print_sequence (FILE * fp, _
 	return;
 
     if (len == 1)
-	reiserfs_warning (fp, " %d", le32_to_cpu (start));
+	reiserfs_warning (fp, " %u", le32_to_cpu (start));
     else
-	reiserfs_warning (fp, " %d(%d)", le32_to_cpu (start), len);
+	reiserfs_warning (fp, " %u(%d)", le32_to_cpu (start), len);
 }
 
 
@@ -491,7 +491,7 @@ static int print_internal (FILE * fp, st
 	to = last < B_NR_ITEMS (bh) ? last : B_NR_ITEMS (bh);
     }
 
-    reiserfs_warning (fp, "INTERNAL NODE (%ld) contains %b\n",  bh->b_blocknr, bh);
+    reiserfs_warning (fp, "INTERNAL NODE (%lu) contains %b\n",  bh->b_blocknr, bh);
 
     dc = B_N_CHILD (bh, from);
     reiserfs_warning (fp, "PTR %d: %y ", from, dc);
@@ -527,7 +527,7 @@ static int print_leaf (FILE * fp, reiser
 
     reiserfs_warning (fp,
 		      "\n===================================================================\n");
-    reiserfs_warning (fp, "LEAF NODE (%ld) contains %b (real items %d)\n",
+    reiserfs_warning (fp, "LEAF NODE (%lu) contains %b (real items %d)\n",
 		      bh->b_blocknr, bh, real_nr);
 
     if (!(print_mode & PRINT_TREE_DETAILS)) {
@@ -761,7 +761,7 @@ void print_block (FILE * fp, reiserfs_fi
         if (print_super_block (fp, fs, file_name, bh, 0))
 	    if (print_leaf (fp, fs, bh, mode, first, last))
 		if (print_internal (fp, bh, first, last))
-		    reiserfs_warning (fp, "Block %ld contains unformatted data\n", bh->b_blocknr);
+		    reiserfs_warning (fp, "Block %lu contains unformatted data\n", bh->b_blocknr);
 }
 
 
@@ -797,7 +797,7 @@ void print_tb (int mode, int item_pos, i
       tbSh = 0;
       tbFh = 0;
     }
-    printf ("* %u * %3lu(%2lu) * %3lu(%2lu) * %3lu(%2lu) * %5ld * %5ld * %5ld * %5ld * %5ld *\n",
+    printf ("* %u * %3lu(%2lu) * %3lu(%2lu) * %3lu(%2lu) * %5lu * %5lu * %5lu * %5lu * %5lu *\n",
 	    h, 
 	    tbSh ? tbSh->b_blocknr : ~0ul,
 	    tbSh ? tbSh->b_count : ~0ul,
--- a/reiserfscore/reiserfslib.c
+++ b/reiserfscore/reiserfslib.c
@@ -59,7 +59,8 @@ reiserfs_filsys_t * reiserfs_open (char
     reiserfs_filsys_t * fs;
     struct buffer_head * bh;
     struct reiserfs_super_block * sb;
-    int fd, i;
+    int fd;
+    unsigned int i;
 
     /* convert root dir key and parent root dir key to little endian format */
     make_const_keys ();
@@ -200,7 +201,7 @@ reiserfs_filsys_t * reiserfs_create (cha
 	block_size, block_count, 0)) 
     {
 	reiserfs_warning (stderr, "reiserfs_create: can not create that small "
-	    "(%d blocks) filesystem\n", block_count);
+	    "(%u blocks) filesystem\n", block_count);
 	return 0;
     }
 
--- a/reiserfscore/stree.c
+++ b/reiserfscore/stree.c
@@ -313,7 +313,7 @@ int search_by_key (reiserfs_filsys_t * f
 		   int  n_stop_level)   /* How far down the tree to search.*/
 {
     struct reiserfs_super_block * sb;
-    int n_block_number,
+    unsigned int n_block_number,
 	expected_level,
 	n_block_size    = fs->fs_blocksize;
     struct buffer_head  *       p_s_bh;

Re: rebuild-tree fails on large volume

[Edward Shishkin]

On 08/08/2011 10:04 PM, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/06/2011 03:06 AM, Jeff Mahoney wrote:
>> On 08/06/2011 02:47 AM, Christian Kujau wrote:
>>> On Thu, 4 Aug 2011 at 12:49, Carsten Ralle wrote:
>>>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>>>
>>>> I looked all over the place but couldn't find any infos about
>>>> the version to patch.
>>>
>>> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>>>
>>> @Jeff: will the patch be applied to the next (?) reiserfsprogs
>>> release?
>>>
>>> Thanks, Christian.
>>>
>>> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
>>
>> I don't actually maintain reiserfsprogs unless the openSUSE version
>> has now become the official one. I've been meaning to get back to you
>> about this but it's been a rough week.
>>
>> -Jeff
>>
>
> Attached is the patch I use for large file systems.


Great.
It seems we'll release 3.6.22 near Christmas.
I also have something to push to reiser4progs...

Thanks,
Edward.

Re: rebuild-tree fails on large volume

[Carsten Ralle]

>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>> I looked all over the place but couldn't find any infos about the
>> version to patch.
> The patch applies cleanly to reiserfsprogs-3.6.21[0].
> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
many thanks to all of you: the rebuild-tree (3.6.21-0 + your patch)
finished this morning and everything looks OK so far, but it'll take a
while to check all of the data.

Imho the patch should be included as soon as possible to the official
OpenSuSE reiserfsprogs tree as there still are a lot of people running
large volumes on ReiserFS v3.6.

Thanks again,

Carsten

-- 
--------------------------------------------------
Yoo GmbH                       Tel.: 037328 809 40
Zellwaldring 51                Fax : 037328 809 96
D-09603 Grossvoigtsberg
Germany                             www.yoogmbh.de
Registereintrag: Amtsgericht Chemnitz, HRB 181 852
Geschäftsführung: Carsten Ralle
--------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rebuild-tree fails on large volume

[Christian Stroetmann]

On the 09.08.2011 19:01, Carsten Ralle wrote:
>>> http://www.spinics.net/lists/reiserfs-devel/msg02679.html
>>> I looked all over the place but couldn't find any infos about the
>>> version to patch.
>> The patch applies cleanly to reiserfsprogs-3.6.21[0].
>> [0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/
> many thanks to all of you: the rebuild-tree (3.6.21-0 + your patch)
> finished this morning and everything looks OK so far, but it'll take a
> while to check all of the data.
>
> Imho the patch should be included as soon as possible to the official
> OpenSuSE reiserfsprogs tree as there still are a lot of people running
> large volumes on ReiserFS v3.6.

We can't follow this argumentation unless it is a special patch for a 
special Linux distribution. But as far as we have followed the 
communication it is a patch that applies in general, and if this is the 
case, then other persons are also interested in this patch. So, we do 
think that it should go to the place where it belongs which is actually [0].

[0] https://www.kernel.org/pub/linux/utils/fs/reiserfs/

Besides this, stop advertising, please. Thanks.

Have fun
Christian *<:o)   O>-<    -(D)>-<

Re: rebuild-tree fails on large volume

[Carsten Ralle]

Am 10.08.2011 03:48, schrieb Christian Stroetmann:

> Besides this, stop advertising, please. Thanks.
Which of my 3 messages on this thread did you consider 'advertising' ??

Carsten

Any news on reiser4 status or where its all at ?

[doiggl]

Hello,
Any news on reiser4 status or where its all at ?
Thanks Glenn

Re: Any news on reiser4 status or where its all at ?

[Edward Shishkin]

On 09/07/2011 08:24 AM, doiggl@velocitynet.com.au wrote:
> Hello,
> Any news on reiser4 status or where its all at ?


You are pretty aware of its status.
I'll report as soon as I have any updates on reiser4.

Thanks,
Edward.

Re: Any news on reiser4 status or where its all at ?

[Christian Stroetmann]

On the 07.09.2011 08:24, doiggl@velocitynet.com.au wrote:
> Hello,
> Any news on reiser4 status or where its all at ?
> Thanks Glenn

You are suspiciously pretty aware of its status. Is there a client?

Christian Stroetmann

Re: Any news on reiser4 status or where its all at ?

[Arend Freije]

Christian Stroetmann wrote:
> On the 07.09.2011 08:24, doiggl@velocitynet.com.au wrote:
>> Hello,
>> Any news on reiser4 status or where its all at ?
>> Thanks Glenn
>
> You are suspiciously pretty aware of its status. Is there a client?
>
> Christian Stroetmann

Dear Christian,

Most of your comments are totally worthless and do not help the 
community, and that's quite annoying. I'll add your email address to the 
Junk filter.
I wish you a good life, preferably in a remote area.

Arend

Re: Any news on reiser4 status or where its all at ?

[Christian Stroetmann]

On the 08.09.2011 07:50, Arend Freije wrote:
>
> Christian Stroetmann wrote:
>> On the 07.09.2011 08:24, doiggl@velocitynet.com.au wrote:
>>> Hello,
>>> Any news on reiser4 status or where its all at ?
>>> Thanks Glenn
>>
>> You are suspiciously pretty aware of its status. Is there a client?
>>
>> Christian Stroetmann
>
> Dear Christian,
>
> Most of your comments are totally worthless and do not help the 
> community, and that's quite annoying. I'll add your email address to 
> the Junk filter.
> I wish you a good life, preferably in a remote area.
>
> Arend
>

Why is Mr. Freije so offending?
We don't know what he wants to say us and perhaps others.
All what we do or ask is community related and doubtlessly helps the 
community:
We informed how we use the R4 fs.
We made suggestions how to bring the project further.
We offered our help and support.
We busted persons, who in fact have tried to damage the project and the 
community massively.
We informed about infringements of copyrights.
We informed about persons who tried to damage the project by playing foul.
We asked about how we could buy Namesys to bring the project back on track.
We asked for stopping advertisement.
AND IN THIS CASE WE HAVE SIMPLY REPEATED THE SENTENCE THAT THE 
MAINTAINER SAID YESTERDAY BY ADDING THE WORD suspiciously, BECAUSE WE 
WOULD LIKE TO KNOW MORE ABOUT THE GOALS BY ONE OF THE LAST ACTIVE 
MAILING-LIST SUBSCRIBERS.

We don't know who Mr. Freije is.
Maybe he mailed four years ago a message.
But we are sure that so far he posted no concepts, descriptions, help, 
code, patch or something that is community related at all.

Furthermore, we thank Mr.Freije for his kind wish of having a good life, 
while assuring everybody else that it won't be in a remote area.

Last but not least:
Thank you very much for showing the community you real nature, because 
this is exactly what we want to find out as part of the community work. 
Said this, from our point of view Mr. Freije is definitely not able to 
work in a team.
Please Mr. Freije, stop messing up with community members.


Thanks
C. Stroetmann

Re: Any news on reiser4 status or where its all at ?

[Christian Stroetmann]

On the 08.09.2011 10:09, Christian Stroetmann wrote:
> On the 08.09.2011 07:50, Arend Freije wrote:
>>
>> Christian Stroetmann wrote:
>>> On the 07.09.2011 08:24, doiggl@velocitynet.com.au wrote:
>>>> Hello,
>>>> Any news on reiser4 status or where its all at ?
>>>> Thanks Glenn
>>>
>>> You are suspiciously pretty aware of its status. Is there a client?
>>>
>>> Christian Stroetmann
>>
>> Dear Christian,
>>
>> Most of your comments are totally worthless and do not help the 
>> community, and that's quite annoying. I'll add your email address to 
>> the Junk filter.
>> I wish you a good life, preferably in a remote area.
>>
>> Arend
>>
>
> Why is Mr. Freije so offending?
> We don't know what he wants to say us and perhaps others.
> All what we do or ask is community related and doubtlessly helps the 
> community:
> We informed how we use the R4 fs.
> We made suggestions how to bring the project further.
> We offered our help and support.
> We busted persons, who in fact have tried to damage the project and 
> the community massively.
> We informed about infringements of copyrights.
> We informed about persons who tried to damage the project by playing 
> foul.
> We asked about how we could buy Namesys to bring the project back on 
> track.
> We asked for stopping advertisement.
> AND IN THIS CASE WE HAVE SIMPLY REPEATED THE SENTENCE THAT THE 
> MAINTAINER SAID YESTERDAY BY ADDING THE WORD suspiciously, BECAUSE WE 
> WOULD LIKE TO KNOW MORE ABOUT THE GOALS BY ONE OF THE LAST ACTIVE 
> MAILING-LIST SUBSCRIBERS.
>
> We don't know who Mr. Freije is.
> Maybe he mailed four years ago a message.
> But we are sure that so far he posted no concepts, descriptions, help, 
> code, patch or something that is community related at all.

Sorry, we have to correct our statement. In fact, we found 5 messages:

12th December 2008:
One was about a compiled kernel.
The next one was something that he now calls annoying himself.

4th April 2009:
This was again a comment on the same level as our message.

25th of April 2009:
Ask in a offending way where our fork is.

1st of July 2009:
He gave informations how to use R4 with Grub, which from our point of 
view could be easily found in the web by searching.

>
>
> Furthermore, we thank Mr.Freije for his kind wish of having a good 
> life, while assuring everybody else that it won't be in a remote area.
>
> Last but not least:
> Thank you very much for showing the community you real nature, because 
> this is exactly what we want to find out as part of the community 
> work. Said this, from our point of view Mr. Freije is definitely not 
> able to work in a team.
> Please Mr. Freije, stop messing up with community members.
>
>
> Thanks
> C. Stroetmann
>

We do apologize for our mistake.

Have fun
C. Stroetmann

Re: Any news on reiser4 status or where its all at ?

[Edward Shishkin]

On 09/08/2011 07:50 AM, Arend Freije wrote:
>
> Christian Stroetmann wrote:
>> On the 07.09.2011 08:24, doiggl@velocitynet.com.au wrote:
>>> Hello,
>>> Any news on reiser4 status or where its all at ?
>>> Thanks Glenn
>>
>> You are suspiciously pretty aware of its status. Is there a client?
>>
>> Christian Stroetmann
>
> Dear Christian,
>
> Most of your comments are totally worthless and do not help the
> community, and that's quite annoying. I'll add your email address to the
> Junk filter.


Good idea. I have done so 4 years ago.

Thanks,
Edward.


> I wish you a good life, preferably in a remote area.
>
> Arend
> --
> To unsubscribe from this list: send the line "unsubscribe
> reiserfs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html