Horrible ftruncate performance

Horrible ftruncate performance

[Szakacsits Szabolcs]

Hi,

I've noticed very long "hangs" using reiserfs and they were always at
ftruncate(2). I made a comparision between different filesystems. SuSE 8.2
(same bad performance on older SuSE versions as well), same partitition,
default mkfs.*. Let's create a 200GB sparse file:

	dd if=/dev/zero of=sparse bs=1 seek=200G count=1

Results:
	ext3	    0.00 sec
	XFS         0.00 sec
	JFS         0.00 sec
	reiserfs  874.27 sec (all spent in the kernel)

I also created a 2TB sparse file with the other filesystems and the results
were still unmeasurable. However it would have taken 10x more time for
reiserfs because as I noticed the time spent in ftruncate is linear to the
length the file to be truncated.

Is there a faster way to create big sparse files on reiserfs?

	Szaka

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 05:23:39AM +0200, Szakacsits Szabolcs wrote:

> I've noticed very long "hangs" using reiserfs and they were always at
> ftruncate(2). I made a comparision between different filesystems. SuSE 8.2

Yes, this is known "feature".

> (same bad performance on older SuSE versions as well), same partitition,
> default mkfs.*. Let's create a 200GB sparse file:
> 	dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> Results:
> 	ext3	    0.00 sec
> 	XFS         0.00 sec
> 	JFS         0.00 sec
> 	reiserfs  874.27 sec (all spent in the kernel)

See the patch below.
It is merged into 2.4.22-pre3
Speeds up large holes creation in ~ 1000 times (on 4k blocksize)

> Is there a faster way to create big sparse files on reiserfs?

Use the patch. (should apply to 2.4.18,2.4.19,2.4.20,2.4.21)
(I am unsure if you can apply it to the kernel from SuSE 8.2, though).

Bye,
    Oleg
===== fs/reiserfs/do_balan.c 1.12 vs edited =====
--- 1.12/fs/reiserfs/do_balan.c	Thu Sep 12 12:39:21 2002
+++ edited/fs/reiserfs/do_balan.c	Tue Jun 17 19:13:06 2003
@@ -304,8 +304,6 @@
 		    int new_item_len;
 		    int version;
 
-		    RFALSE (!is_direct_le_ih (ih),
-			    "PAP-12075: only direct inserted item can be broken. %h", ih);
 		    ret_val = leaf_shift_left (tb, tb->lnum[0]-1, -1);
 
 		    /* Calculate item length to insert to S[0] */
@@ -328,7 +326,7 @@
 		    version = ih_version (ih);
 
 		    /* Calculate key component, item length and body to insert into S[0] */
-                    set_le_ih_k_offset( ih, le_ih_k_offset( ih ) + tb->lbytes );
+                    set_le_ih_k_offset( ih, le_ih_k_offset( ih ) + (tb->lbytes << (is_indirect_le_ih(ih)?tb->tb_sb->s_blocksize_bits-UNFM_P_SHIFT:0)) );
 
 		    put_ih_item_len( ih, new_item_len );
 		    if ( tb->lbytes >  zeros_num ) {
@@ -437,23 +435,28 @@
 				ih_item_len( B_N_PITEM_HEAD(tb->L[0],n+item_pos-ret_val)),
 				l_n,body, zeros_num > l_n ? l_n : zeros_num
 				);
-
-			    RFALSE( l_n && 
-				    is_indirect_le_ih(B_N_PITEM_HEAD
-						      (tb->L[0],
-						       n + item_pos - ret_val)),
-				    "PAP-12110: pasting more than 1 unformatted node pointer into indirect item");
-
 			    /* 0-th item in S0 can be only of DIRECT type when l_n != 0*/
 			    {
-			      int version;
-
-			      version = ih_version (B_N_PITEM_HEAD (tbS0, 0));
-			      set_le_key_k_offset (version, B_N_PKEY (tbS0, 0), 
-						   le_key_k_offset (version, B_N_PKEY (tbS0, 0)) + l_n);
-			      version = ih_version (B_N_PITEM_HEAD(tb->CFL[0],tb->lkey[0]));
-			      set_le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFL[0],tb->lkey[0]),
-						   le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFL[0],tb->lkey[0])) + l_n);
+				int version;
+				int temp_l = l_n;
+				
+				RFALSE (ih_item_len (B_N_PITEM_HEAD (tbS0, 0)),
+					"PAP-12106: item length must be 0");
+				RFALSE (comp_short_le_keys (B_N_PKEY (tbS0, 0),
+							    B_N_PKEY (tb->L[0],
+									    n + item_pos - ret_val)),
+					"PAP-12107: items must be of the same file");
+				if (is_indirect_le_ih(B_N_PITEM_HEAD (tb->L[0],
+								      n + item_pos - ret_val)))	{
+				    temp_l = l_n << (tb->tb_sb->s_blocksize_bits - UNFM_P_SHIFT);
+				}
+				/* update key of first item in S0 */
+				version = ih_version (B_N_PITEM_HEAD (tbS0, 0));
+				set_le_key_k_offset (version, B_N_PKEY (tbS0, 0), 
+						     le_key_k_offset (version, B_N_PKEY (tbS0, 0)) + temp_l);
+				/* update left delimiting key */
+				set_le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFL[0],tb->lkey[0]),
+						     le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFL[0],tb->lkey[0])) + temp_l);
 			    }
 
 			    /* Calculate new body, position in item and insert_size[0] */
@@ -522,7 +525,7 @@
 			    );
 		    /* if appended item is indirect item, put unformatted node into un list */
 		    if (is_indirect_le_ih (pasted))
-			set_ih_free_space (pasted, ((struct unfm_nodeinfo*)body)->unfm_freespace);
+			set_ih_free_space (pasted, 0);
 		    tb->insert_size[0] = 0;
 		    zeros_num = 0;
 		}
@@ -550,15 +553,11 @@
 	    { /* new item or its part falls to R[0] */
 		if ( item_pos == n - tb->rnum[0] + 1 && tb->rbytes != -1 )
 		{ /* part of new item falls into R[0] */
-		    int old_key_comp, old_len, r_zeros_number;
+		    loff_t old_key_comp, old_len, r_zeros_number;
 		    const char * r_body;
 		    int version;
 		    loff_t offset;
 
-		    RFALSE( !is_direct_le_ih (ih),
-			    "PAP-12135: only direct item can be split. (%h)", 
-			    ih);
-
 		    leaf_shift_right(tb,tb->rnum[0]-1,-1);
 
 		    version = ih_version(ih);
@@ -567,7 +566,7 @@
 		    old_len = ih_item_len(ih);
 
 		    /* Calculate key component and item length to insert into R[0] */
-                    offset = le_ih_k_offset( ih ) + (old_len - tb->rbytes );
+                    offset = le_ih_k_offset( ih ) + ((old_len - tb->rbytes )<<(is_indirect_le_ih(ih)?tb->tb_sb->s_blocksize_bits-UNFM_P_SHIFT:0));
                     set_le_ih_k_offset( ih, offset );
 		    put_ih_item_len( ih, tb->rbytes);
 		    /* Insert part of the item into R[0] */
@@ -575,13 +574,13 @@
 		    bi.bi_bh = tb->R[0];
 		    bi.bi_parent = tb->FR[0];
 		    bi.bi_position = get_right_neighbor_position (tb, 0);
-		    if ( offset - old_key_comp > zeros_num ) {
+		    if ( (old_len - tb->rbytes) > zeros_num ) {
 			r_zeros_number = 0;
-			r_body = body + offset - old_key_comp - zeros_num;
+			r_body = body + (old_len - tb->rbytes) - zeros_num;
 		    }
 		    else {
 			r_body = body;
-			r_zeros_number = zeros_num - (offset - old_key_comp);
+			r_zeros_number = zeros_num - (old_len - tb->rbytes);
 			zeros_num -= r_zeros_number;
 		    }
 
@@ -692,12 +691,17 @@
 			
 			{
 			  int version;
+			  unsigned long temp_rem = n_rem;
 			  
 			  version = ih_version (B_N_PITEM_HEAD (tb->R[0],0));
+			  if (is_indirect_le_key(version,B_N_PKEY(tb->R[0],0))){
+			      temp_rem = n_rem << (tb->tb_sb->s_blocksize_bits -
+			                 UNFM_P_SHIFT);
+			  }
 			  set_le_key_k_offset (version, B_N_PKEY(tb->R[0],0), 
-					       le_key_k_offset (version, B_N_PKEY(tb->R[0],0)) + n_rem);
+					       le_key_k_offset (version, B_N_PKEY(tb->R[0],0)) + temp_rem);
 			  set_le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFR[0],tb->rkey[0]), 
-					       le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFR[0],tb->rkey[0])) + n_rem);
+					       le_key_k_offset (version, B_N_PDELIM_KEY(tb->CFR[0],tb->rkey[0])) + temp_rem);
 			}
 /*		  k_offset (B_N_PKEY(tb->R[0],0)) += n_rem;
 		  k_offset (B_N_PDELIM_KEY(tb->CFR[0],tb->rkey[0])) += n_rem;*/
@@ -721,13 +725,12 @@
 			leaf_paste_in_buffer(&bi, 0, n_shift, tb->insert_size[0] - n_rem, r_body, r_zeros_number);
 
 			if (is_indirect_le_ih (B_N_PITEM_HEAD(tb->R[0],0))) {
-
+#if 0
 			    RFALSE( n_rem,
 				    "PAP-12160: paste more than one unformatted node pointer");
-
-			    set_ih_free_space (B_N_PITEM_HEAD(tb->R[0],0), ((struct unfm_nodeinfo*)body)->unfm_freespace);
+#endif
+			    set_ih_free_space (B_N_PITEM_HEAD(tb->R[0],0), 0);
 			}
-
 			tb->insert_size[0] = n_rem;
 			if ( ! n_rem )
 			    pos_in_item ++;
@@ -766,7 +769,7 @@
 		    }
 
 		    if (is_indirect_le_ih (pasted))
-			set_ih_free_space (pasted, ((struct unfm_nodeinfo*)body)->unfm_freespace);
+			set_ih_free_space (pasted, 0);
 		    zeros_num = tb->insert_size[0] = 0;
 		}
 	    }
@@ -843,12 +846,6 @@
 		    const char * r_body;
 		    int version;
 
-		    RFALSE( !is_direct_le_ih(ih),
-			/* The items which can be inserted are:
-			   Stat_data item, direct item, indirect item and directory item which consist of only two entries "." and "..".
-			   These items must not be broken except for a direct one. */
-			    "PAP-12205: non-direct item can not be broken when inserting");
-
 		    /* Move snum[i]-1 items from S[0] to S_new[i] */
 		    leaf_move_items (LEAF_FROM_S_TO_SNEW, tb, snum[i] - 1, -1, S_new[i]);
 		    /* Remember key component and item length */
@@ -858,7 +855,7 @@
 
 		    /* Calculate key component and item length to insert into S_new[i] */
                     set_le_ih_k_offset( ih,
-                                le_ih_k_offset(ih) + (old_len - sbytes[i] ) );
+                                le_ih_k_offset(ih) + ((old_len - sbytes[i] )<<(is_indirect_le_ih(ih)?tb->tb_sb->s_blocksize_bits-UNFM_P_SHIFT:0) ));
 
 		    put_ih_item_len( ih, sbytes[i] );
 
@@ -868,13 +865,13 @@
 		    bi.bi_parent = 0;
 		    bi.bi_position = 0;
 
-		    if ( le_ih_k_offset (ih) - old_key_comp > zeros_num ) {
+		    if ( (old_len - sbytes[i]) > zeros_num ) {
 			r_zeros_number = 0;
-			r_body = body + (le_ih_k_offset(ih) - old_key_comp) - zeros_num;
+			r_body = body + (old_len - sbytes[i]) - zeros_num;
 		    }
 		    else {
 			r_body = body;
-			r_zeros_number = zeros_num - (le_ih_k_offset (ih) - old_key_comp);
+			r_zeros_number = zeros_num - (old_len - sbytes[i]);
 			zeros_num -= r_zeros_number;
 		    }
 
@@ -995,11 +992,14 @@
 
 			    tmp = B_N_PITEM_HEAD(S_new[i],0);
 			    if (is_indirect_le_ih (tmp)) {
-				if (n_rem)
-				    reiserfs_panic (tb->tb_sb, "PAP-12230: balance_leaf: invalid action with indirect item");
-				set_ih_free_space (tmp, ((struct unfm_nodeinfo*)body)->unfm_freespace);
+				set_ih_free_space (tmp, 0);
+				set_le_ih_k_offset( tmp, le_ih_k_offset(tmp) + 
+					            (n_rem << (tb->tb_sb->s_blocksize_bits -
+						     UNFM_P_SHIFT)));
+			    } else {
+				set_le_ih_k_offset( tmp, le_ih_k_offset(tmp) + 
+				                    n_rem );
 			    }
-                            set_le_ih_k_offset( tmp, le_ih_k_offset(tmp) + n_rem );
 			}
 
 			tb->insert_size[0] = n_rem;
@@ -1045,7 +1045,7 @@
 
 		    /* if we paste to indirect item update ih_free_space */
 		    if (is_indirect_le_ih (pasted))
-			set_ih_free_space (pasted, ((struct unfm_nodeinfo*)body)->unfm_freespace);
+			set_ih_free_space (pasted, 0);
 		    zeros_num = tb->insert_size[0] = 0;
 		}
 	    }
@@ -1141,11 +1141,12 @@
 		    leaf_paste_in_buffer (&bi, item_pos, pos_in_item, tb->insert_size[0], body, zeros_num);
 
 		    if (is_indirect_le_ih (pasted)) {
-
+#if 0
 			RFALSE( tb->insert_size[0] != UNFM_P_SIZE,
 				"PAP-12280: insert_size for indirect item must be %d, not %d",
 				UNFM_P_SIZE, tb->insert_size[0]);
-			set_ih_free_space (pasted, ((struct unfm_nodeinfo*)body)->unfm_freespace);
+#endif
+			set_ih_free_space (pasted, 0);
 		    }
 		    tb->insert_size[0] = 0;
 		}
===== fs/reiserfs/inode.c 1.45 vs edited =====
--- 1.45/fs/reiserfs/inode.c	Fri May 23 00:35:02 2003
+++ edited/fs/reiserfs/inode.c	Tue Jun 17 19:11:38 2003
@@ -798,7 +798,11 @@
 	       pointer to 'block'-th block use block, which is already
 	       allocated */
 	    struct cpu_key tmp_key;
