Reiser4 performance bottlenecks and possible solutions

["Xu CanHao" <xucanhao@xxxxxxxxx>]

Hello!

Since performance is one of the most important aspect of Reiser4, I
indeed encountered some performance bottlenecks of Reiser4 during my
daily usage. The following is my own(possibly wrong) experiences:

1, Tail-conversion/Extent-only
May save space at a 5-10 percent, while impacts performance much more
greater. Extent-only performs better.

2, read()...
Old read_unix_file() is not efficient, especially in
read_unix_file_container_tails(). So I think generic_file_read() is
better for Extent-only users.

1+2, Extent-only + generic_file_read()
During my benchmark, 1+2 provides 10%-400% better performance(varies
with the benchmark utility)

3, fsync()
Terrible fsync() performance has been talked for a thousand times
without a full solution. I'm thinking of a temporary solution: adding
a mount option and let the user determine the fsync() frequency(yes,
you may lose data when power-fail), things like:

int sync_unix_file(struct file *file, struct dentry *dentry, int datasync)
{
     reiser4_context *ctx;
     txn_atom *atom;
     reiser4_block_nr reserve;
     reiser4_super_info_data *sbinfo;

     ctx = init_context(dentry->d_inode->i_sb);
     if (IS_ERR(ctx))
             return PTR_ERR(ctx);

     sbinfo = get_current_super_private();
     if (sbinfo->fsync == 0)
     {
             reiser4_exit_context(ctx);
             return 0;
     }
     else if (sbinfo->fsync == 1)
     {
fsync_file:     reserve = estimate_update_common(dentry->d_inode);
             if (reiser4_grab_space(reserve, BA_CAN_COMMIT)) {
                     reiser4_exit_context(ctx);
                     return RETERR(-ENOSPC);
             }
             write_sd_by_inode_common(dentry->d_inode);

             atom = get_current_atom_locked();
             spin_lock_txnh(ctx->trans);
             force_commit_atom(ctx->trans);
             reiser4_exit_context(ctx);
             return 0;
     }
     else if (sbinfo->fsync > 1)
     {
             fsync_num++;
             if (fsync_num >= sbinfo->fsync) {
                     fsync_num = 0;
                     goto fsync_file;
             }
             reiser4_exit_context(ctx);
             return 0;
     }
     return 0;
}

you may use "#mount /dev/sda1 /mnt/tmp -o fsync=10" which means "fsync
once when invoked fsync 10 times"

4, Relocation/Overwrite
Should you take 1+2 the default value 64 of flush.relocate_threshold
and flush.relocate_distance may not suitable, a lower value maybe
better for most case.

1+2+3+4
If you take all of them, the performance gain would be dramatically
and still as stable as before, at least for my months of experience.

Thanks!
-
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html