<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
Hi all,<BR>
<BR>
For the PHP script with little write/read accesses I will try to find it (I dont remember exactly the syntax), but for PHP Sessions, the bug could be easily reproduced.<BR>
<BR>
I just test it on a new very simple GlusterFS partition with no trafic (juste me), and I reproduced it immediatly.<BR>
<BR>
Explainations:<BR>
- 2 servers Debian Lenny stable<BR>
- GlusterFS 3.0.0 in distributed mode (one server and multiple clients)<BR>
- Lighttpd / PHP5 Fast-CGI<BR>
<BR>
I juste mount the GlusterFS partition on the /var/www directory.<BR>
<BR>
First of all, the PHP script you can execute:<BR>
<BR>
&lt;?php<BR>
session_save_path('.');<BR>
//if you want to verify if it worked<BR>
//echo session_save_path();<BR>
session_start();<BR>
?&gt;<BR>
<BR>
Secondly, there are 2 configurations if GlusterFS and, of course, one works and one does not.<BR>
The client configuration is the same in the both cases:<BR>
<BR>
glusterfs.vol<BR>
<I>volume test-1</I><BR>
<I>&nbsp;&nbsp;&nbsp; type protocol/client</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport-type tcp</I><BR>
<I>&nbsp;&nbsp;&nbsp; option remote-host test</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.socket.nodelay on</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.remote-port 6996</I><BR>
<I>&nbsp;&nbsp;&nbsp; option remote-subvolume brick1</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume writebehind</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/write-behind</I><BR>
<I>&nbsp;&nbsp;&nbsp; option cache-size 4MB</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes test-1</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume readahead</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/read-ahead</I><BR>
<I>&nbsp;&nbsp;&nbsp; option page-count 4</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes writebehind</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume iocache</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/io-cache</I><BR>
<I>&nbsp;&nbsp;&nbsp; option cache-size 1GB</I><BR>
<I>&nbsp;&nbsp;&nbsp; option cache-timeout 1</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes readahead</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume quickread</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/quick-read</I><BR>
<I>&nbsp;&nbsp;&nbsp; option cache-timeout 1</I><BR>
<I>&nbsp;&nbsp;&nbsp; option max-file-size 64kB</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes iocache</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume statprefetch</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/stat-prefetch</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes quickread</I><BR>
<I>end-volume</I><BR>
<BR>
Now the server configuration:<BR>
<BR>
glusterfsd.vol (this doesnt work)<BR>
<I>volume posix1</I><BR>
<I>&nbsp; type storage/posix</I><BR>
<I>&nbsp; option directory /data</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume locks1</I><BR>
<I>&nbsp;&nbsp;&nbsp; type features/locks</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes posix1</I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume brick1</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/io-threads</I><BR>
<I>&nbsp;&nbsp;&nbsp; option thread-count 8</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes locks1 </I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume server-tcp</I><BR>
<I>&nbsp;&nbsp;&nbsp; type protocol/server</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport-type tcp</I><BR>
<I>&nbsp;&nbsp;&nbsp; option auth.addr.brick1.allow *</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.socket.listen-port 6996</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.socket.nodelay on</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes brick1</I><BR>
<I>end-volume</I><BR>
<BR>
glusterfsd.vol (this works)<BR>
<I>volume posix1</I><BR>
<I>&nbsp; type storage/posix</I><BR>
<I>&nbsp; option directory /data</I><BR>
<I>end-volume</I><BR>
<BR>
<I>#volume locks1</I><BR>
<I>#&nbsp;&nbsp;&nbsp; type features/locks</I><BR>
<I>#&nbsp;&nbsp; subvolumes posix1</I><BR>
<I>#end-volume</I><BR>
<BR>
<I>volume brick1</I><BR>
<I>&nbsp;&nbsp;&nbsp; type performance/io-threads</I><BR>
<I>&nbsp;&nbsp;&nbsp; option thread-count 8</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes posix1 </I><BR>
<I>end-volume</I><BR>
<BR>
<I>volume server-tcp</I><BR>
<I>&nbsp;&nbsp;&nbsp; type protocol/server</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport-type tcp</I><BR>
<I>&nbsp;&nbsp;&nbsp; option auth.addr.brick1.allow *</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.socket.listen-port 6996</I><BR>
<I>&nbsp;&nbsp;&nbsp; option transport.socket.nodelay on</I><BR>
<I>&nbsp;&nbsp;&nbsp; subvolumes brick1</I><BR>
<I>end-volume</I><BR>
<BR>
So, with the locks translator, you can execute the script one time (it will be ok) but the second time the session file is on the file system but locked and nobody can access to it. PHP freezes and processes coult not be killed.<BR>
<BR>
When it's happened, I have nothing in client-side logs but I have 2 kinds of message in the server-side logs:<BR>
When I execute the script:<BR>
<I>[2010-02-04 21:11:22] W [posix.c:246:posix_lstat_with_gen] posix1: Access to /data//.. (on dev 2049) is crossing device (64768)</I><BR>
<I>[2010-02-04 21:11:24] W [posix.c:246:posix_lstat_with_gen] posix1: Access to /data//.. (on dev 2049) is crossing device (64768)</I><BR>
<BR>
When I try to umount -f (disconnect the gluster):<BR>
<I>[2010-02-04 21:13:45] E [server-protocol.c:339:protocol_server_reply] protocol/server: frame 20: failed to submit. op= 26, type= 4</I><BR>
<BR>
As I said I will try to find the other PHP script.<BR>
<BR>
I hope this will help you.<BR>
<BR>
Thanks for your hard work, GlusterFS is a great project.<BR>
<BR>
Regards.<BR>
<BR>
Le jeudi 04 f&#233;vrier 2010 &#224; 11:25 -0600, Tejas N. Bhise a &#233;crit :
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Samuel,

