[Gluster-devel] Buggy writebehind translators !!!

[Anand Avati]

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 at flex.ro>:
>
> 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