-	    struct unfm_nodeinfo un = {0, 0};
+	    unp_t unf_single=0; // We use this in case we need to allocate only
+				// one block which is a fastpath
+	    unp_t *un;
+	    __u64 max_to_insert=MAX_ITEM_LEN(inode->i_sb->s_blocksize)/UNFM_P_SIZE;
+	    __u64 blocks_needed;
 
 	    RFALSE( pos_in_item != ih_item_len(ih) / UNFM_P_SIZE,
 		    "vs-804: invalid position for append");
@@ -807,30 +811,58 @@
 			  le_key_k_offset (version, &(ih->ih_key)) + op_bytes_number (ih, inode->i_sb->s_blocksize),
 			  //pos_in_item * inode->i_sb->s_blocksize,
 			  TYPE_INDIRECT, 3);// key type is unimportant
-		  
-	    if (cpu_key_k_offset (&tmp_key) == cpu_key_k_offset (&key)) {
+
+	    blocks_needed = 1 + ((cpu_key_k_offset (&key) - cpu_key_k_offset (&tmp_key)) >> inode->i_sb->s_blocksize_bits);
+	    RFALSE( blocks_needed < 0, "green-805: invalid offset");
+
+	    if ( blocks_needed == 1 ) {
+		un = &unf_single;
+	    } else {
+		un=kmalloc( min(blocks_needed,max_to_insert)*UNFM_P_SIZE,
+			    GFP_ATOMIC); // We need to avoid scheduling.
+		if ( !un) {
+		    un = &unf_single;
+		    blocks_needed = 1;
+		    max_to_insert = 0;
+		} else
+		    memset(un, 0, UNFM_P_SIZE * min(blocks_needed,max_to_insert));
+	    }
+	    if ( blocks_needed <= max_to_insert) {
 		/* we are going to add target block to the file. Use allocated
 		   block for that */
-		un.unfm_nodenum = cpu_to_le32 (allocated_block_nr);
+		un[blocks_needed-1] = cpu_to_le32 (allocated_block_nr);
 		set_block_dev_mapped (bh_result, allocated_block_nr, inode);
 		bh_result->b_state |= (1UL << BH_New);
 		done = 1;
 	    } else {
 		/* paste hole to the indirect item */
+		/* If kmalloc failed, max_to_insert becomes zero and it means we
+		   only have space for one block */
+		blocks_needed=max_to_insert?max_to_insert:1;
 	    }
-	    retval = reiserfs_paste_into_item (&th, &path, &tmp_key, (char *)&un, UNFM_P_SIZE);
+	    retval = reiserfs_paste_into_item (&th, &path, &tmp_key, (char *)un, UNFM_P_SIZE * blocks_needed);
+
+	    if (blocks_needed != 1)
+		 kfree(un);
+
 	    if (retval) {
 		reiserfs_free_block (&th, allocated_block_nr);
 		goto failure;
 	    }
-	    if (un.unfm_nodenum)
+	    if (done) {
 		inode->i_blocks += inode->i_sb->s_blocksize / 512;
+	    } else {
+		/* We need to mark new file size in case this function will be
+		   interrupted/aborted later on. And we may do this only for
+		   holes. */
+		inode->i_size += blocks_needed << inode->i_blkbits;
+	    }
 	    //mark_tail_converted (inode);
 	}
-		
+
 	if (done == 1)
 	    break;
-	 
+
 	/* this loop could log more blocks than we had originally asked
 	** for.  So, we have to allow the transaction to end if it is
 	** too big or too full.  Update the inode so things are 
===== fs/reiserfs/tail_conversion.c 1.17 vs edited =====
--- 1.17/fs/reiserfs/tail_conversion.c	Sat May  3 15:38:39 2003
+++ edited/fs/reiserfs/tail_conversion.c	Tue Jun 17 19:11:38 2003
@@ -30,7 +30,7 @@
                                 key of unfm pointer to be pasted */
     int	n_blk_size,
       n_retval;	  /* returned value for reiserfs_insert_item and clones */
-    struct unfm_nodeinfo unfm_ptr;  /* Handle on an unformatted node
+    unp_t unfm_ptr;  /* Handle on an unformatted node
 				       that will be inserted in the
 				       tree. */
 
@@ -59,8 +59,7 @@
     
     p_le_ih = PATH_PITEM_HEAD (path);
 
-    unfm_ptr.unfm_nodenum = cpu_to_le32 (unbh->b_blocknr);
-    unfm_ptr.unfm_freespace = 0; // ???
+    unfm_ptr = cpu_to_le32 (unbh->b_blocknr);
     
     if ( is_statdata_le_ih (p_le_ih) )  {
 	/* Insert new indirect item. */
===== include/linux/reiserfs_fs.h 1.27 vs edited =====
--- 1.27/include/linux/reiserfs_fs.h	Sat May  3 15:38:41 2003
+++ edited/include/linux/reiserfs_fs.h	Tue Jun 17 19:12:15 2003
@@ -1158,6 +1158,7 @@
 
 /* Size of pointer to the unformatted node. */
 #define UNFM_P_SIZE (sizeof(unp_t))
+#define UNFM_P_SHIFT 2
 
 // in in-core inode key is stored on le form
 #define INODE_PKEY(inode) ((struct key *)((inode)->u.reiserfs_i.i_key))

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Thu, 10 Jul 2003, Oleg Drokin wrote:
> On Thu, Jul 10, 2003 at 05:23:39AM +0200, Szakacsits Szabolcs wrote:
>
> > I've noticed very long "hangs" using reiserfs and they were always at
> > ftruncate(2). I made a comparision between different filesystems. SuSE 8.2
>
> Yes, this is known "feature".

OK, I've searched all relevant archives, namesys web pages and found
nothing relevant.

> > (same bad performance on older SuSE versions as well), same partitition,
> > default mkfs.*. Let's create a 200GB sparse file:
> > 	dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > Results:
> > 	ext3	    0.00 sec
> > 	XFS         0.00 sec
> > 	JFS         0.00 sec
> > 	reiserfs  874.27 sec (all spent in the kernel)
>
> See the patch below.
> It is merged into 2.4.22-pre3

Excellent, I can see
http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.22.log
Oleg Drokin <green@angband.namesys.com>:
	reiserfs: speed up large file holes creation

> Speeds up large holes creation in ~ 1000 times

How long does it take for you the above dd command _and_ how fast is your
CPU?

> (on 4k blocksize)

AFAIK, reiserfs supports only 4 kB blocksizes. At least the
'man mkreiserfs' said always so.

> > Is there a faster way to create big sparse files on reiserfs?
>
> Use the patch. (should apply to 2.4.18,2.4.19,2.4.20,2.4.21)
> (I am unsure if you can apply it to the kernel from SuSE 8.2, though).

Thanks but it's only indirectly my problem (I use XFS, there are other
problems with reiserfs for my needs): before further work on ntfsresize,
NTFS I wrote a util, ntfsclone. It efficiently saves all data or only
metadata to a device, stdout or sparse file, so the clone is an exact copy
and always mountable. Good for backup, debug, development and the extremely
well compressable metadata-only clone can be transfered through the net
(e.g. a 200GB NTFS with only a few GB data ends up between a few hundred kB
or max a couple of MB).

The problem is when one uses it on reiserfs. For the users it "hangs". E.g.
in the above case creating a metadata only clone takes 2-3 sec for all the
other filesystems and 15 minutes for reiserfs.

So apparently my only chance is to document the issue and detect if the fs
is reiserfs and warn the user it will take a very long time (unless kernel
is at least 2.4.22 and your speed up works).

Thanks again,

	Szaka

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Thu, 10 Jul 2003, Oleg Drokin wrote:
>
> angband:/mnt # time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> 1+0 records in
> 1+0 records out
>
> real    0m19.205s
> user    0m0.000s
> sys     0m7.130s

Interesting. For me, the real and the system time was always [almost] the
same.

> This is on Athlon MP-1700+ (I have dual system). The system is all IDE.
> This is still kind of long, but it is better than it was ;)
> Actually I expected it to be much faster, I guess I need to take a look why
> it still eats this much time.
>
> > > (on 4k blocksize)
> > AFAIK, reiserfs supports only 4 kB blocksizes. At least the
> > 'man mkreiserfs' said always so.
>
> may be you just have old reiserfsprogs version.

Yes, I have whatever the latest distros ship. Right now I could check out
only Red Hat 9 and SuSE 8.2, they both have 3.6.4. The latest reiserfsprogs
is 3.6.8.

> There are support for variable blocksizes in 2.5, and there is separate
> patch for 2.4

Cool. The max 4 kB block size was a long time common deficiency of the main
Linux filesystems.

Cheers,

	Szaka

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 09:30:46AM +0200, Szakacsits Szabolcs wrote:
> > > I've noticed very long "hangs" using reiserfs and they were always at
> > > ftruncate(2). I made a comparision between different filesystems. SuSE 8.2
> > Yes, this is known "feature".
> OK, I've searched all relevant archives, namesys web pages and found
> nothing relevant.
In fact there were sevaral discussions on our mailing list about this.

> > Speeds up large holes creation in ~ 1000 times
> How long does it take for you the above dd command _and_ how fast is your
> CPU?

angband:/mnt # time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
1+0 records in
1+0 records out

real    0m19.205s
user    0m0.000s
sys     0m7.130s

This is on Athlon MP-1700+ (I have dual system). The system is all IDE.
This is still kind of long, but it is better than it was ;)
Actually I expected it to be much faster, I guess I need to take a look why
it still eats this much time.

> > (on 4k blocksize)
> AFAIK, reiserfs supports only 4 kB blocksizes. At least the
> 'man mkreiserfs' said always so.

may be you just have old reiserfsprogs version.
There are support for variable blocksizes in 2.5, and there is separate
patch for 2.4

> The problem is when one uses it on reiserfs. For the users it "hangs". E.g.
> in the above case creating a metadata only clone takes 2-3 sec for all the
> other filesystems and 15 minutes for reiserfs.
> So apparently my only chance is to document the issue and detect if the fs
> is reiserfs and warn the user it will take a very long time (unless kernel
> is at least 2.4.22 and your speed up works).

Yes, this seems adequate.

Thank you.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 10:17:40AM +0200, Szakacsits Szabolcs wrote:
> > angband:/mnt # time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > 1+0 records in
> > 1+0 records out
> > real    0m19.205s
> > user    0m0.000s
> > sys     0m7.130s
> Interesting. For me, the real and the system time was always [almost] the
> same.

May be this is because when system time was very big, the difference looked like a noise? ;)

> > > > (on 4k blocksize)
> > > AFAIK, reiserfs supports only 4 kB blocksizes. At least the
> > > 'man mkreiserfs' said always so.
> > may be you just have old reiserfsprogs version.
> Yes, I have whatever the latest distros ship. Right now I could check out
> only Red Hat 9 and SuSE 8.2, they both have 3.6.4. The latest reiserfsprogs
> is 3.6.8.

Actually 3.6.4 has support for blocksizes other than 4k, this is controlled by
-b switch of mkreiserfs (run it without arguments and it will tell you)
man page on mkreiserfs (in SuSE 8.2 at least) have it listed too.

> > There are support for variable blocksizes in 2.5, and there is separate
> > patch for 2.4
> Cool. The max 4 kB block size was a long time common deficiency of the main
> Linux filesystems.

The 4k blocksize is not FS limit, this is VFS limit related to the fact that
buffer size cannot be bigger than PAGE_SIZE. PAGE_SIZE is 4k on x86,
but it is bigger on some other architectures (e.g. 8k on alphas).
Also there is an effort by William Lee Irwin III to create "clustered page cache"
or something like that (the patchset is named pgcl-something) for 2.5 kernels,
that one allows to cluster several physical pages into one logical, that will
allow to use blocksizes other than hardware PAGE_SIZE, too.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

Hi,

On Thu, 10 Jul 2003, Oleg Drokin wrote:

> May be this is because when system time was very big, the difference
> looked like a noise? ;)

You can decide yourself,

PIII/666:  0.00s  usr,  917.83s sys   923.72s real,  99% CPU
Xeon/1.7:  0.00s  usr,  862.79s sys,  865.13s real,  99% CPU

> > Yes, I have whatever the latest distros ship. Right now I could check out
> > only Red Hat 9 and SuSE 8.2, they both have 3.6.4. The latest reiserfsprogs
> > is 3.6.8.
>
> Actually 3.6.4 has support for blocksizes other than 4k, this is
> controlled by -b switch of mkreiserfs (run it without arguments and it
> will tell you) man page on mkreiserfs (in SuSE 8.2 at least) have it
> listed too.

Both SuSE 8.2 and Red Hat 9 mkreiserfs manual say:

       -b | --block-size N
              N is block size in bytes. 4096 only for now.

> The 4k blocksize is not FS limit, this is VFS limit related to the fact
> that buffer size cannot be bigger than PAGE_SIZE.

Yes but people aren't really interested in this. FreeBSD uses 8 kB for at
least about 6 years by default and NTFS max 64 kB for a decade (frequently
used in benchmarks and when high performance is needed and make sense).

If today I take a stock kernel, which main Linux filesystems support bigger
than 4 kB block size? None.

> Also there is an effort by William Lee Irwin III to create "clustered
> page cache" or something like that (the patchset is named

I know, also it's too late for 2.6.

	Szaka

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Thu, Jul 10, 2003 at 04:01:13PM +0200, Szakacsits Szabolcs wrote:

> > May be this is because when system time was very big, the difference
> > looked like a noise? ;)
> You can decide yourself,
> PIII/666:  0.00s  usr,  917.83s sys   923.72s real,  99% CPU
> Xeon/1.7:  0.00s  usr,  862.79s sys,  865.13s real,  99% CPU

Well, there is some difference. May be it can be explained by different drives, different
partitioning and stuff like that.

> > > Yes, I have whatever the latest distros ship. Right now I could check out
> > > only Red Hat 9 and SuSE 8.2, they both have 3.6.4. The latest reiserfsprogs
> > > is 3.6.8.
> > Actually 3.6.4 has support for blocksizes other than 4k, this is
> > controlled by -b switch of mkreiserfs (run it without arguments and it
> > will tell you) man page on mkreiserfs (in SuSE 8.2 at least) have it
> > listed too.
> Both SuSE 8.2 and Red Hat 9 mkreiserfs manual say:
>        -b | --block-size N
>               N is block size in bytes. 4096 only for now.

