[Gluster-users] reducing size of gdata.log
Hi, Our gdata.log file has gotten quite large (6.4G) and contributed to problems we experienced due to a full /var area. Is there a recommended/safe way to reduce the size of this file? As an example would I come to grief trying: mv gdata.log gdata.log.1; touch gdata.log Then moving gdata.log.1 to another area? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Pat Haley Email: pha...@mit.edu Center for Ocean Engineering Phone: (617) 253-6824 Dept. of Mechanical EngineeringFax:(617) 253-8125 MIT, Room 5-222B http://web.mit.edu/phaley/www/ 77 Massachusetts Avenue Cambridge, MA 02139-4301 ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
Re: [Gluster-users] reducing size of gdata.log
Dear Pat, Hi, Our gdata.log file has gotten quite large (6.4G) and contributed to problems we experienced due to a full /var area. Is there a recommended/safe way to reduce the size of this file? As an example would I come to grief trying: mv gdata.log gdata.log.1; touch gdata.log Then moving gdata.log.1 to another area? Have a look for logrotate, which might be the 1st step of your solution. You could still backup the old logs elsewhere then I think... Hope to have given you a clue. Greetings, Vlad Popa University of Salzburg Computer Science/HPC Computing Jakob Harringer Str, 2 5020 Salzburg Austria ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
Re: [Gluster-users] Renaming permission denied
On Dec 12, 2011, at 1:41 AM, Pranith Kumar K wrote: Seems like the issue with that specific file your application is trying to rename. Could you check if that file has correct permissions on the backends?. It is difficult for me to test that due to the file being created and unlinked during the reindexing process. The fact it has permission to unlink and not rename seems very odd to me. Brian Rosner ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
[Gluster-users] mixing rdma/tcp bricks, rebalance operation locked up
I built an rdma-based volume out of 5 bricks: $ gluster volume info Volume Name: glrdma Type: Distribute Status: Started Number of Bricks: 6 Transport-type: rdma Bricks: Brick1: pbs1:/data2 Brick2: pbs2:/data2 Brick3: pbs3:/data2 Brick4: pbs3:/data Brick5: pbs4:/data Options Reconfigured: diagnostics.count-fop-hits: on diagnostics.latency-measurement: on and everything was working well. I then tried to add a TCP/socket brick to it, thinking that it would be refused, but gluster happily added it: $ gluster volume info Volume Name: glrdma Type: Distribute Status: Started Number of Bricks: 6 Transport-type: rdma Bricks: Brick1: pbs1:/data2 Brick2: pbs2:/data2 Brick3: pbs3:/data2 Brick4: pbs3:/data Brick5: pbs4:/data Brick6: dabrick:/data2 -- TCP/socket brick Options Reconfigured: diagnostics.count-fop-hits: on diagnostics.latency-measurement: on However, not too suprisingly, there are problems when I tried to rebalance the added brick. It allowed me to start a rebalance/fix- layout, but it never ended and the logs continue to contain the following reports of 'connection refused' (see at bottom). Attempts to remove the TCP brick are unsuccessful, even after stopping the volume: $ gluster volume stop glrdma Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y Stopping volume glrdma has been successful $ gluster volume remove-brick glrdma dabrick:/data2 Removing brick(s) can result in data loss. Do you want to Continue? (y/n) y Remove Brick unsuccessful (more errors citing missing 'option transport-type'. defaulting to socket: [2011-12-13 10:34:57.241676] I [cli-rpc- ops.c:1073:gf_cli3_1_remove_brick_cbk] 0-cli: Received resp to remove brick [2011-12-13 10:34:57.241852] I [input.c:46:cli_batch] 0-: Exiting with: -1 [2011-12-13 10:46:08.937294] W [rpc- transport.c:606:rpc_transport_load] 0-rpc-transport: missing 'option transport-type'. defaulting to socket [2011-12-13 10:46:09.110636] I [cli-rpc- ops.c:417:gf_cli3_1_get_volume_cbk] 0-cli: Received resp to get vol: 0 [2011-12-13 10:46:09.110845] I [cli-rpc- ops.c:596:gf_cli3_1_get_volume_cbk] 0-: Returning: 0 [2011-12-13 10:46:09.111038] I [cli-rpc- ops.c:417:gf_cli3_1_get_volume_cbk] 0-cli: Received resp to get vol: 0 [2011-12-13 10:46:09.111070] I [cli-rpc- ops.c:596:gf_cli3_1_get_volume_cbk] 0-: Returning: 0 [2011-12-13 10:46:09.111080] I [input.c:46:cli_batch] 0-: Exiting with: 0 [2011-12-13 10:52:18.142283] W [rpc- transport.c:606:rpc_transport_load] 0-rpc-transport: missing 'option transport-type'. defaulting to socket And the rebalance operations now seem to be locked up, since the response to rebalance is nonsensical: (the commands were given serially, with no other intervening commands) $ gluster volume rebalance glrdma fix-layout start Rebalance on glrdma is already started $ gluster volume rebalance glrdma fix-layout status rebalance stopped $ gluster volume rebalance glrdma fix-layout stop stopped rebalance process of volume glrdma (after rebalancing 0 files totaling 0 bytes) $ gluster volume rebalance glrdma fix-layout start Rebalance on glrdma is already started Is there a way to back out of this situation? Or has incorrectly adding the TCP brick permanently hosed the volume? And does this imply a bug in the add-brick routine? (hopefully fixed?) Logs extracts -- tc-glusterd-mount-glrdma.log (and nfs.log, even tho I haven't tried to export it via nfs) has zillions of these lines: [2011-12-13 10:36:11.702130] E [rdma.c:4417:tcp_connect_finish] 0- glrdma-client-5: tcp connect to failed (Connection refused) cli.log has many of these lines: [2011-12-13 10:34:55.142428] W [rpc- transport.c:606:rpc_transport_load] 0-rpc-transport: missing 'option transport-type'. defaulting to socket -- Harry Mangalam - Research Computing, OIT, Rm 225 MSTB, UC Irvine [ZOT 2225] / 92697 Google Voice Multiplexer: (949) 478-4487 MSTB Lat/Long: (33.642025,-117.844414) (paste into Google Maps) -- This signature has been OCCUPIED! ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
[Gluster-users] where's the API docs?
Where could I find the API documentation for GlusterFS 3.2.5? I don't see anything on the gluster.org site. Erik Redding Systems Programmer, RHCE Core Systems Texas State University-San Marcos smime.p7s Description: S/MIME cryptographic signature ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
Re: [Gluster-users] New Gluster User - Why did the file created in /srv1/brick1 not replicate?
On 12/12/2011 05:24 PM, Chris Matchett wrote: We are using Gluster 3.2 on CentOS 5.7 and have been doing some dr testing. Here's how we tested and also a query regarding an outcome we didn't understand. /srv2/brick2 was shutdown uncleanly and restarted /srv1/brick1 was shutdown uncleanly and restarted. /srv2/brick2 was restarted, files were added to the brick2 folder... a mount was made on /srv2/mnt/test-vol files were added /srv1/brick1 was restarted, files from /srv2/brick2 and mounted volumne appeared a file was added on /srv1/brick1, it did not appear on /srv2 on brick or volume a mount was made on /srv1/mnt/test-vol a file was added, this appeared on /srv2 in brick and volume why did the file created in /srv1/brick1 not replicate? Many thanks, Chris -- Chris Matchett TM2 Support Our Sales and Customer Service numbers are changing to Local Call rate 0333 numbers -- local rates and inclusive minutes even from mobiles. Support : 0 442 800 Sales : 0 442 600 ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users Chris, Changing the files, adding entries into directory directly to backend are not allowed after the mount is performed. Pranith ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
Re: [Gluster-users] Renaming permission denied
On 12/13/2011 10:56 PM, Brian Rosner wrote: On Dec 12, 2011, at 1:41 AM, Pranith Kumar K wrote: Seems like the issue with that specific file your application is trying to rename. Could you check if that file has correct permissions on the backends?. It is difficult for me to test that due to the file being created and unlinked during the reindexing process. The fact it has permission to unlink and not rename seems very odd to me. Brian Rosner Brian, Could you give the permissions/ownership of the directory the file is being created, permissions/ownership of the file that is being created. Is the group of the file secondary group? It is very difficult for us to find the root cause without a good test case. Pranith ___ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