This problem is important for us to fix. We have heard of this from 2-3 users. It seems to be a combination of apache, php session files shared by multiple apache servers and locking ( or lock translator ). 

We have tried very hard to reproduce this with test programs that read/write very small files across multiple clients ( to mimic behaviour of shared php session files ). We even tried this using sample programs ( even jmeter ) using php sessions - but we were not able to reproduce it.

Are you able to reproduce it easily ? If so, we would request you to help us reproduce this inhouse or else help us with some tracing from your system - ( disclaimer - the tracing could slow down the system a bit :-) ) ..

Maybe we can start with using your test script - please let us know what gluster config, machine config/type etc you used so we can try something as close as possible.

Thank you for your help in making the product better.

Regards,
Tejas.




----- Original Message -----
From: &quot;Samuel Hassine&quot; &lt;<A HREF="mailto:samuel.hassine@gmail.com">samuel.hassine@gmail.com</A>&gt;
To: &quot;Gluster List&quot; &lt;<A HREF="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</A>&gt;
Cc: &quot;Yann Autissier&quot; &lt;<A HREF="mailto:yann.autissier@anotherservice.com">yann.autissier@anotherservice.com</A>&gt;
Sent: Thursday, February 4, 2010 8:14:34 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: [Gluster-devel] Feedback - Problem with the locks feature

Hi all,

Just a little feedback about a special using of GlusterFS.

We are hosting about 15 000 websites on an infrastructure containing a
big files server. We just change our files sharing system from NFS to
GlusterFS. So we are using a simple distributed GlusterFS for the
websites files. We are alo using a second GlusterFSd instance (on an
alternate port) in order to export a special partition for PHP sessions.

On the first partition, it seems to work very well for reading and
writing. But on the second one, with a &quot;classic&quot; server configuration
(posix vol, locks vol, performance vol and server vol), the file system
freezes immediatly. After some tests, we found that it works fine
without the locks volume.

But after some other tests on the first GlusterFS, we discover that the
same problem could occured with a script that writes many little files
on the FS. It is the same problem with the last version of ezpublish,
the cache generation failed).

Do you think it could be fixed in the next versions or just bypassing
the locks translator is a good solution?

Thanks for your answers.
Sam



_______________________________________________
Gluster-devel mailing list
<A HREF="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</A>
<A HREF="http://lists.nongnu.org/mailman/listinfo/gluster-devel">http://lists.nongnu.org/mailman/listinfo/gluster-devel</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>