On 11/18/2010 07:28 AM, Barry Jaspan wrote:
> On Thu, Nov 18, 2010 at 9:41 AM, Anand Avati<anand.avati at gmail.com> wrote:
>
>> FUSE based filesystems have to face the unfortunate overhead of context
>> switches between application and the filesystem process.
>
> Gluster 2.x had a library named "booster" that bypassed the FUSE layer by
> providing implementations of all the filesystem syscalls that recognized
> glusterfs file descriptors and went directly to the glusterfs code instead
> of the kernel for those operations.
>
> Why was booster removed from Gluster 3.x?
>
> Barry
Barry,
Booster was unstable by many reasons. I have did extensive tests to
see the difference in throughput based with booster. It revealed that
bypassing FUSE in itself didn't give much performance improvement,
actually there were no improvements at all. There were calls like
OPENDIR, READDIR which were slow and snaggy to respond, where as native
FUSE was far better.
Context switch overhead for small file performance from a network
perspective was high enough
to mask the context with FUSE and VFS layers. So it doesn't matter if
you bypass FUSE it still hits high on network latency, but in generality
CPU speed matters for context switching performance.
We used taskset to some extent for small file performance to provide
more CPU affinity for network i/o for glusterfsd if the user is
primarily a small file workload. It helps to an extent, but things can
be different many times under different workloads.
NFS native solves it to large extent with its aggressive client side
caching of many attributes, since stats are served locally for NFS client.
Booster never evolved much more and we saw the side effects. Since the
problem is elsewhere, so eventually it has to be dropped.
Regards
--
Harshavardhana
Gluster Inc - http://www.gluster.com
+1(408)-770-1887, Ext-113
+1(650)-318-1751