Ah, the safety measure ;)

> > The 4k blocksize is not FS limit, this is VFS limit related to the fact
> > that buffer size cannot be bigger than PAGE_SIZE.
> Yes but people aren't really interested in this. FreeBSD uses 8 kB for at
> least about 6 years by default and NTFS max 64 kB for a decade (frequently
> used in benchmarks and when high performance is needed and make sense).

Sigh, so we are all doomed.

> If today I take a stock kernel, which main Linux filesystems support bigger
> than 4 kB block size? None.

iso9660 fs have pretty big blocksize, I think. Too bad you can only read from it ;)

Bye,
    Oleg

Re: Horrible ftruncate performance

[Chris Mason]

On Thu, 2003-07-10 at 01:29, Oleg Drokin wrote:
> Hello!
> 
> On Thu, Jul 10, 2003 at 05:23:39AM +0200, Szakacsits Szabolcs wrote:
> 
> > I've noticed very long "hangs" using reiserfs and they were always at
> > ftruncate(2). I made a comparision between different filesystems. SuSE 8.2
> 
> Yes, this is known "feature".
> 
> > (same bad performance on older SuSE versions as well), same partitition,
> > default mkfs.*. Let's create a 200GB sparse file:
> > 	dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > Results:
> > 	ext3	    0.00 sec
> > 	XFS         0.00 sec
> > 	JFS         0.00 sec
> > 	reiserfs  874.27 sec (all spent in the kernel)
> 
> See the patch below.
> It is merged into 2.4.22-pre3
> Speeds up large holes creation in ~ 1000 times (on 4k blocksize)
> 
> > Is there a faster way to create big sparse files on reiserfs?
> 
> Use the patch. (should apply to 2.4.18,2.4.19,2.4.20,2.4.21)
> (I am unsure if you can apply it to the kernel from SuSE 8.2, though).

I'll try to get this in for 8.3, it makes a huge difference.

-chris

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 16:27 schrieb Chris Mason:
> On Thu, 2003-07-10 at 01:29, Oleg Drokin wrote:
> > Hello!
> >
> > On Thu, Jul 10, 2003 at 05:23:39AM +0200, Szakacsits Szabolcs wrote:
> > > I've noticed very long "hangs" using reiserfs and they were always at
> > > ftruncate(2). I made a comparision between different filesystems. SuSE
> > > 8.2
> >
> > Yes, this is known "feature".
> >
> > > (same bad performance on older SuSE versions as well), same
> > > partitition, default mkfs.*. Let's create a 200GB sparse file:
> > > 	dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > > Results:
> > > 	ext3	    0.00 sec
> > > 	XFS         0.00 sec
> > > 	JFS         0.00 sec
> > > 	reiserfs  874.27 sec (all spent in the kernel)
> >
> > See the patch below.
> > It is merged into 2.4.22-pre3
> > Speeds up large holes creation in ~ 1000 times (on 4k blocksize)
> >
> > > Is there a faster way to create big sparse files on reiserfs?
> >
> > Use the patch. (should apply to 2.4.18,2.4.19,2.4.20,2.4.21)
> > (I am unsure if you can apply it to the kernel from SuSE 8.2, though).
>
> I'll try to get this in for 8.3, it makes a huge difference.

9.0 ...If I'm right...;-)

And reiserfsprogs-3.6.8 (9 with the great speedup)?

Greetings,
	Dieter

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Donnerstag, 10. Juli 2003 11:21 schrieb Oleg Drokin:
> Hello!
>
> On Thu, Jul 10, 2003 at 09:30:46AM +0200, Szakacsits Szabolcs wrote:
> > > > I've noticed very long "hangs" using reiserfs and they were always at
> > > > ftruncate(2). I made a comparision between different filesystems.
> > > > SuSE 8.2
> > >
> > > Yes, this is known "feature".
> >
> > OK, I've searched all relevant archives, namesys web pages and found
> > nothing relevant.
>
> In fact there were sevaral discussions on our mailing list about this.
>
> > > Speeds up large holes creation in ~ 1000 times
> >
> > How long does it take for you the above dd command _and_ how fast is your
> > CPU?
>
> angband:/mnt # time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> 1+0 records in
> 1+0 records out
>
> real    0m19.205s
> user    0m0.000s
> sys     0m7.130s
>
> This is on Athlon MP-1700+ (I have dual system). The system is all IDE.
> This is still kind of long, but it is better than it was ;)
> Actually I expected it to be much faster, I guess I need to take a look why
> it still eats this much time.

daul Athlon MP 1900+
U160

Argh! ---I can't kill it!
No CNTL-C or '"killall -9 dd" or under "top".
Even as root;-(

2.4.21-jam1 (aa1) plus all data-logging

SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w

It was runinng with a paralell C++ (-j20) compilation.

Is the mentioned patch needed?

Regards,
	Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Fri, Jul 11, 2003 at 04:35:27PM +0200, Dieter N?tzel wrote:

> daul Athlon MP 1900+
> U160
> Argh! ---I can't kill it!
> No CNTL-C or '"killall -9 dd" or under "top".
> Even as root;-(

Yup. It spins in kernel mode not listening to signals busy doing balancing
for lots of zeroes, one at a time.

> 2.4.21-jam1 (aa1) plus all data-logging
> SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> 0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w
> It was runinng with a paralell C++ (-j20) compilation.
> Is the mentioned patch needed?

Yes, patch is needed for any system that does not contain it.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 16:49 schrieb Oleg Drokin:
> Hello!
>
> On Fri, Jul 11, 2003 at 04:35:27PM +0200, Dieter N?tzel wrote:
> > daul Athlon MP 1900+
> > U160
> > Argh! ---I can't kill it!
> > No CNTL-C or '"killall -9 dd" or under "top".
> > Even as root;-(
>
> Yup. It spins in kernel mode not listening to signals busy doing balancing
> for lots of zeroes, one at a time.
>
> > 2.4.21-jam1 (aa1) plus all data-logging
> > SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > 0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w
> > It was runinng with a paralell C++ (-j20) compilation.
> > Is the mentioned patch needed?
>
> Yes, patch is needed for any system that does not contain it.

2.4.21-jam1 (2.4.21aa1):

SunWave1 src/linux# patch -p1 -E -N 
<../patches/2.4.21-data-logging/ftruncate.patch
patching file fs/reiserfs/do_balan.c
Hunk #1 FAILED at 304.
Hunk #2 FAILED at 326.
Hunk #3 FAILED at 435.
Hunk #4 FAILED at 525.
Hunk #5 FAILED at 553.
Hunk #6 FAILED at 566.
Hunk #7 FAILED at 574.
Hunk #8 FAILED at 691.
Hunk #9 FAILED at 725.
Hunk #10 FAILED at 769.
Hunk #11 FAILED at 846.
Hunk #12 succeeded at 847 with fuzz 2 (offset -8 lines).
Hunk #13 FAILED at 857.
Hunk #14 FAILED at 984.
Hunk #15 FAILED at 1037.
Hunk #16 FAILED at 1133.
15 out of 16 hunks FAILED -- saving rejects to file fs/reiserfs/do_balan.c.rej
patching file fs/reiserfs/inode.c
Hunk #1 FAILED at 798.
Hunk #2 FAILED at 811.
2 out of 2 hunks FAILED -- saving rejects to file fs/reiserfs/inode.c.rej
patching file fs/reiserfs/tail_conversion.c
Hunk #1 FAILED at 30.
Hunk #2 succeeded at 59 with fuzz 1.
1 out of 2 hunks FAILED -- saving rejects to file 
fs/reiserfs/tail_conversion.c.rej
patching file include/linux/reiserfs_fs.h
Hunk #1 succeeded at 1289 (offset 131 lines).

OK some "hand work"...

Maybe it _IS_ time for this _AND_ all the other data-logging patches?
2.4.22-pre5?

Thanks,
	Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Fri, Jul 11, 2003 at 05:16:56PM +0200, Dieter N?tzel wrote:

> OK some "hand work"...

Actually I did it already, as data-logging patches can be applied to 2.4.22-pre3
(where this truncate patch was included).

> Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> 2.4.22-pre5?

It's Chris turn. I thought it is good idea to test in -ac first, though
(even taking into account that these patches are part of SuSE's stock kernels).

Bye,
    Oleg

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 17:24 schrieb Oleg Drokin:
> Hello!
>
> On Fri, Jul 11, 2003 at 05:16:56PM +0200, Dieter N?tzel wrote:
> > OK some "hand work"...
>
> Actually I did it already, as data-logging patches can be applied to
> 2.4.22-pre3 (where this truncate patch was included).

No -aaX.

> > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > 2.4.22-pre5?
>
> It's Chris turn. I thought it is good idea to test in -ac first, though
> (even taking into account that these patches are part of SuSE's stock
> kernels).

I don't think -ac would make it => No big Reiser involved...

-Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Fri, Jul 11, 2003 at 05:27:25PM +0200, Dieter N?tzel wrote:
> > Actually I did it already, as data-logging patches can be applied to
> > 2.4.22-pre3 (where this truncate patch was included).
> No -aaX.

Right.

> > > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > > 2.4.22-pre5?
> > It's Chris turn. I thought it is good idea to test in -ac first, though
> > (even taking into account that these patches are part of SuSE's stock
> > kernels).
> I don't think -ac would make it => No big Reiser involved...

Would make what?
I think Alan have agreed to put data-logging code in already.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 17:24 schrieb Oleg Drokin:
> Hello!
>
> On Fri, Jul 11, 2003 at 05:16:56PM +0200, Dieter N?tzel wrote:
> > OK some "hand work"...

Where comes this from?
I don't find it my tree:

fs/eiserfs/inode.c

-            if (un.unfm_nodenum)
                 inode->i_blocks += inode->i_sb->s_blocksize / 512;
             //mark_tail_converted (inode);

Thanks,
	Dieter

Re: Horrible ftruncate performance

[Marc-Christian Petersen]

On Friday 11 July 2003 17:24, Oleg Drokin wrote:

Hi Oleg,

> Actually I did it already, as data-logging patches can be applied to
> 2.4.22-pre3 (where this truncate patch was included).
> > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > 2.4.22-pre5?
> It's Chris turn. I thought it is good idea to test in -ac first, though
> (even taking into account that these patches are part of SuSE's stock
> kernels).
Well, I don't think that testing in -ac is necessary at all in this case.

Hundred (maybe even thousands) of users are using data-logging stuff, SuSE has 
it since years, WOLK has it since years. At least for WOLK I know that there 
isn't at least one problem with data-logging stuff (there might be but not 
hit yet ;) and there are also tons of wolk+reiserfs-data-logging users and I 
can be sure 100%, if there were a problem, my inbox would tell me so ;)

I am using WOLK on many production machines with ReiserFS mostly as Fileserver 
(hundred of gigabytes) and proxy caches.

If someone would ask me: Go for 2.4 mainline inclusion w/o going via -ac! :)

--
ciao, Marc

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 17:32 schrieb Oleg Drokin:
> Hello!
>
> On Fri, Jul 11, 2003 at 05:27:25PM +0200, Dieter N?tzel wrote:
> > > Actually I did it already, as data-logging patches can be applied to
> > > 2.4.22-pre3 (where this truncate patch was included).
> >
> > No -aaX.
>
> Right.
>
> > > > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > > > 2.4.22-pre5?
> > >
> > > It's Chris turn. I thought it is good idea to test in -ac first, though
> > > (even taking into account that these patches are part of SuSE's stock
> > > kernels).
> >
> > I don't think -ac would make it => No big Reiser involved...
>
> Would make what?
> I think Alan have agreed to put data-logging code in already.

OK, good to hear.

But "all" ReiserFS data-logging users running -aa (SuSE) kernels (apart from 
WOLK ;-).

-Dieter

Re: Horrible ftruncate performance

[Marc-Christian Petersen]

On Friday 11 July 2003 17:32, Dieter Nützel wrote:

Hi Dieter,

> Where comes this from?
> I don't find it my tree:
>
> fs/eiserfs/inode.c
>
> -            if (un.unfm_nodenum)
>                  inode->i_blocks += inode->i_sb->s_blocksize / 512;
>              //mark_tail_converted (inode);

reiserfs-quota patch removes this.

--
ciao, Marc

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 17:36 schrieb Marc-Christian Petersen:
> On Friday 11 July 2003 17:32, Dieter Nützel wrote:
>
> Hi Dieter,
>
> > Where comes this from?
> > I don't find it my tree:
> >
> > fs/eiserfs/inode.c
> >
> > -            if (un.unfm_nodenum)
> >                  inode->i_blocks += inode->i_sb->s_blocksize / 512;
> >              //mark_tail_converted (inode);
>
> reiserfs-quota patch removes this.

Ah, thank you very much.

I can go ahead, then.

-Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Gello!

On Fri, Jul 11, 2003 at 05:32:49PM +0200, Dieter N?tzel wrote:
> > > OK some "hand work"...
> Where comes this from?

It was there for a lot of time. Like for not less than 2 years, I'd say.

> I don't find it my tree:

reiserfs quota patch got rid of it.
Here's relevant part of my diff:
            if (retval) {
-               reiserfs_free_block (th, allocated_block_nr);
+               reiserfs_free_block (th, inode, allocated_block_nr, 1);
                goto failure;
            }
-           if (done) {
-               inode->i_blocks += inode->i_sb->s_blocksize / 512;
-           } else {
+           if (!done) {
                /* We need to mark new file size in case this function will be
                   interrupted/aborted later on. And we may do this only for
                   holes. */

Bye,
    Oleg

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Fri, Jul 11, 2003 at 05:34:12PM +0200, Marc-Christian Petersen wrote:

> > Actually I did it already, as data-logging patches can be applied to
> > 2.4.22-pre3 (where this truncate patch was included).
> > > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > > 2.4.22-pre5?
> > It's Chris turn. I thought it is good idea to test in -ac first, though
> > (even taking into account that these patches are part of SuSE's stock
> > kernels).
> Well, I don't think that testing in -ac is necessary at all in this case.

May be not. But it is still useful ;)

> I am using WOLK on many production machines with ReiserFS mostly as Fileserver 
> (hundred of gigabytes) and proxy caches.

I am using this code on my production server myself ;)

> If someone would ask me: Go for 2.4 mainline inclusion w/o going via -ac! :)

Chris should decide (and Marcelo should agree) (Actually Chris thought it is good
idea to submit data-logging to Marcelo now, too). I have no objections.
Also now, that quota v2 code is in place, even quota code can be included.

