-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dan wrote:
> The thing is that it isn't possible to have a perfectly synced remote
> copy of a filesystem at every single moment unless they are tied
> together in something like raid1 and all writes are syncronos, which
> would be murder on performanc
The thing is that it isn't possible to have a perfectly synced remote copy
of a filesystem at every single moment unless they are tied together in
something like raid1 and all writes are syncronos, which would be murder on
performance. Otherwise, there will always be a delay for the remote sync.
a
dan wrote:
> if its the server that the write was going to, its lost. if it is the
> remote server, then it will resync when it is back online.
Being able to recover from a complete loss of the local server at any
point in time (building disaster, software/operator error, etc.) is
pretty much
if its the server that the write was going to, its lost. if it is the
remote server, then it will resync when it is back online.
On Fri, Jul 11, 2008 at 1:07 AM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> dan wrote:
>
> you can also
>> write directly to the exported directory without using the g
dan wrote:
> you can also
> write directly to the exported directory without using the gluster layer! so
> you can skip any IO slowdown from fuse on the primary box! gluster will keep
> them synced up! and gluster can run over compressed ssh tunnels!
What happens if the server dies before the co
Has anyone every tried using backuppc with gluster?
I have setup a quick glusterfs on some test rigs and find it to be a very
very interesting filesystem.
gluster does run under fuse but performs like a native filesystem. I get
11.7MB/s on a 100Mb line, which is just as fast as iscsi. I can eve
