[Gluster-users] gluster(1.3.10) becomes unstable after some time

[Amar S. Tumballi]

Hi Roman,
 Sorry for the delay in response.

* The first problem I saw: After 20 minutes of some basic tests with
file copying gluster mount on all servers became unavailable.

Do you see any '/core*' files? this means the calls are bailing out, there
are three possible reasons.
 i) because of heavy disk i/o, response is getting delayed, hence the
default 'transport-timeout' option is not enough. Try higher values like
120.

 ii) a glusterfs process died, hence the clients couldn't connect to the
corresponding server process (unlikely in your case a new connection is made
again after call bail).

 iii) bug in glusterfs itself. in this case, we would like you to try 1.3.12
(latest 1.3.x release) or wait for another 10days for next pre release of
1.4 branch, which should work fine IMO.


> The second problem I see - even with  'option
> alu.read-only-subvolumes' gluster remains writing to the specified as
> read-only volumes. what could be the reason for this?
>

The reason for it is, the 'read-only-subvolumes' option is used for making
sure new files are not created on those two subvolumes. But if a file
already exists on those subvolumes then it continues to grow. If you don't
want any write to happen, you need to use filter.

Regards,
Amar

-- 
Amar Tumballi
Gluster/GlusterFS Hacker
[bulde on #gluster/irc.gnu.org]
http://www.zresearch.com - Commoditizing Super Storage!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080922/ca41ec50/attachment.html>