gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Buggy writebehind translators !!!


From: Anand Avati
Subject: Re: [Gluster-devel] Buggy writebehind translators !!!
Date: Wed, 4 Jul 2007 17:03:57 +0530

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 <address@hidden>:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]