I'm sorry, I had taken a mistake here. You are right, we can distinguish between client/server by the symbolic linked filename. But the program itself do not distinguish its role at least until 1.3.12. It means that somebody careless would set up a server daemon by the client process name. It should be a problem. I do not know the actual situation of 2.0rc1, because of the 'NO_CONTENT_TYPE' problem I have noticed in some prior mails. About point 2, I will check my APT system later, why the fuse-lib depends on kmod-fuse. About point 3, actually the size of stick is just 128M (because it's on board). So maybe it is a problem only for me, let's skip it. -----Original Message----- From: gluster-devel-bounces+kirbyzhou=sohu-rd.com@xxxxxxxxxx [mailto:gluster-devel-bounces+kirbyzhou=sohu-rd.com@xxxxxxxxxx] On Behalf Of Gordan Bobic Sent: Monday, February 02, 2009 10:53 PM To: gluster-devel@xxxxxxxxxx Subject: Re: Why integrate both client and server into a single executable? On Mon, 2 Feb 2009 22:04:15 +0800, Kirby Zhou <kirbyzhou@xxxxxxxxxxx> wrote: > Why integrate both client and server into a single executable? Presumably because most of the code is shared between the two? (e.g. socket code, config parsing code, logging, etc.) > I think it brings a lot of trouble to server operators. > > For example: > > 1. If client and server runs together on the same node, I don't know > which process should be kill if some bug occurs. Since there is only one process, there is only one process to kill/restart. I'm not sure what you mean by "I don't know which process". Note that you can still run it as a 2-process sytem, if you really want to. # killall glusterfs will kill the client. # killall glusterfsd will kill the server. You could bolt this down more tightly by wrapping them and saving the PID of the process into a file, traditionally in /var/run/. > 2. FUSE is not necessary in the server side, but I can not avoid > install FUSE on the server side. It increases the security venture of the > server side. Hmm, you may have a point there, but you only need the fuse-libs, not the fuse kernel module. I'm not convinced that the fuse libraries are a significant security risk. > 3. It increase the file size of the final binary. I want to boot up > the gluster server node from a small USB finger, the size of binary is > important. I'm not sure the size of the binary is all that significant when you factor in the size of the kernel, initrd and a minimal root. Can you provide some actual sizing figures on this? The smallest/cheapest USB memory stick I can find right now is 1GB and they sell for about $5 / £3.5. Is an extra few KB of a binary disk footprint really going to make that much difference? Or are you thinking about putting this into something _really_ small like an ARM based appliance? Gordan _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxx http://lists.nongnu.org/mailman/listinfo/gluster-devel
