zfs-fuse-2009.06.03-3.tar.bz2

[Emmanuel Anne]

As asked in a previous mail, here is the complete tarball of what I currently have.
This tarball contains a more efficient patch for the "ever returning crash".
Explanation :
in this version when there is an async write (which means when a write is blocked before it could write everything to disk, usually because of too much disk activity at the same time), then zfs-fuse creates a special task list to process the async operations.
The problem is that this task list can accept only n concurrent async writes (4 at the begining, then I had put 12, and finally 14).
So I have finally found a more efficient patch for this, when it reserves the task, there is a flag to say what to do in case the limits are reached, and you can tell it to never fail. So this is what I did.

Anyway 14 is already very high, I have tested 14 on 24 hours with a lot of disk activity and 2 mirrorings and no crash, so it shouldn't even reach this new limit normally.

Now clearly this thing doesn't work the same way in the opensolaris kernel, because 4 is ridiculously low with fuse and you reach it so often that it's totally useless, so the kernel probably has a way to execute these async operations faster.

Anyway to sum up this thing should be as stable as possible for now.

attached tar.bz2 file.
(didn't test with fuse-2.8 yet).

[Rudd-O]

Emmannuel

Can you please stop publishing tarballs and start publishing patches?
I'm managing a mercurial repository here for everyone to use, since
Ricardo seems missing in actino, and it's TOO HARD to use tarballs to
determine what has changed.

Please. And use version control. Clone my tree and make your changes
in your clone, and commit frequently. Send me bundles or hg diffs
(bundles are preferable, honestly), so I can push them to the repo
with proper attribution and validation.

>  zfs-fuse-2009.06.03-3.tar.bz2
> 1542 KVerDescargar

[Rudd-O]

This is what I understand this tarball contains:

- The original vvatashki tarball
- Your first and second patch (well, the second patch included the
first one, you should have published them as independent patches, not
issued a second one including the first, but well)
- Some other modifications that I am unfamiliar with, with the fix for
the 4 turning into 14 that I don't understand.

If I am correct, please generate a patch with the last bug fix, and
post it to the list. If I am wrong, correct me please.

[Rudd-O]

BTW, if I was correct, then the patch that people need to apply on top
of your earlier diff2 patch is nothing but this:

----------------------------------------------------

diff -r 0fc42d5d533e src/lib/libsolkerncompat/vnode.c
--- a/src/lib/libsolkerncompat/vnode.c Mon Jul 13 21:16:22 2009 -0500
+++ b/src/lib/libsolkerncompat/vnode.c Mon Jul 13 22:10:39 2009 -0500
@@ -667,7 +667,7 @@
if (vp->v_count == 1) {
mutex_exit(&vp->v_lock);
VERIFY(taskq_dispatch(taskq, (task_func_t *)vn_rele_inactive,
- vp, TQ_SLEEP) != 0);
+ vp, UMEM_NOFAIL) != 0);
return;
}
vp->v_count--;
diff -r 0fc42d5d533e src/lib/libzpool/dsl_pool.c
--- a/src/lib/libzpool/dsl_pool.c Mon Jul 13 21:16:22 2009 -0500
+++ b/src/lib/libzpool/dsl_pool.c Mon Jul 13 22:10:39 2009 -0500
@@ -91,7 +91,7 @@
mutex_init(&dp->dp_scrub_cancel_lock, NULL, MUTEX_DEFAULT, NULL);

dp->dp_vnrele_taskq = taskq_create("zfs_vn_rele_taskq", 1,
minclsyspri,
- 1, 12, 0);
+ 1, 14, 0);

return (dp);
}
diff -r 0fc42d5d533e src/zfs-fuse/cmd_listener.c
--- a/src/zfs-fuse/cmd_listener.c Mon Jul 13 21:16:22 2009 -0500
+++ b/src/zfs-fuse/cmd_listener.c Mon Jul 13 22:10:39 2009 -0500
@@ -41,7 +41,7 @@

boolean_t exit_listener = B_FALSE;

-int cmd_ioctl_req(int sock, zfsfuse_cmd_t *cmd)
+static int cmd_ioctl_req(int sock, zfsfuse_cmd_t *cmd)
{
dev_t dev = {0};

-----------------------------------------------------

I have checked this in as revision:

http://git.rudd-o.com/zfs/rev/8169168334b7

in my mercurial repo.

You make whitespace changes in your code dumps that I have to revert
manually. Please try not to make unnecessary whitespace changes
because they increase by much the possibiilty that code merges and
patches fail.

We appreciate your work.

[Emmanuel Anne]

Ok, ok the tarball was asked by somebody, I prefer patches too usually.
I'll try to learn how to use mercurial, it's a promise ! ;-)

(you're right for the final patch, it was quite long to find, but very short in the end, and for the whitespace stuff, usually I clean this up before sending the patches, but here of course you got everything !).

2009/7/14 Rudd-O <rud...@rudd-o.com>

[Rudd-O]

No prob :-)