Also it would be great to port this stuff to 2.5 (yes, I know Chris wants this to be in 2.4 first)

Bye,
    Oleg

Re: Horrible ftruncate performance

[Chris Mason]

On Fri, 2003-07-11 at 11:44, Oleg Drokin wrote:
> Hello!
> 
> On Fri, Jul 11, 2003 at 05:34:12PM +0200, Marc-Christian Petersen wrote:
> 
> > > Actually I did it already, as data-logging patches can be applied to
> > > 2.4.22-pre3 (where this truncate patch was included).
> > > > Maybe it _IS_ time for this _AND_ all the other data-logging patches?
> > > > 2.4.22-pre5?
> > > It's Chris turn. I thought it is good idea to test in -ac first, though
> > > (even taking into account that these patches are part of SuSE's stock
> > > kernels).
> > Well, I don't think that testing in -ac is necessary at all in this case.
> 
> May be not. But it is still useful ;)
> 
> > I am using WOLK on many production machines with ReiserFS mostly as Fileserver 
> > (hundred of gigabytes) and proxy caches.
> 
> I am using this code on my production server myself ;)
> 
> > If someone would ask me: Go for 2.4 mainline inclusion w/o going via -ac! :)
> 
> Chris should decide (and Marcelo should agree) (Actually Chris thought it is good
> idea to submit data-logging to Marcelo now, too). I have no objections.
> Also now, that quota v2 code is in place, even quota code can be included.
> 
> Also it would be great to port this stuff to 2.5 (yes, I know Chris wants this to be in 2.4 first)

Marcelo seems to like being really conservative on this point, and I
don't have a problem with Oleg's original idea to just do relocation in
2.4.22 and the full data logging in 2.4.23-pre4 (perhaps +quota now that
32 bit quota support is in there).

2.5 porting work has restarted at last, Oleg's really been helpful with
keeping the 2.4 stuff up to date.

-chris

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 19:09 schrieb Chris Mason:
> On Fri, 2003-07-11 at 11:44, Oleg Drokin wrote:
> > Hello!
> >
> > On Fri, Jul 11, 2003 at 05:34:12PM +0200, Marc-Christian Petersen wrote:
> > > > Actually I did it already, as data-logging patches can be applied to
> > > > 2.4.22-pre3 (where this truncate patch was included).
> > > >
> > > > > Maybe it _IS_ time for this _AND_ all the other data-logging
> > > > > patches? 2.4.22-pre5?
> > > >
> > > > It's Chris turn. I thought it is good idea to test in -ac first,
> > > > though (even taking into account that these patches are part of
> > > > SuSE's stock kernels).
> > >
> > > Well, I don't think that testing in -ac is necessary at all in this
> > > case.
> >
> > May be not. But it is still useful ;)
> >
> > > I am using WOLK on many production machines with ReiserFS mostly as
> > > Fileserver (hundred of gigabytes) and proxy caches.
> >
> > I am using this code on my production server myself ;)
> >
> > > If someone would ask me: Go for 2.4 mainline inclusion w/o going via
> > > -ac! :)
> >
> > Chris should decide (and Marcelo should agree) (Actually Chris thought it
> > is good idea to submit data-logging to Marcelo now, too). I have no
> > objections. Also now, that quota v2 code is in place, even quota code can
> > be included.
> >
> > Also it would be great to port this stuff to 2.5 (yes, I know Chris wants
> > this to be in 2.4 first)
>
> Marcelo seems to like being really conservative on this point, and I
> don't have a problem with Oleg's original idea to just do relocation in
> 2.4.22 and the full data logging in 2.4.23-pre4 (perhaps +quota now that
> 32 bit quota support is in there).

So, it's another half year away...?

> 2.5 porting work has restarted at last, Oleg's really been helpful with
> keeping the 2.4 stuff up to date.

Nice but.

Patches against latest -aa could be helpful, then.

Thanks,
	Dieter

Re: Horrible ftruncate performance

[Chris Mason]

On Fri, 2003-07-11 at 13:27, Dieter Nützel wrote:

> > 2.5 porting work has restarted at last, Oleg's really been helpful with
> > keeping the 2.4 stuff up to date.
> 
> Nice but.
> 
> Patches against latest -aa could be helpful, then.

Hmmm, the latest -aa isn't all that latest right now.  Do you want
something against 2.4.21-rc8aa1 or should I wait until andrea updates to
2.4.22-pre something?

-chris

Re: Horrible ftruncate performance

[Philippe Gramoullé]

Hello Dieter,

Before we  used to host web files so reiserfs + quota was mandatory. We could live without the data-logging
code. Now that we use reiserfs for fsync intensive applications, data-logging + quota + latest
IO improvements from Chris that were committed recently in 2.4.22-pre and it will soon become a must have.

Of course i wish that it would all be included in 2.4.22 but if Marcello doesn't agree
i guess, we'll continue to use the out-of-tree patches and diff's that all people here kindly provided
for years.

Thanks,

Philippe

On Fri, 11 Jul 2003 19:27:06 +0200
Dieter Nützel <Dieter.Nuetzel@hamburg.de> wrote:

  | > Marcelo seems to like being really conservative on this point, and I
  | > don't have a problem with Oleg's original idea to just do relocation in
  | > 2.4.22 and the full data logging in 2.4.23-pre4 (perhaps +quota now that
  | > 32 bit quota support is in there).
  | 
  | So, it's another half year away...?

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Freitag, 11. Juli 2003 20:32 schrieb Chris Mason:
> On Fri, 2003-07-11 at 13:27, Dieter Nützel wrote:
> > > 2.5 porting work has restarted at last, Oleg's really been helpful with
> > > keeping the 2.4 stuff up to date.
> >
> > Nice but.
> >
> > Patches against latest -aa could be helpful, then.
>
> Hmmm, the latest -aa isn't all that latest right now.

True.

2.4.21-jam1 has 2.4.21pre8aa1 plus several other stuff.

> Do you want something against 2.4.21-rc8aa1 or should I wait until andrea
> updates to 2.4.22-pre something?

I think the later is better.

Up and running with "hand crafted" stuff ;-)

As reminder the old numbers (single U160, IBM 10k rpm):

2.4.21-jam1 (aa1) plus all data-logging

SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w

It was runinng with a paralell C++ (-j20) compilation.


Now the new ones (I've test with and without above C++ compilation ;-)

INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1
1+0 Records ein
1+0 Records aus
0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
INSTALL/SOURCE> l
insgesamt 19294
drwxrwxr-x    2 root     root          192 Jul 11 21:46 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32 atlas3.5.6.tar.bz2
-rw-r--r--    1 nuetzel  users     2945814 Jul  2 02:53 k3b-0.9pre2.tar.gz
-rw-r--r--    1 nuetzel  users    15078557 Jul  2 03:04 movix-0.8.0rc2.tar.gz
-rw-r--r--    1 nuetzel  users    214748364801 Jul 11 21:46 sparse2

More than 506 times...

=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))

GREAT stuff!

Thanks,
	Dieter

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Fri, 11 Jul 2003, Dieter [iso-8859-1] Nützel wrote:

> As reminder the old numbers (single U160, IBM 10k rpm):

For the below test, disk doesn't really matter. It's almost [should be (*)]
pure CPU job. Otherwise I'd have suggested a 'sync' at the end(**).

> 2.4.21-jam1 (aa1) plus all data-logging
>
> SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> 0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w
>
> It was runinng with a paralell C++ (-j20) compilation.
> Now the new ones (I've test with and without above C++ compilation ;-)
>
> INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1
> 0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 153pf+0w

This is too good to be true. You shouldn't have sparse2 before running the
test. You wrote you tried this twice ("with and without above C++
compilation"). This should be the result of the second run.

> More than 506 times...
> => 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))

I guess you mean 50,634 or 50634 times faster? But I'm afraid you didn't
test what you should have. Interestingly, the above speedup, 50 times, is
just what I got with Oleg's patch. So now it's only about 2000 times slower
than XFS, JFS and ext3.

Footnotes:
(*) So disk shouldn't matter because the other filesystems use only 4kB to
    store this 200GB sparse file. ReiserFS wastes 201MB! One could
    mistakenly think this IO could be one of the reasons for the slowless,
    but not. No 'sync' and anyway it's just 2 sec to do it on my disk
    later on.

(**) There are a lot of bogus fs benchmarks out there. One of the many
    issues missed is sync after write tests. I also noticed ReiserFS is
    quick to say "I did it" but sometimes it "hangs" for a painful time.
    Ragged, sluggish. Without the sync, I've seen and experienced ResierFS
    frequently coming out as the winner [not sustained writes]. With sync,
    the results are different.

Ok, last complain for today :) I couldn't find an API (I admit, because of
the above reasons, I didn't search hard) to query the map of disk blocks or
[offsets, length] couples used by a file, like XFS's XFS_IOC_GETBMAPX does.
This makes also ReiserFS inadequate to work with sparse files efficiently.

	Szaka

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Sat, 12 Jul 2003, Carl-Daniel Hailfinger wrote:
> Szakacsits Szabolcs wrote:
> > On Fri, 11 Jul 2003, Dieter [iso-8859-1] Nützel wrote:
> >
> >>More than 506 times...
> >>=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))
> >
> > I guess you mean 50,634 or 50634 times faster? But I'm afraid you didn't
> > test what you should have. Interestingly, the above speedup, 50 times, is
> > just what I got with Oleg's patch. So now it's only about 2000 times slower
> > than XFS, JFS and ext3.
>
> This is an i18n issue. In Germany, the meaning of "." and "," in numbers
> is just the reverse of U.S. usage. Of course, we Germans argue the U.S. do
> it backwards.
> Pi=3,14159265....
> fifty thousand six hundred thirty four=50.634

I know very well, but we are communicating in English, not German.

	Szaka

Re: Horrible ftruncate performance

[Carl-Daniel Hailfinger]

Szakacsits Szabolcs wrote:
> On Fri, 11 Jul 2003, Dieter [iso-8859-1] Nützel wrote:
> 
>>More than 506 times...
>>=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))
> 
> I guess you mean 50,634 or 50634 times faster? But I'm afraid you didn't
> test what you should have. Interestingly, the above speedup, 50 times, is
> just what I got with Oleg's patch. So now it's only about 2000 times slower
> than XFS, JFS and ext3.

This is an i18n issue. In Germany, the meaning of "." and "," in numbers
is just the reverse of U.S. usage. Of course, we Germans argue the U.S. do
it backwards.
Pi=3,14159265....
fifty thousand six hundred thirty four=50.634


Carl-Daniel

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Samstag, 12. Juli 2003 05:49 schrieb Szakacsits Szabolcs:
> On Sat, 12 Jul 2003, Carl-Daniel Hailfinger wrote:
> > Szakacsits Szabolcs wrote:
> > > On Fri, 11 Jul 2003, Dieter [iso-8859-1] Nützel wrote:
> > >>More than 506 times...
> > >>=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))
> > >
> > > I guess you mean 50,634 or 50634 times faster? But I'm afraid you
> > > didn't test what you should have.

Why?
Read again.
Time decrease from 8 minutes, 26 seconds down to 0,01 seconds (sometimes 0,00 
seconds).

> > > Interestingly, the above speedup, 50 times,

Do the math.

> > > is just what I got with Oleg's patch. So now it's only about
> > > 2000 times slower than XFS, JFS and ext3.

Do you think?
Compare your 0.00 seconds (0,00 seconds) for XFS, JFS and ext3 with my 0.01 
seconds (0,01 seconds with tcsh 'time').

> > This is an i18n issue. In Germany, the meaning of "." and "," in numbers
> > is just the reverse of U.S. usage. Of course, we Germans argue the U.S.
> > do it backwards.
> > Pi=3,14159265....
> > fifty thousand six hundred thirty four=50.634
>
> I know very well, but we are communicating in English, not German.

Even that ;-)

I mean what I've wrote.
In English (US): 50.634 (fifty thousand six hundred thirty four)

My only error was:
Apart from my disks specification (I post as much as I can when we talk about 
'benchmarks') I copy & paste some wrong lines. But the final 'sync' is faster 
with faster disk;-)

I did three (or more) sparse file generations. One after each other.
See, again:


INSTALL/SOURCE> l
insgesamt 19286
drwxrwxr-x    2 root     root          168 Jul 11 23:33 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32 atlas3.5.6.tar.bz2
-rw-r--r--    1 nuetzel  users     2945814 Jul  2 02:53 k3b-0.9pre2.tar.gz
-rw-r--r--    1 nuetzel  users    15078557 Jul  2 03:04 movix-0.8.0rc2.tar.gz

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.010u 0.020s 0:00.02 150.0%    0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.000u 0.010s 0:00.02 50.0%     0+0k 0+0io 122pf+0w
INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.000u 0.000s 0:00.01 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 19310
drwxrwxr-x    2 root     root          240 Jul 12 15:01 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32 atlas3.5.6.tar.bz2
-rw-r--r--    1 nuetzel  users     2945814 Jul  2 02:53 k3b-0.9pre2.tar.gz
-rw-r--r--    1 nuetzel  users    15078557 Jul  2 03:04 movix-0.8.0rc2.tar.gz
-rw-r--r--    1 nuetzel  users    214748364801 Jul 12 15:01 sparse
-rw-r--r--    1 nuetzel  users    214748364801 Jul 12 15:01 sparse1
-rw-r--r--    1 nuetzel  users    214748364801 Jul 12 15:01 sparse2

Regards,
	Dieter

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Samstag, 12. Juli 2003 03:37 schrieb Szakacsits Szabolcs:
> On Fri, 11 Jul 2003, Dieter [iso-8859-1] Nützel wrote:
> > As reminder the old numbers (single U160, IBM 10k rpm):
>
> For the below test, disk doesn't really matter. It's almost [should be (*)]
> pure CPU job. Otherwise I'd have suggested a 'sync' at the end(**).
>
> > 2.4.21-jam1 (aa1) plus all data-logging
> >
> > SOURCE/dri-trunk> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1
> > 0.000u 362.760s 8:26.34 71.6%   0+0k 0+0io 124pf+0w
> >
> > It was runinng with a paralell C++ (-j20) compilation.
> > Now the new ones (I've test with and without above C++ compilation ;-)
> >
> > INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1
> > 0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
>
> This is too good to be true. You shouldn't have sparse2 before running the
> test. You wrote you tried this twice ("with and without above C++
> compilation"). This should be the result of the second run.
>
> > More than 506 times...
> > => 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))

