On Tue, Apr 19, 2011 at 06:00:28PM +0200, Vincent Thomasset wrote:
> My idea is currently to run it on the same machines in the cluster that
> actually need storage, so that each machine would indeed use a local
> mount, so that i could reuse the existing, and large, storage space
> available without hassle (one of the things that make glusterfs pretty
> cool to deploy on existing clusters IMO).
>
> But i don't see how this could be a problem, isn't the glusterfs mount the
> so called native client method or did i get the doc wrong ?
You can have the local mount be directly as ext3/4, in which case gluster
doesn't replicate simultaneously when you write to it. Or you can also have
the local mount be "-t glusterfs", in which case it does. At least in my
testing.
So I have a machine that's half a gluster mirror with a directory at
/mnt/somedir that's formatted ext4 and given to gluster. Then gluster is
exporting the filesystem as /somedir (because I reused the name), and it can
be locally mounted with:
mount -t glusterfs localhost:/somedir /mnt/tmp
Now if I look at my filesystems with df I get
/dev/mapper/volname-somedir
309637120 118580172 175328308 41% /mnt/somedir
localhost:/somedir 309637120 118580224 175328256 41% /mnt/tmp
(That first is because gluster's using a filesystem on an lvm in my case.)
Both /mnt/somedir and /mnt/tmp have the same files in them. But anything I
write to /mnt/tmp/ gets instantly replicated to the mirror, because it's
going through the gluster client handling the mount. Anything I write to
/mnt/somedir does not get instantly replicated, because it's mounted
directly, without gluster being aware of what I'm doing until something
triggers gluster later to look at that particular file.
Best,
Whit
