[Gluster-devel] Some problems reproduced (strace, test code etc.)

[Mike Machuidel]

Hi Anand,

(Had to send it again. This time to the mailing list as well)

I built the latest version of the FUSE kernel module with some of
Miklos Szeredi his patches applied (very quick and dirty). I got the
following results:

- The shared writable mmap bug is gone. "apt-get update" seems to work.
- Batched page writes using fuse_writepages is supported but not yet
being used by GlusterFS. May be you can give me some pointers how to test it.
- The error when using "cat <<EOF" in a chrooted environment is still
occurring. I know you are working on it.

You can find the source of the modified FUSE kernel module with the
patches applied at:
http://www.satl.com/~machuidel/glusterfs/fuse/fuse-shared-mmap-writepages.tar.gz

I tested it with Linux 2.6.20 as distributed in Ubuntu Feisty. Debian
Sarge (2.6.18) might work as well.

Would be nice to play with these features before the time they are
officially supported.

Machuidel

On 5/25/07, Anand Avati <avati at zresearch.com> wrote:
> >
> > 1) Okay. I found the following patch (might be related?):
> > http://lkml.org/lkml/2007/2/27/304
> >
> > I will try and let you know if it worked.
>
> excellent! i'm curious to know your results.
>
> > 2) When doing "dd if=/dev/zero of=test" on an non-gluster filesystem I
> > get a much higher throughput (around 90 MB/s). Of course I can imagine
> > this is caused by frequent kernel/user-space context switches and also
> > read on the GlusterFS and FUSE roadmap this will be improved soon.
> > I'm wondering how Hurd will do in this regard.
>
>
> "dd if=/dev/zero of=test" without a big bs= value will be slow on
> *any* fuse based filesytems. i saw a few patches related to batch
> writepages support into fuse which would likely improve the
> performance a lot. infact i just wrote to the fuse-devel mailing list
> asking if this was on the way anytime.
>
> > 3) It only happens in a chrooted environment on a gluster filesystem.
>
> ah ok, looking into it.
>
> thanks!
> avati
>
>
> --
> Anand V. Avati
>