[-]

> Footnotes:
> (*) So disk shouldn't matter because the other filesystems use only 4kB to
>     store this 200GB sparse file. ReiserFS wastes 201MB!

No. Exactly 8192 bytes (8 KibiBytes)

>     One could
>     mistakenly think this IO could be one of the reasons for the slowless,
>     but not. No 'sync' and anyway it's just 2 sec to do it on my disk
>     later on.

It is all fixed. With or without final 'sync'.

> (**) There are a lot of bogus fs benchmarks out there. One of the many
>     issues missed is sync after write tests. I also noticed ReiserFS is
>     quick to say "I did it" but sometimes it "hangs" for a painful time.

Never append for ages.

>     Ragged, sluggish. Without the sync, I've seen and experienced ResierFS
>     frequently coming out as the winner [not sustained writes]. With sync,
>     the results are different.

Test with fsync. Try Chris's "synctest".

-Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Sat, Jul 12, 2003 at 03:37:48AM +0200, Szakacsits Szabolcs wrote:
> Footnotes:
> (*) So disk shouldn't matter because the other filesystems use only 4kB to
>     store this 200GB sparse file. ReiserFS wastes 201MB! One could

Yes. The thing is reiserfs prepopulates the tree with empty pointers
up to needed file length. Others just increase filesize.
We found out that just increasing filesize leads to races later on
when two parallel writers try to actually write somewhere
past the real file end. Then we endup in a situation where
same stuff in the tree is about to be inserted twice which
is bad idea of course.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Sat, Jul 12, 2003 at 04:05:27PM +0200, Dieter N?tzel wrote:
> > Footnotes:
> > (*) So disk shouldn't matter because the other filesystems use only 4kB to
> >     store this 200GB sparse file. ReiserFS wastes 201MB!
> No. Exactly 8192 bytes (8 KibiBytes)

No, he is right.
Space usage is ~ holesize>>10 (for 4k blocksize)
Empty tree pointers take this space.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Sat, Jul 12, 2003 at 03:37:48AM +0200, Szakacsits Szabolcs wrote:
 
> Ok, last complain for today :) I couldn't find an API (I admit, because of
> the above reasons, I didn't search hard) to query the map of disk blocks or
> [offsets, length] couples used by a file, like XFS's XFS_IOC_GETBMAPX does.

Something like FIBMAP ioctl?

> This makes also ReiserFS inadequate to work with sparse files efficiently.

The real lack is for the API to "punch a hole" that was recently discussed
on the list already.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Hans Reiser]

reiser4 is the cure for this.  soon, very soon.

-- 
Hans

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Sun, 13 Jul 2003, Oleg Drokin wrote:
> On Sat, Jul 12, 2003 at 03:37:48AM +0200, Szakacsits Szabolcs wrote:
>
> > Ok, last complain for today :) I couldn't find an API (I admit, because of
> > the above reasons, I didn't search hard) to query the map of disk blocks or
> > [offsets, length] couples used by a file, like XFS's XFS_IOC_GETBMAPX does.
>
> Something like FIBMAP ioctl?

FIBMAP is limited, inefficient (especially for large sparse files with very
high hole density) and it also needs root.

Some data, querying a 200GB file,

ext3 + FIBMAP             63.53 sec 100% CPU
JFS  + FIBMAP      	  65.81 sec 100% CPU
XFS  + FIBMAP            125.93 sec 100% CPU
XFS  + XFS_IOC_GETBMAPX    0.00 sec   0% CPU

Probably this inefficiency is the reason that no utilities (tar, cp, cat,
gzip, bzip2, etc) use it, instead they just read/analyse the zeros over an
hour when in cases their _entire_ operation could/can be done in seconds,
minutes.

	Szaka

Re: Horrible ftruncate performance

[Szakacsits Szabolcs]

On Sat, 12 Jul 2003, Dieter Nützel wrote:
> > > >>More than 506 times...
> > > >>=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))
> > > >
> > > > I guess you mean 50,634 or 50634 times faster? But I'm afraid you
> > > > didn't test what you should have.
>
> Why? Read again. Time decrease from 8 minutes, 26 seconds down to 0,01
> seconds (sometimes 0,00 seconds).

For the same test, with the efficiency patch, Oleg wrote:

	real    0m19.205s
	user    0m0.000s
	sys     0m7.130s

That's a difference what doesn't happen magically, usually. The reason is
one of these,

	1) Oleg's result is incorrect
	2) Your result is incorrect
	3) You use different patches.

> INSTALL/SOURCE> l
> insgesamt 19286
> drwxrwxr-x    2 root     root          168 Jul 11 23:33 .
> drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
> -rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32 atlas3.5.6.tar.bz2
> -rw-r--r--    1 nuetzel  users     2945814 Jul  2 02:53 k3b-0.9pre2.tar.gz
> -rw-r--r--    1 nuetzel  users    15078557 Jul  2 03:04 movix-0.8.0rc2.tar.gz
>
> INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time
> sync
> 1+0 Records ein
> 1+0 Records aus
> 0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
> 0.010u 0.020s 0:00.02 150.0%    0+0k 0+0io 122pf+0w
>
> INSTALL/SOURCE> l
> insgesamt 19310
> drwxrwxr-x    2 root     root          240 Jul 12 15:01 .
> drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
> -rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32 atlas3.5.6.tar.bz2
> -rw-r--r--    1 nuetzel  users     2945814 Jul  2 02:53 k3b-0.9pre2.tar.gz
> -rw-r--r--    1 nuetzel  users    15078557 Jul  2 03:04 movix-0.8.0rc2.tar.gz
> -rw-r--r--    1 nuetzel  users    214748364801 Jul 12 15:01 sparse

This is ok, however you also claimed 'sparse' used only 8 kB physical disk
space what Oleg refuted it can't be. Conclusion? You used a different
filesystem, not reiser3.

	Szaka

Re: Horrible ftruncate performance

[Hans Reiser]

Szakacsits Szabolcs wrote:

>On Sun, 13 Jul 2003, Oleg Drokin wrote:
>  
>
>>On Sat, Jul 12, 2003 at 03:37:48AM +0200, Szakacsits Szabolcs wrote:
>>
>>    
>>
>>>Ok, last complain for today :) I couldn't find an API (I admit, because of
>>>the above reasons, I didn't search hard) to query the map of disk blocks or
>>>[offsets, length] couples used by a file, like XFS's XFS_IOC_GETBMAPX does.
>>>      
>>>
>>Something like FIBMAP ioctl?
>>    
>>
>
>FIBMAP is limited, inefficient (especially for large sparse files with very
>high hole density) and it also needs root.
>
>Some data, querying a 200GB file,
>
>ext3 + FIBMAP             63.53 sec 100% CPU
>JFS  + FIBMAP      	  65.81 sec 100% CPU
>XFS  + FIBMAP            125.93 sec 100% CPU
>XFS  + XFS_IOC_GETBMAPX    0.00 sec   0% CPU
>
>Probably this inefficiency is the reason that no utilities (tar, cp, cat,
>gzip, bzip2, etc) use it, instead they just read/analyse the zeros over an
>hour when in cases their _entire_ operation could/can be done in seconds,
>minutes.
>
>	Szaka
>
>
>
>  
>
This is a good point.  Demidov, consider holes when you optimize 
assignment in sys_reiser4().

-- 
Hans

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Dienstag, 15. Juli 2003 14:19 schrieb Szakacsits Szabolcs:
> On Sat, 12 Jul 2003, Dieter Nützel wrote:
> > > > >>More than 506 times...
> > > > >>=> 506.34 seconds (8:26.34) / 0.01 seconds = 50.634 times ;-)))
> > > > >
> > > > > I guess you mean 50,634 or 50634 times faster? But I'm afraid you
> > > > > didn't test what you should have.
> >
> > Why? Read again. Time decrease from 8 minutes, 26 seconds down to 0,01
> > seconds (sometimes 0,00 seconds).
>
> For the same test, with the efficiency patch, Oleg wrote:
>
> 	real    0m19.205s
> 	user    0m0.000s
> 	sys     0m7.130s
>
> That's a difference what doesn't happen magically, usually. The reason is
> one of these,
>
> 	1) Oleg's result is incorrect

Maybe.

> 	2) Your result is incorrect

Maybe.

> 	3) You use different patches.

Maybe.

I used what I've posted:

2.4.21-jam1 (2.4.21pre8aa1 on-top of 2.4.21)

patches/2.4.21-data-logging> l
insgesamt 109
drwxr-xr-x    2 root     root          536 Jul 11 23:37 .
drwxr-xr-x    6 root     root          480 Jul 15 06:49 ..
-rw-r--r--    1 root     root        18079 Jun 16 15:32 
03-relocation-8.diff.bz2
-rw-r--r--    1 root     root         4929 Jun 16 15:32 
04-reiserfs-sync_fs-4.diff.bz2
-rw-r--r--    1 root     root        32452 Jun 26 13:57 
05-data-logging-38.diff.bz2
-rw-r--r--    1 root     root         6072 Jun 26 14:27 
06-reiserfs-jh-2.diff.bz2
-rw-r--r--    1 root     root        10605 Jun 26 13:57 
08-reiserfs-quota-28.diff.bz2
-rw-r--r--    1 root     root         1638 Jun 16 15:32 09-kinoded-8.diff.bz2
-rw-r--r--    1 root     root          370 Jun 16 15:32 
10-quota_nospace_fix.diff.bz2
-rw-r--r--    1 root     root         1097 Jun 17 22:05 
10-reiserfs-quota-link-fix.diff.bz2
-rw-r--r--    1 root     root          674 Jun 16 15:32 README.bz2
-rw-r--r--    1 root     root         3933 Jul 11 17:07 ftruncate.patch.bz2
-rw-r--r--    1 root     root         7253 Jun 26 13:31 io-stalls-7.diff.bz2

Maybe I did something wrong (or 'better') during my 'ftruncate.patch' merge.
I can repeat the below numbers.

* But sometimes *.o files would be corrupted when I do heavy parallel C++
  compilations.
* 'rpm --rebuilddb' sigfault

> > INSTALL/SOURCE> l
> > insgesamt 19286
> > drwxrwxr-x    2 root     root          168 Jul 11 23:33 .
> > drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
> > -rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32
> > atlas3.5.6.tar.bz2 -rw-r--r--    1 nuetzel  users     2945814 Jul  2
> > 02:53 k3b-0.9pre2.tar.gz -rw-r--r--    1 nuetzel  users    15078557 Jul 
> > 2 03:04 movix-0.8.0rc2.tar.gz
> >
> > INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ;
> > time sync
> > 1+0 Records ein
> > 1+0 Records aus
> > 0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
> > 0.010u 0.020s 0:00.02 150.0%    0+0k 0+0io 122pf+0w
> >
> > INSTALL/SOURCE> l
> > insgesamt 19310
> > drwxrwxr-x    2 root     root          240 Jul 12 15:01 .
> > drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
> > -rw-r--r--    1 nuetzel  users     1696205 Jul  3 01:32
> > atlas3.5.6.tar.bz2 -rw-r--r--    1 nuetzel  users     2945814 Jul  2
> > 02:53 k3b-0.9pre2.tar.gz -rw-r--r--    1 nuetzel  users    15078557 Jul 
> > 2 03:04 movix-0.8.0rc2.tar.gz -rw-r--r--    1 nuetzel  users   
> > 214748364801 Jul 12 15:01 sparse
>
> This is ok, however you also claimed 'sparse' used only 8 kB physical disk
> space what Oleg refuted it can't be.

Yes, see above.
That's because I did something wrong (or 'better').

> Conclusion? You used a different filesystem, not reiser3.

No. It isn't at all that 'old' ReiserFS 3.x when we patch it with 
'data-logging'. But maybe I did something wrong stupid.

With Chris latest stuff

patches/2.4.22-pre5-data-logging> l
insgesamt 89
drwxr-xr-x    2 root     root          552 Jul 15 05:25 .
drwxr-xr-x    6 root     root          480 Jul 15 06:49 ..
-rw-r--r--    1 root     root         1251 Jul 13 16:08 
02-akpm-b_journal_head-1.diff.bz2
-rw-r--r--    1 root     root         4929 Jul 13 16:08 
04-reiserfs-sync_fs-4.diff.bz2
-rw-r--r--    1 root     root        32068 Jul 13 16:08 
05-data-logging-39.diff.bz2
-rw-r--r--    1 root     root          503 Jul 13 16:08 
06-logging-export.diff.bz2
-rw-r--r--    1 root     root         5724 Jul 13 16:08 
06-reiserfs-jh-3.diff.bz2
-rw-r--r--    1 root     root          424 Jul 13 16:08 
06-write_times.diff.bz2
-rw-r--r--    1 root     root        10378 Jul 13 16:08 
07-reiserfs-quota-28.diff.bz2
-rw-r--r--    1 root     root         1541 Jul 13 16:08 08-kinoded-9.diff.bz2
-rw-r--r--    1 root     root         1097 Jul 13 16:08 
10-reiserfs-quota-link-fix.diff.bz2
-rw-r--r--    1 root     root          564 Jul 13 16:08 README.bz2
-rw-r--r--    1 root     root         1580 Jul 15 04:15 
search_reada-5.diff.bz2

I get the 204,804 MB space usage for every 'sparse' file and comparable 
runtime (ca. 13,7 MB/s).

INSTALL/SOURCE> l
insgesamt 1032
drwxrwxr-x    2 root     root          176 Jul 15 17:48 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.840s 0:14.77 19.2%     0+0k 0+0io 153pf+0w
0.000u 0.020s 0:01.21 1.6%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.910s 0:14.73 19.7%     0+0k 0+0io 153pf+0w
0.000u 0.010s 0:01.42 0.7%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 2.920s 0:14.66 19.9%     0+0k 0+0io 153pf+0w
0.010u 0.020s 0:01.30 2.3%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 615444
drwxrwxr-x    2 root     root          248 Jul 15 17:58 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 17:57 sparse
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 17:58 sparse1
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 17:59 sparse2


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The 'right' questions are:

* Are the 204,804 MB really needed?
* How many space do XFS, JFS and ext3 'use'?
* When the above three can do it a 1000 times faster why can't we?
* Do the three other do it right?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Removing of the sparse files can take horrible amount of time.

Even with a pre-emption kernel on a dual SMP system.
For nearly 3 seconds no mouse movement.

