Amar S. Tumballi wrote:
Hi Teo,
"option transport-timeout 20" is less. our default option itself is 120.
Can you increase it? may be around ~600?
-bulde
Done !
volume client1 # 1, 2 and 3 servers are all the same
type protocol/client
option transport-type tcp/client
option remote-host 64.34.25.3
option remote-port 6996
option remote-subvolume brick
option transport-timeout 600
end-volume
Restarted from ground ... no file, no database, created from scratch
glu=# update animal set observatii='ok1';
UPDATE 713268
glu=# vacuum;
VACUUM
glu=# update animal set observatii='ok2';
ERROR: could not read block 590 of relation
535356560/535356561/535356562: File descriptor in bad state
--------------------------------------
OK, let me tell you something real and nice ! :-)
There are 20 year ago, in the CP/M era , when my computer at work was a
8086 with 56 Kb of RAM (less than the worst GSM phone today) and the
'mass-storage' were 4 floppy disks 5 inch and 241 Ko size !
Because at that time I needed more for one application, I hacked the
CP/M code and wrote some sort of driver in assembler that took 2 disks
of 241 , apply a "unify translator" :-) and made a 482Ko
SUPER-FLOPPY-DRIVE available to all programs (especially dBASE-II at
that time) :))
So, you will understand now why I love 'glusterfs' and wanted to help to
make it better.
We have a functional Hadoop cluster here but we have plans to use
glusterfs for our next project. It's not going to be a remote-storage
for some database backup, it will be a mass-storage for various blob
objects and I feel that glusterfs could be a better solution for us.
Thank you all for your work,
Teo
