Teo, would it be possible for you to test it again with glusterfs--mainline--2.5 tree? This tree has a rewrite of the bail-out logic (more efficient and more accurate) and should not bail out unnecessarily as it used to happen in some intsances in the glusterfs--mainline--2.4 tree codebase. please note, glusterfs--mainline--2.5 is not 100% stable yet. I'm curious to know if your problem was actually only with the bailing out logic. thanks, avati 2007/6/25, Constantin Teodorescu <teo@xxxxxxx>:
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
-- Anand V. Avati