INSTALL/SOURCE> time rm sparse ; time sync

0.000u 9.010s 1:05.86 13.6%     0+0k 0+0io 130pf+0w
0.000u 0.000s 0:00.05 0.0%      0+0k 0+0io 122pf+0w


 18:00:18  up 58 min,  1 user,  load average: 2,26, 1,11, 0,70
122 processes: 120 sleeping, 1 running, 1 zombie, 0 stopped
CPU0 states:   0,0% user   6,4% system    0,0% nice   0,0% iowait  93,0% idle
CPU1 states:   0,3% user  13,3% system    0,0% nice   0,0% iowait  85,3% idle
Mem:  1033384k av, 1026084k used,    7300k free,       0k shrd,  728348k buff
       618772k active,             343816k inactive
Swap: 1028120k av,   13328k used, 1014792k free                   73976k 
cached

  PID USER     PRI  NI  SIZE  RSS SHARE WCHAN     STAT %CPU   TIME COMMAND
 3862 nuetzel   17   0   532  532   440 wait_on_b D    17,2   0:06 rm


INSTALL/SOURCE> time rm sparse1 sparse2 ; time sync
0.000u 9.830s 0:09.87 99.5%     0+0k 0+0io 130pf+0w
0.000u 0.000s 0:00.05 0.0%      0+0k 0+0io 122pf+0w


INSTALL/SOURCE> l
insgesamt 615444
drwxrwxr-x    2 root     root          248 Jul 15 18:30 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 18:30 sparse
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 18:30 sparse1
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 18:31 sparse2
INSTALL/SOURCE> sync

INSTALL/SOURCE> time rm sparse2 ; time sync
0.000u 4.910s 0:04.92 99.7%     0+0k 0+0io 130pf+0w
0.000u 0.000s 0:00.34 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time rm sparse1 ; time sync
0.000u 4.840s 0:04.85 99.7%     0+0k 0+0io 130pf+0w
0.000u 0.000s 0:00.07 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> sync
INSTALL/SOURCE> time rm sparse ; time sync
0.010u 14.600s 1:49.55 13.3%    0+0k 0+0io 130pf+0w
0.000u 0.010s 0:00.06 16.6%     0+0k 0+0io 122pf+0w


Longest run taken over 5 minutes ;-(
Compare with mine (in the range of XFS, JFS and ext3).
Are there any races (on SMP)?

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

If I 'create' a second sparse file with the same name over an existing one 
(overwrite) I get the 1000 times speedup!

INSTALL/SOURCE> l
insgesamt 1032
drwxrwxr-x    2 root     root          176 Jul 15 18:33 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm

INSTALL/SOURCE> sync
INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.870s 0:14.89 19.2%     0+0k 0+0io 153pf+0w
0.000u 0.020s 0:01.55 1.2%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> sync
INSTALL/SOURCE> l
insgesamt 205836
drwxrwxr-x    2 root     root          200 Jul 15 18:40 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 18:40 sparse

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.000u 0.000s 0:00.02 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 205836
drwxrwxr-x    2 root     root          200 Jul 15 18:40 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 18:41 sparse


Chris and Oleg what do you need?
SYSRQ-P/M?

Regards,
	Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Tue, Jul 15, 2003 at 06:48:58PM +0200, Dieter N?tzel wrote:

> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> The 'right' questions are:
> * Are the 204,804 MB really needed?

In reiserfs - yes.

> * How many space do XFS, JFS and ext3 'use'?

ext2 uses 16 kb for me (4k blocksize)

> * When the above three can do it a 1000 times faster why can't we?

We can, only in case of reiserfs we have nasty races if we do that.
Or may be not. I have something to discuss around, I guess ;)

> * Do the three other do it right?

I do not know.

> Removing of the sparse files can take horrible amount of time.

Does the patch below helps?

> If I 'create' a second sparse file with the same name over an existing one 
> (overwrite) I get the 1000 times speedup!

Hm. Interesting observation.

> Chris and Oleg what do you need?
> SYSRQ-P/M?

I guess I need additional pair of brains ;)
Also some time that I can spend thinking about all of this.
I guess I'd have plently of it in the Saturday, while flying to Canada.
Only I won't be able to do any experiments. Sigh.

Bye,
    Oleg

===== fs/reiserfs/stree.c 1.22 vs edited =====
--- 1.22/fs/reiserfs/stree.c	Tue Jun 24 11:30:22 2003
+++ edited/fs/reiserfs/stree.c	Tue Jul 15 20:57:09 2003
@@ -1773,6 +1773,8 @@
 	  journal_begin(th, p_s_inode->i_sb, orig_len_alloc) ;
 	  reiserfs_update_inode_transaction(p_s_inode) ;
 	}
+	if ( current->need_resched )
+	    schedule();
     } while ( n_file_size > ROUND_UP (n_new_file_size) &&
 	      search_for_position_by_key(p_s_inode->i_sb, &s_item_key, &s_search_path) == POSITION_FOUND )  ;
 

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Dienstag, 15. Juli 2003 19:05 schrieb Oleg Drokin:
> Hello!
>
> On Tue, Jul 15, 2003 at 06:48:58PM +0200, Dieter N?tzel wrote:
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >!!!!!!!!!!!!!!!!! The 'right' questions are:
> > * Are the 204,804 MB really needed?
>
> In reiserfs - yes.
>
> > * How many space do XFS, JFS and ext3 'use'?
>
> ext2 uses 16 kb for me (4k blocksize)
>
> > * When the above three can do it a 1000 times faster why can't we?
>
> We can, only in case of reiserfs we have nasty races if we do that.
> Or may be not. I have something to discuss around, I guess ;)
>
> > * Do the three other do it right?
>
> I do not know.
>
> > Removing of the sparse files can take horrible amount of time.
>
> Does the patch below helps?

Somewhat.
Mouse movement is OK, now. But...

NSTALL/SOURCE> l
insgesamt 1032
drwxrwxr-x    2 root     root          176 Jul 15 21:45 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 3.090s 0:16.81 18.3%     0+0k 0+0io 153pf+0w
0.000u 0.050s 0:00.27 18.5%     0+0k 0+0io 122pf+0w

INSTALL/SOURCE> sync
INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 3.010s 0:15.27 19.7%     0+0k 0+0io 153pf+0w
0.000u 0.020s 0:01.01 1.9%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> sync
INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.760s 0:15.16 18.2%     0+0k 0+0io 153pf+0w
0.000u 0.030s 0:00.85 3.5%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> sync
INSTALL/SOURCE> l
insgesamt 615444
drwxrwxr-x    2 root     root          248 Jul 15 21:46 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 21:46 sparse
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 21:46 sparse1
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 21:47 sparse2

INSTALL/SOURCE> time rm sparse2 ; time sync
0.000u 4.930s 0:04.88 101.0%    0+0k 0+0io 130pf+0w
0.000u 0.010s 0:00.02 50.0%     0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time rm sparse1 ; time sync
0.000u 4.950s 0:04.87 101.6%    0+0k 0+0io 130pf+0w
0.000u 0.030s 0:00.05 60.0%     0+0k 0+0io 122pf+0w

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

INSTALL/SOURCE> time rm sparse ; time sync
0.000u 14.990s 1:31.15 16.4%    0+0k 0+0io 130pf+0w
0.000u 0.030s 0:00.22 13.6%     0+0k 0+0io 122pf+0w

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> > If I 'create' a second sparse file with the same name over an existing
> > one (overwrite) I get the 1000 times speedup!
>
> Hm. Interesting observation.

Unchanged.

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.750s 0:15.31 17.9%     0+0k 0+0io 153pf+0w
0.010u 0.050s 0:00.93 6.4%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 205836
drwxrwxr-x    2 root     root          200 Jul 15 21:52 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 21:52 sparse

INSTALL/SOURCE> sync
INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.000u 0.030s 0:00.03 100.0%    0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 205836
drwxrwxr-x    2 root     root          200 Jul 15 21:52 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 15 21:53 sparse

> > Chris and Oleg what do you need?
> > SYSRQ-P/M?
>
> I guess I need additional pair of brains ;)
> Also some time that I can spend thinking about all of this.
> I guess I'd have plently of it in the Saturday, while flying to Canada.
> Only I won't be able to do any experiments. Sigh.
>
> Bye,
>     Oleg
>
> ===== fs/reiserfs/stree.c 1.22 vs edited =====
> --- 1.22/fs/reiserfs/stree.c	Tue Jun 24 11:30:22 2003
> +++ edited/fs/reiserfs/stree.c	Tue Jul 15 20:57:09 2003
> @@ -1773,6 +1773,8 @@
>  	  journal_begin(th, p_s_inode->i_sb, orig_len_alloc) ;
>  	  reiserfs_update_inode_transaction(p_s_inode) ;
>  	}
> +	if ( current->need_resched )
> +	    schedule();
>      } while ( n_file_size > ROUND_UP (n_new_file_size) &&
>  	      search_for_position_by_key(p_s_inode->i_sb, &s_item_key,
> &s_search_path) == POSITION_FOUND )  ;

Good night!
	It's summer now;-)
					Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Tue, Jul 15, 2003 at 09:55:09PM +0200, Dieter N?tzel wrote:

> Somewhat.
> Mouse movement is OK, now. But...
> 
> 1+0 Records aus
> 0.000u 3.090s 0:16.81 18.3%     0+0k 0+0io 153pf+0w
> 0.000u 0.050s 0:00.27 18.5%     0+0k 0+0io 122pf+0w
> INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ; time 
> sync
> 1+0 Records ein
> 1+0 Records aus
> 0.000u 3.010s 0:15.27 19.7%     0+0k 0+0io 153pf+0w
> 0.000u 0.020s 0:01.01 1.9%      0+0k 0+0io 122pf+0w

So you create a file in 15 seconds and remove it in 15 seconds.
Kind of nothing changed except mouse now moves, am I reading this wrong?

> INSTALL/SOURCE> time rm sparse ; time sync
> 0.000u 14.990s 1:31.15 16.4%    0+0k 0+0io 130pf+0w
> 0.000u 0.030s 0:00.22 13.6%     0+0k 0+0io 122pf+0w

So the stuff fell out of cache and we need to read it again.
hence the increased time. Hm, probably this case can be optimized
if there is only one item in the leaf and this item should be removed.
Need to take closer look to balancing code.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Mittwoch, 16. Juli 2003 12:35 schrieb Oleg Drokin:
> Hello!
>
> On Tue, Jul 15, 2003 at 09:55:09PM +0200, Dieter N?tzel wrote:
> > Somewhat.
> > Mouse movement is OK, now. But...
> >
> > 1+0 Records aus
> > 0.000u 3.090s 0:16.81 18.3%     0+0k 0+0io 153pf+0w
> > 0.000u 0.050s 0:00.27 18.5%     0+0k 0+0io 122pf+0w
> > INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ;
> > time sync
> > 1+0 Records ein
> > 1+0 Records aus
> > 0.000u 3.010s 0:15.27 19.7%     0+0k 0+0io 153pf+0w
> > 0.000u 0.020s 0:01.01 1.9%      0+0k 0+0io 122pf+0w
>
> So you create a file in 15 seconds

Right.

> and remove it in 15 seconds.

No. "Normaly" ~5 seconds.

INSTALL/SOURCE> time rm sparse2 ; time sync
0.000u 4.930s 0:04.88 101.0%    0+0k 0+0io 130pf+0w
0.000u 0.010s 0:00.02 50.0%     0+0k 0+0io 122pf+0w

> Kind of nothing changed except mouse now moves,

Yes.

> am I reading this wrong?

No. ;-)

> > INSTALL/SOURCE> time rm sparse ; time sync
> > 0.000u 14.990s 1:31.15 16.4%    0+0k 0+0io 130pf+0w
> > 0.000u 0.030s 0:00.22 13.6%     0+0k 0+0io 122pf+0w
>
> So the stuff fell out of cache and we need to read it again.

Shouldn't this take only 15 seconds, then?
Worst case was ~5 minutes.

> hence the increased time. Hm, probably this case can be optimized
> if there is only one item in the leaf and this item should be removed.
> Need to take closer look to balancing code.

Now, out of office.

Greetings,
	Dieter

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Wed, Jul 16, 2003 at 12:47:53PM +0200, Dieter N?tzel wrote:
> > > Somewhat.
> > > Mouse movement is OK, now. But...
> > > 1+0 Records aus
> > > 0.000u 3.090s 0:16.81 18.3%     0+0k 0+0io 153pf+0w
> > > 0.000u 0.050s 0:00.27 18.5%     0+0k 0+0io 122pf+0w
> > > INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ;
> > > time sync
> > > 1+0 Records ein
> > > 1+0 Records aus
> > > 0.000u 3.010s 0:15.27 19.7%     0+0k 0+0io 153pf+0w
> > > 0.000u 0.020s 0:01.01 1.9%      0+0k 0+0io 122pf+0w
> > So you create a file in 15 seconds
> Right.
> > and remove it in 15 seconds.
> No. "Normaly" ~5 seconds.

Ah, yes. Looking at wrong timeing info ;)
I see that yesterday without the patch you had 1m, 9s, 5s, 2m times
for 4 deletes...

> > Kind of nothing changed except mouse now moves,

> > > INSTALL/SOURCE> time rm sparse ; time sync
> > > 0.000u 14.990s 1:31.15 16.4%    0+0k 0+0io 130pf+0w
> > > 0.000u 0.030s 0:00.22 13.6%     0+0k 0+0io 122pf+0w
> > So the stuff fell out of cache and we need to read it again.
> Shouldn't this take only 15 seconds, then?

Probably there was some seeking due to removal of lots of blocks.

> Worst case was ~5 minutes.

Yeah, this is of course sad.
BTW is this with search_reada patch? What if you try without it?

