Hi
>> Is there any problem in having both the gluster file system
>> mounted in the traditional way and booster using the same
>> 'mount point' ?
>
> Due to some system calls not being handling by Gluster - I think I would
> suggest it.
>
> It's not perfect - but at least any calls that fall through will still
> be handled properly.
My intention was this ... but i just wanted to be sure that this will
have no conflicts, specially when a file descriptor obtained in one
non supported syscall is used in one supproted syscall or viceversa
> For example, if an application calls fopen(), which
> is not on the GlusterFS list of overridden system calls the last time I
> checked, then at least the fopen() will be intercepted by FUSE rather
> than fail altogether.
as far as i know fopen is not a syscall is a libc function that
is suposed to internally use open, so it should also work with
booster too
> One poster (not sure if it was you) suggested that they access the local
> volume directly, rather than through a server.
not me i think, but if you mean by access the local volume directly to
diretly access the disk totally bypassing glusterfs we actually do that
when we need read only access from within the server itself as in our
application most data is read only and other data is never read before
it's totally written and is never modified once created, for writing we
always use the gluster volume for replication to work.
--
Best regards ...
----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. telf +34 902 50 29 75
----------------------------------------------------------------
