Re: [Gluster-users] Gluster - Performance issue while copying bulk files/folders

Hi Anuradha, Please find the Gluster Volume Profile details time cp -RPp drupal\ code/ /mnt/testmount/copytogluster *Profile info of the volume when you copy dirs/files into glusterfs.* *Time taken to copy (70 MB files/Folder)* [root@GFSCLIENT01 temp]# time cp -RPp /mnt/testmount/

Re: [Gluster-users] Gluster - Performance issue while copying bulk files/folders

Hi Mat, The performance when copying or testing using dd command is very fast and 70 mb file take less than 3 min to copy to the Storage Volume. Its a ISCSI based Storage presented to the clients Thanks Sriikanth On Sat, Dec 12, 2015 at 6:20 PM, Mathieu Chateau wrote:

Re: [Gluster-users] Sharding - what next?

Hi, late reply again ... On 10/12/2015 5:33 PM, Krutika Dhananjay wrote: There is a 'heal-info summary' command that is under review, written by Mohammed Ashiq @ http://review.gluster.org/#/c/12154/3 which prints the number of files that are yet to be healed. It could perhaps be enhanced to

Re: [Gluster-users] How to diagnose volume rebalance failure?

ize scanned failures skipped status run time in secs - --- --- --- --- --- -- localhost 0 0Bytes 952767 0 0 failed 3621.00 volume rebalance: FastVol: success: As you can see, I started rebalance task

Re: [Gluster-users] How to diagnose volume rebalance failure?

As you can see, I started rebalance task for only 1 time. cmd_history.log-20151215 == [2015-12-14 12:50:41.443937] : volume start FastVol : SUCCESS [2015-12-14 12:55:01.367519] : volume rebalance FastVol start : SUCCESS [2015-12-14 13:55:22

Re: [Gluster-users] How to diagnose volume rebalance failure?

0 failed 3621.00 volume rebalance: FastVol: success: As you can see, I started rebalance task for only 1 time. cmd_history.log-20151215 == [2015-12-14 12:50:41.443937] : volume start FastVol : SUCCESS [2015-12-14 12:55:01.367519] : volume rebalance

Re: [Gluster-users] libgfapi access

On 12/16/2015 01:51 AM, Ankireddypalle Reddy wrote: Thanks for the explanation. Valgrind profiling shows multiple memcpy's being invoked for each write through libgfapi. Is there a way to avoid these memcpy's?. Also is there a limit on the number of glfs_t* instances that can be allocated