Bye,
    Oleg

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Mittwoch, 16. Juli 2003 12:57 schrieb Oleg Drokin:
> Hello!
>
> On Wed, Jul 16, 2003 at 12:47:53PM +0200, Dieter N?tzel wrote:
> > > > Somewhat.
> > > > Mouse movement is OK, now. But...
> > > > 1+0 Records aus
> > > > 0.000u 3.090s 0:16.81 18.3%     0+0k 0+0io 153pf+0w
> > > > 0.000u 0.050s 0:00.27 18.5%     0+0k 0+0io 122pf+0w
> > > > INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G
> > > > count=1 ; time sync
> > > > 1+0 Records ein
> > > > 1+0 Records aus
> > > > 0.000u 3.010s 0:15.27 19.7%     0+0k 0+0io 153pf+0w
> > > > 0.000u 0.020s 0:01.01 1.9%      0+0k 0+0io 122pf+0w
> > >
> > > So you create a file in 15 seconds
> >
> > Right.
> >
> > > and remove it in 15 seconds.
> >
> > No. "Normaly" ~5 seconds.
>
> Ah, yes. Looking at wrong timeing info ;)
> I see that yesterday without the patch you had 1m, 9s, 5s, 2m times
> for 4 deletes...
>
> > > Kind of nothing changed except mouse now moves,
> > >
> > > > INSTALL/SOURCE> time rm sparse ; time sync
> > > > 0.000u 14.990s 1:31.15 16.4%    0+0k 0+0io 130pf+0w
> > > > 0.000u 0.030s 0:00.22 13.6%     0+0k 0+0io 122pf+0w
> > >
> > > So the stuff fell out of cache and we need to read it again.
> >
> > Shouldn't this take only 15 seconds, then?
>
> Probably there was some seeking due to removal of lots of blocks.
>
> > Worst case was ~5 minutes.
>
> Yeah, this is of course sad.
> BTW is this with search_reada patch?

Yes.

> What if you try without it?

Do _NOT_ really help.

INSTALL/SOURCE> l
insgesamt 1032
drwxrwxr-x    2 root     root          176 Jul 17 20:05 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm

INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.000u 2.770s 0:15.88 17.4%     0+0k 0+0io 153pf+0w
0.000u 0.000s 0:00.79 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time dd if=/dev/zero of=sparse1 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 2.440s 0:15.03 16.3%     0+0k 0+0io 153pf+0w
0.010u 0.020s 0:01.08 2.7%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time dd if=/dev/zero of=sparse2 bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 2.710s 0:14.94 18.2%     0+0k 0+0io 153pf+0w
0.000u 0.000s 0:01.76 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 615444
drwxrwxr-x    2 root     root          248 Jul 17 20:06 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 17 20:06 sparse
-rw-r--r--    1 nuetzel  users    214748364801 Jul 17 20:06 sparse1
-rw-r--r--    1 nuetzel  users    214748364801 Jul 17 20:07 sparse2

INSTALL/SOURCE> time sync
0.000u 0.000s 0:00.02 0.0%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time rm sparse2 ; time sync
0.000u 4.860s 0:04.82 100.8%    0+0k 0+0io 130pf+0w
0.010u 0.000s 0:00.03 33.3%     0+0k 0+0io 122pf+0w

INSTALL/SOURCE> time rm sparse1 ; time sync
0.000u 4.910s 0:04.82 101.8%    0+0k 0+0io 130pf+0w
0.000u 0.020s 0:00.03 66.6%     0+0k 0+0io 122pf+0w

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

INSTALL/SOURCE> time rm sparse ; time sync
0.010u 6.500s 0:48.47 13.4%     0+0k 0+0io 130pf+0w
0.000u 0.000s 0:00.02 0.0%      0+0k 0+0io 122pf+0w

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

INSTALL/SOURCE> l
insgesamt 1032
drwxrwxr-x    2 root     root          176 Jul 17 20:08 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm


Overwrite:

INSTALL/SOURCE> time sync
0.000u 0.000s 0:00.02 0.0%      0+0k 0+0io 122pf+0w
INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 2.890s 0:16.17 17.9%     0+0k 0+0io 153pf+0w
0.000u 0.020s 0:01.27 1.5%      0+0k 0+0io 122pf+0w

INSTALL/SOURCE> l
insgesamt 205836
drwxrwxr-x    2 root     root          200 Jul 17 20:09 .
drwxr-xr-x    3 root     root           72 Jul  3 01:39 ..
-rw-r--r--    1 nuetzel  users      452390 Jul 15 00:29 
kmplayer-0.7.96.tar.bz2
-rw-r--r--    1 nuetzel  users      403358 Jul 14 21:46 
modutils-2.4.21-18.src.rpm
-rw-r--r--    1 nuetzel  users      194505 Jul 14 22:01 
procps-2.0.13-1.src.rpm
-rw-r--r--    1 nuetzel  users    214748364801 Jul 17 20:09 sparse

INSTALL/SOURCE> time sync
0.000u 0.010s 0:00.09 11.1%     0+0k 0+0io 122pf+0w
INSTALL/SOURCE> time dd if=/dev/zero of=sparse bs=1 seek=200G count=1 ; time 
sync
1+0 Records ein
1+0 Records aus
0.010u 0.000s 0:00.00 0.0%      0+0k 0+0io 153pf+0w
0.000u 0.010s 0:00.07 14.2%     0+0k 0+0io 122pf+0w

-Dieter

Re: Horrible ftruncate performance

[Hans Reiser]

The answer to the below is to use reiser4.  It uses extents, and two 64 
bit numbers are all that is needed to store the hole.  V4 will be ready 
for testing in a few days, and will ship for real users at the end of 
summer we hope.

Fixing V3 is  the wrong answer: this is one of its design flaws.

Hans

Oleg Drokin wrote:

>Hello!
>
>On Tue, Jul 15, 2003 at 06:48:58PM +0200, Dieter N?tzel wrote:
>
>  
>
>>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>The 'right' questions are:
>>* Are the 204,804 MB really needed?
>>    
>>
>
>In reiserfs - yes.
>
>  
>
>>* How many space do XFS, JFS and ext3 'use'?
>>    
>>
>
>ext2 uses 16 kb for me (4k blocksize)
>
>  
>
>>* When the above three can do it a 1000 times faster why can't we?
>>    
>>
>
>We can, only in case of reiserfs we have nasty races if we do that.
>Or may be not. I have something to discuss around, I guess ;)
>
>  
>


-- 
Hans

Re: Horrible ftruncate performance

[Chris Mason]

On Tue, 2003-07-22 at 12:43, Hans Reiser wrote:
> The answer to the below is to use reiser4.  It uses extents, and two 64 
> bit numbers are all that is needed to store the hole.  V4 will be ready 
> for testing in a few days, and will ship for real users at the end of 
> summer we hope.
> 
> Fixing V3 is  the wrong answer: this is one of its design flaws.

It's important to remember that releasing v4 doesn't automatically
convert all existing v3 users to it.  This is the kind of thing we
should try to fix without making major design changes to v3.  It's at
least worth talking about, "use v4" can't always be the answer.

-chris

Re: Horrible ftruncate performance

[Hans Reiser]

Chris Mason wrote:

>On Tue, 2003-07-22 at 12:43, Hans Reiser wrote:
>  
>
>>The answer to the below is to use reiser4.  It uses extents, and two 64 
>>bit numbers are all that is needed to store the hole.  V4 will be ready 
>>for testing in a few days, and will ship for real users at the end of 
>>summer we hope.
>>
>>Fixing V3 is  the wrong answer: this is one of its design flaws.
>>    
>>
>
>It's important to remember that releasing v4 doesn't automatically
>convert all existing v3 users to it.  This is the kind of thing we
>should try to fix without making major design changes to v3.  It's at
>least worth talking about, "use v4" can't always be the answer.
>
V3 is in feature freeze.   Unfortunately, determining what is a feature 
and what is a bug is a process based not just on the user experience, 
but on the structure of the code.  The proper fix for this bug is to add 
a feature called extents.   This  belongs in, and is in, V4.  V4 will be 
available very soon.

Adding features, like new kinds of items, will disturb the stability of 
V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime 
where conservatism is appropriate.

>
>-chris
>
>
>
>
>  
>


-- 
Hans

Re: Horrible ftruncate performance

[Chris Mason]

On Tue, 2003-07-22 at 14:09, Hans Reiser wrote:

> >It's important to remember that releasing v4 doesn't automatically
> >convert all existing v3 users to it.  This is the kind of thing we
> >should try to fix without making major design changes to v3.  It's at
> >least worth talking about, "use v4" can't always be the answer.
> >
> V3 is in feature freeze.   Unfortunately, determining what is a feature 
> and what is a bug is a process based not just on the user experience, 
> but on the structure of the code.  The proper fix for this bug is to add 
> a feature called extents.   This  belongs in, and is in, V4.  V4 will be 
> available very soon.
> 
> Adding features, like new kinds of items, will disturb the stability of 
> V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime 
> where conservatism is appropriate.
> 

Heh, everything needs to be zero defect ;-)  But I completely agree
about not adding new item types or other format changes.  Still,
non-extent filesystems can create holes faster than we can, so it is
worth talking about ways to fix it (within the constraints of existing
code).

-chris

Re: Horrible ftruncate performance

[Oleg Drokin]

Hello!

On Tue, Jul 22, 2003 at 02:24:09PM -0400, Chris Mason wrote:
 
> Heh, everything needs to be zero defect ;-)  But I completely agree
> about not adding new item types or other format changes.  Still,
> non-extent filesystems can create holes faster than we can, so it is
> worth talking about ways to fix it (within the constraints of existing
> code).

Yeah, we really can insert items with the actual data in the tree
(as I already discussed with Chris). (No, not one item per one pointer,
that will be messy). That should work, I think.

No, that won't hurt reiser4, because the key strenght of the reiser4 is the
throughput and online repacker.
Today the Linus have proclaimed that he really needs the online repacker because
he got tired by inter-file fragmentation (as opposed to in-file
fragmentation) and he really looks forward for someone who
can deliwer XP-like feature of grouping data
based on the previous read-patterns.

Bye,
    Oleg

Re: Horrible ftruncate performance

[Voicu Liviu]

Hans Reiser wrote:
> Oleg Drokin wrote:
> 
>> Hello!
>>
>> On Tue, Jul 22, 2003 at 02:24:09PM -0400, Chris Mason wrote:
>>
>>  
>>
>>> Heh, everything needs to be zero defect ;-)  But I completely agree
>>> about not adding new item types or other format changes.  Still,
>>> non-extent filesystems can create holes faster than we can, so it is
>>> worth talking about ways to fix it (within the constraints of existing
>>> code).
>>>   
>>
>>
>> Yeah, we really can insert items with the actual data in the tree
>> (as I already discussed with Chris). (No, not one item per one pointer,
>> that will be messy). That should work, I think.
>>
>> No, that won't hurt reiser4, because the key strenght of the reiser4 
>> is the
>> throughput and online repacker.
>>
> Online repacker is not the key strength, but it is a quite nice feature 
> that accentuates the other strengths.

Then what is the key strength? Or better to ask, how does V4 differs 
from V3?
Best regards,
Liviu

>> Today the Linus have proclaimed that he really needs the online 
>> repacker because
>> he got tired by inter-file fragmentation (as opposed to in-file
>> fragmentation) and he really looks forward for someone who
>> can deliwer XP-like feature of grouping data
>> based on the previous read-patterns.
>>
> that is a very nice feature, it is indeed quite important, and it also a 
> major work item that we have no sponsor for.  Unfortunately, it is a 
> non-focused feature (it helps everyone), and getting it sponsored will 
> be hard.
> 
>>
>> Bye,
>>    Oleg
>>
>>
>>  
>>
> 
> 


-- 
Voicu Liviu
Rothberg International School
Computation center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: pacman@mscc.huji.ac.il

System Operating: Linux Gentoo1.4 ( www.gentoo.org )

Click here to see my GPG signature:
	http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

Re: Horrible ftruncate performance

[Hans Reiser]

Chris Mason wrote:

>On Tue, 2003-07-22 at 14:09, Hans Reiser wrote:
>
>  
>
>>>It's important to remember that releasing v4 doesn't automatically
>>>convert all existing v3 users to it.  This is the kind of thing we
>>>should try to fix without making major design changes to v3.  It's at
>>>least worth talking about, "use v4" can't always be the answer.
>>>
>>>      
>>>
>>V3 is in feature freeze.   Unfortunately, determining what is a feature 
>>and what is a bug is a process based not just on the user experience, 
>>but on the structure of the code.  The proper fix for this bug is to add 
>>a feature called extents.   This  belongs in, and is in, V4.  V4 will be 
>>available very soon.
>>
>>Adding features, like new kinds of items, will disturb the stability of 
>>V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime 
>>where conservatism is appropriate.
>>
>>    
>>
>
>Heh, everything needs to be zero defect ;-)  But I completely agree
>about not adding new item types or other format changes.  Still,
>non-extent filesystems can create holes faster than we can,
>
by using a format that is better designed for large holes....

> so it is
>worth talking about ways to fix it (within the constraints of existing
>code).
>
>-chris
>
>
>
>
>  
>

V4 is going out for outside testers this week.  It blows v3 away in 
performance, space usage, well structured code, scalability, features, 
everything really.  The only reason to use V3 is that it is highly debugged.

V4 is a nice example of what you can't easily do incrementally (unless, 
of course, you have the plugin infrastructure V4 has.;-) ).

-- 
Hans

Re: Horrible ftruncate performance

[Hans Reiser]

Oleg Drokin wrote:

>Hello!
>
>On Tue, Jul 22, 2003 at 02:24:09PM -0400, Chris Mason wrote:
> 
>  
>
>>Heh, everything needs to be zero defect ;-)  But I completely agree
>>about not adding new item types or other format changes.  Still,
>>non-extent filesystems can create holes faster than we can, so it is
>>worth talking about ways to fix it (within the constraints of existing
>>code).
>>    
>>
>
>Yeah, we really can insert items with the actual data in the tree
>(as I already discussed with Chris). (No, not one item per one pointer,
>that will be messy). That should work, I think.
>
>No, that won't hurt reiser4, because the key strenght of the reiser4 is the
>throughput and online repacker.
>
Online repacker is not the key strength, but it is a quite nice feature 
that accentuates the other strengths.

>Today the Linus have proclaimed that he really needs the online repacker because
>he got tired by inter-file fragmentation (as opposed to in-file
>fragmentation) and he really looks forward for someone who
>can deliwer XP-like feature of grouping data
>based on the previous read-patterns.
>
that is a very nice feature, it is indeed quite important, and it also a 
major work item that we have no sponsor for.  Unfortunately, it is a 
non-focused feature (it helps everyone), and getting it sponsored will 
be hard.

>
>Bye,
>    Oleg
>
>
>  
>


-- 
Hans

Re: Horrible ftruncate performance

[Voicu Liviu]

Hans Reiser wrote:
> Voicu Liviu wrote:
> 
>>
>> Then what is the key strength? Or better to ask, how does V4 differs 
>> from V3?
>> Best regards,
>> Liviu
> 
> 
> Plugins.  Raw performance, of which the repacker is just an aspect.
> 
Thank you very much

