<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/03/2013 12:52 AM, Koleszár Ádám
wrote:<br>
</div>
<blockquote cite="mid:51836CD6.5030505@virtual-call-center.eu"
type="cite">Hi,
<br>
<br>
<br>
We have a problem with glusterFS. We are using it on Centos 5
machine with OpenVZ kernel. Gluster daemon and gluster clients run
on the host, not in the container. Recently we noticed a problem
when we upgraded the OpenVZ kernel. After the upgrade there are
strange errors in case of accessing the gluster volume. There are
a few folders that can't be seen with 'ls' but if you give the
whole path you can access the files in the folder. If there is a
folder with files in it and you type 'ls' it hangs and only can be
stopped with 'kill -9'.
<br>
<br>
We are using glusterfs 3.2.5 but we have tried with 3.2.7 and the
same happened.
<br>
With kernel version: 2.6.18-308.el5.028stab099.3 -- there were no
errors.
<br>
With kernel version: 2.6.18-348.3.1.el5.028stab106.2 -- it has the
above mentioned errors
<br>
<br>
Unfortunately we don't have any information about the other
kernels between the two versions. We can reproduce the errors in
production and development environments. We created a new volume
on our own test computers but we cannot reproduce the bugs. If we
mount the development gluster volume on the test computers which
are running the 2.6.18-348.3.1.el5.028stab106.2 OVZ kernel we
cannot reproduce the bug. That's why we think the gluster clients
work with the new kernel but the gluster daemon doesn't.
<br>
<br>
</blockquote>
It's the ext4 problem:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/">http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/</a><br>
<br>
Backported to el5 as of 2.6.18-326.el5
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>