[Gluster-devel] Buggy writebehind translators !!!

[Constantin Teodorescu]

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