-- 
Voicu Liviu
Rothberg International School
Computation center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: pacman@mscc.huji.ac.il

System Operating: Linux Gentoo1.4 ( www.gentoo.org )

Click here to see my GPG signature:
	http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

Re: Horrible ftruncate performance

[Hans Reiser]

Voicu Liviu wrote:

>
> Then what is the key strength? Or better to ask, how does V4 differs 
> from V3?
> Best regards,
> Liviu

Plugins.  Raw performance, of which the repacker is just an aspect.

-- 
Hans

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Dienstag, 22. Juli 2003 20:09 schrieb Hans Reiser:
> Chris Mason wrote:
> >On Tue, 2003-07-22 at 12:43, Hans Reiser wrote:
> >>The answer to the below is to use reiser4.  It uses extents, and two 64
> >>bit numbers are all that is needed to store the hole.  V4 will be ready
> >>for testing in a few days, and will ship for real users at the end of
> >>summer we hope.
> >>
> >>Fixing V3 is  the wrong answer: this is one of its design flaws.
> >
> >It's important to remember that releasing v4 doesn't automatically
> >convert all existing v3 users to it.  This is the kind of thing we
> >should try to fix without making major design changes to v3.  It's at
> >least worth talking about, "use v4" can't always be the answer.
>
> V3 is in feature freeze.   Unfortunately, determining what is a feature
> and what is a bug is a process based not just on the user experience,
> but on the structure of the code.  The proper fix for this bug is to add
> a feature called extents.   This  belongs in, and is in, V4.  V4 will be
> available very soon.

And "coplete" stable from the beginning? --- Come on.

> Adding features, like new kinds of items, will disturb the stability of
> V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime
> where conservatism is appropriate.

I'll accept this fix in V3 before I "move" to V4.

-Dieter

Re: Horrible ftruncate performance

[Hans Reiser]

Dieter Nützel wrote:

>Am Dienstag, 22. Juli 2003 20:09 schrieb Hans Reiser:
>  
>
>>Chris Mason wrote:
>>    
>>
>>>On Tue, 2003-07-22 at 12:43, Hans Reiser wrote:
>>>      
>>>
>>>>The answer to the below is to use reiser4.  It uses extents, and two 64
>>>>bit numbers are all that is needed to store the hole.  V4 will be ready
>>>>for testing in a few days, and will ship for real users at the end of
>>>>summer we hope.
>>>>
>>>>Fixing V3 is  the wrong answer: this is one of its design flaws.
>>>>        
>>>>
>>>It's important to remember that releasing v4 doesn't automatically
>>>convert all existing v3 users to it.  This is the kind of thing we
>>>should try to fix without making major design changes to v3.  It's at
>>>least worth talking about, "use v4" can't always be the answer.
>>>      
>>>
>>V3 is in feature freeze.   Unfortunately, determining what is a feature
>>and what is a bug is a process based not just on the user experience,
>>but on the structure of the code.  The proper fix for this bug is to add
>>a feature called extents.   This  belongs in, and is in, V4.  V4 will be
>>available very soon.
>>    
>>
>
>And "coplete" stable from the beginning? --- Come on.
>
I have been consistently clear in everything I say that V4 will not be 
as stable as V3 for quite some time.  That is because V3 will not 
significantly change except for bug fixes, whereas V4 is fresh new code.

V3 has been dropping in bug reports for quite some time.  Unfortunately 
I have to say we got some this month (direct IO stuff).

>
>  
>
>>Adding features, like new kinds of items, will disturb the stability of
>>V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime
>>where conservatism is appropriate.
>>    
>>
>
>I'll accept this fix in V3 before I "move" to V4.
>
>-Dieter
>
>
>
>  
>
Most users need for their filesystems to at some point finally get left 
alone and not disturbed.  This is the whole idea behind freeze and 
release based development.

Extents are a nice feature, but they belong in V4 not V3.   Effort spent 
developing extents for V3 is better spent stabilizing V4 which already 
has them and a lot more.

-- 
Hans

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Mittwoch, 23. Juli 2003 15:39 schrieb Hans Reiser:
> Dieter Nützel wrote:
> >Am Dienstag, 22. Juli 2003 20:09 schrieb Hans Reiser:
> >>Chris Mason wrote:
> >>>On Tue, 2003-07-22 at 12:43, Hans Reiser wrote:

[-]

> >>V3 is in feature freeze.   Unfortunately, determining what is a feature
> >>and what is a bug is a process based not just on the user experience,
> >>but on the structure of the code.  The proper fix for this bug is to add
> >>a feature called extents.   This  belongs in, and is in, V4.  V4 will be
> >>available very soon.
> >
> >And "coplete" stable from the beginning? --- Come on.
>
> I have been consistently clear in everything I say that V4 will not be
> as stable as V3 for quite some time.  That is because V3 will not
> significantly change except for bug fixes, whereas V4 is fresh new code.

Yes OK, we all know that and it is _right_. 

> V3 has been dropping in bug reports for quite some time.  Unfortunately
> I have to say we got some this month (direct IO stuff).

I know this.
Andrea Arcangeli's -aa kernels have direct-IO for ages.

> >>Adding features, like new kinds of items, will disturb the stability of
> >>V3.  V3 needs to be zero defect.  It is now in a phase in its lifetime
> >>where conservatism is appropriate.
> >
> >I'll accept this fix in V3 before I "move" to V4.
> >
> >-Dieter
>
> Most users need for their filesystems to at some point finally get left
> alone and not disturbed.  This is the whole idea behind freeze and
> release based development.

Very true.

> Extents are a nice feature, but they belong in V4 not V3.

Nobody asked about extents fro V3.

> Effort spent
> developing extents for V3 is better spent stabilizing V4 which already
> has them and a lot more.

Yes. But we have OSS.
If someone have some time...

Hans, please do not do "full quotes" in mailing list.

Thank you!

-Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

Re: Horrible ftruncate performance

[Hans Reiser]

Dieter Nützel wrote:

>
>  
>
>>Extents are a nice feature, but they belong in V4 not V3.
>>    
>>
>
>Nobody asked about extents fro V3.
>  
>

Extents are the proper fix for hole performance.

-- 
Hans

Re: Horrible ftruncate performance

[Dieter Nützel]

Am Mittwoch, 23. Juli 2003 15:52 schrieb Hans Reiser:
> Dieter Nützel wrote:
> >>Extents are a nice feature, but they belong in V4 not V3.
> >
> >Nobody asked about extents fro V3.
>
> Extents are the proper fix for hole performance.

OK.

But V4 is for 2.5/2.6 only...

What are our options?

Regards,
	Dieter

Re: Horrible ftruncate performance

[Chris Mason]

On Wed, 2003-07-23 at 02:14, Hans Reiser wrote:
> >
> >Heh, everything needs to be zero defect ;-)  But I completely agree
> >about not adding new item types or other format changes.  Still,
> >non-extent filesystems can create holes faster than we can,
> >
> by using a format that is better designed for large holes....
> 

They have pointers to 4k blocks, we have pointers to 4k blocks, our
pointers should be able to do everything their pointers can do ;-)

> > so it is
> >worth talking about ways to fix it (within the constraints of existing
> >code).
> 
> V4 is going out for outside testers this week.  It blows v3 away in 
> performance, space usage, well structured code, scalability, features, 
> everything really.  The only reason to use V3 is that it is highly debugged.
> 

It's awesome that v4 is going out and has a number of features to
improve things over v3.  The point is that we need to show that once a
format has been chosen we can continue to support and improve the FS
within the confines of that format.  

If our only answer to bad performance is reformat with v4, or upgrade to
v4 (if some v3 plugin ever exists), then people lose confidence in our
ability to support the code we've written, and will assume they'll hit
the same problem with v4 later on.  We've got to show we are committed
not just to fixing bugs, but to keeping up with the baseline of expected
features/performance whenever possible.

The stable FS can't be buried just because the new unstable one happens
to be released ;-)

-chris

Re: Horrible ftruncate performance

[Hans Reiser]

Chris Mason wrote:

>On Wed, 2003-07-23 at 02:14, Hans Reiser wrote:
>  
>
>>>Heh, everything needs to be zero defect ;-)  But I completely agree
>>>about not adding new item types or other format changes.  Still,
>>>non-extent filesystems can create holes faster than we can,
>>>
>>>      
>>>
>>by using a format that is better designed for large holes....
>>
>>    
>>
>
>They have pointers to 4k blocks, we have pointers to 4k blocks, our
>pointers should be able to do everything their pointers can do ;-)
>
>  
>
If you have to write 200MB of zeros to a file instead of 32 bytes, 
performance is going to be bad no matter what you do.

We don't have resources for duplicating work, or even supporting 
duplicate work.  We don't have funding right now from anyone.

V4 works.  V4 is faster than anything else out there by a lot.  If we 
get it debugged, we might have one of those licenses in addition to the 
GPL come out of nowhere again, and survive.   We have no resources for 
any other activity besides debugging and shipping and promoting V4, or 
fixing V3 bugs.  Hole performance improvement using extents is a feature 
not a bug.

-- 
Hans

Re: Horrible ftruncate performance

[Philippe Gramoullé]

Hello Dieter,

On Wed, 23 Jul 2003 16:24:07 +0200
Dieter Nützel <Dieter.Nuetzel@hamburg.de> wrote:

  | > Extents are the proper fix for hole performance.
  | 
  | OK.
  | 
  | But V4 is for 2.5/2.6 only...
  | 
  | What are our options?

Well, hopefully, 2.6 will be released around the same time that ReiserFS V4 will
have been through its debug period.

So your options is to wait until 2.6/V4 is out or pay Namesys enough so that it
looks interesting to fix this in V3. :)

Bye,

Philippe

Re: Horrible ftruncate performance

[Chris Mason]

On Wed, 2003-07-23 at 10:55, Hans Reiser wrote:

> >They have pointers to 4k blocks, we have pointers to 4k blocks, our
> >pointers should be able to do everything their pointers can do ;-)
> >
> >  
> >
> If you have to write 200MB of zeros to a file instead of 32 bytes, 
> performance is going to be bad no matter what you do.
> 
> We don't have resources for duplicating work, or even supporting 
> duplicate work.  We don't have funding right now from anyone.
> 
> V4 works.  V4 is faster than anything else out there by a lot.  If we 
> get it debugged, we might have one of those licenses in addition to the 
> GPL come out of nowhere again, and survive.   We have no resources for 
> any other activity besides debugging and shipping and promoting V4, or 
> fixing V3 bugs.  Hole performance improvement using extents is a feature 
> not a bug.

Hans, my point is that other people might be interested in doing the
work and testing the code, or at least discussing ways to fix the
problem without format changes.  Please don't shoot these discussions
down, and give the people interested in improvements to v3 a chance to
discuss it.

v4 is beta and not in any way a viable choice for people today.  It
might end up being the coolest filesystem ever made, but we need to be
realistic about supporting the users we've already got.

-chris

Re: Horrible ftruncate performance

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2003-07-11 at 11:44, Oleg Drokin wrote:
>  
>
>>Hello!
>>
>>On Fri, Jul 11, 2003 at 05:34:12PM +0200, Marc-Christian Petersen wrote:
>>
>>    
>>
>>>>Actually I did it already, as data-logging patches can be applied to
>>>>2.4.22-pre3 (where this truncate patch was included).
>>>>        
>>>>
>>>>>Maybe it _IS_ time for this _AND_ all the other data-logging patches?
>>>>>2.4.22-pre5?
>>>>>          
>>>>>
>>>>It's Chris turn. I thought it is good idea to test in -ac first, though
>>>>(even taking into account that these patches are part of SuSE's stock
>>>>kernels).
>>>>        
>>>>
>>>Well, I don't think that testing in -ac is necessary at all in this case.
>>>      
>>>
>>May be not. But it is still useful ;)
>>
>>    
>>
>>>I am using WOLK on many production machines with ReiserFS mostly as Fileserver 
>>>(hundred of gigabytes) and proxy caches.
>>>      
>>>
>>I am using this code on my production server myself ;)
>>
>>    
>>
>>>If someone would ask me: Go for 2.4 mainline inclusion w/o going via -ac! :)
>>>      
>>>
>>Chris should decide (and Marcelo should agree) (Actually Chris thought it is good
>>idea to submit data-logging to Marcelo now, too). I have no objections.
>>Also now, that quota v2 code is in place, even quota code can be included.
>>
>>Also it would be great to port this stuff to 2.5 (yes, I know Chris wants this to be in 2.4 first)
>>    
>>
>
>Marcelo seems to like being really conservative on this point, and I
>don't have a problem with Oleg's original idea to just do relocation in
>2.4.22 and the full data logging in 2.4.23-pre4 (perhaps +quota now that
>32 bit quota support is in there).
>
I would like to see it go in more quickly.  I don't like significant 
lags between distro and mainline kernels in principle, and in reiserfs I 
would like to see the V3 code go mostly undisturbed after 2.4.22.  V3 
needs to become zero defect, and only a lack of changes other than 
bugfixes will make that happen.  Dribbling out changes slowly is not 
conducive to being zero defect, and V3 only has a certain window of 
usability anyway before V4 obsoletes it.

Let V3's niche be those who need zero defects, and let V4 be for those 
who want features and performance.

>2.5 porting work has restarted at last, Oleg's really been helpful with
>keeping the 2.4 stuff up to date.
>
>-chris
>
>
>
>
>  
>


-- 
Hans

Re: Horrible ftruncate performance

[Chris Mason]

On Sun, 2003-08-03 at 10:05, Hans Reiser wrote:

> I would like to see it go in more quickly.  I don't like significant 
> lags between distro and mainline kernels in principle, and in reiserfs I 
> would like to see the V3 code go mostly undisturbed after 2.4.22.  V3 
> needs to become zero defect, and only a lack of changes other than 
> bugfixes will make that happen.  Dribbling out changes slowly is not 
> conducive to being zero defect, and V3 only has a certain window of 
> usability anyway before V4 obsoletes it.
> 

v3 is installed on a large number of systems, and is storing a huge
amount of data.  It will not go away just because v4 is released.  The
v3 code will not be obsolete, it will still be heavy used and our users
will expect us to keep it up to date.

2.4.22 is pretty much frozen except for bug fixes, the rest of the data
logging code will have to wait for 2.4.23-pre

-chris