Tag Info

New answers tagged

0

There's a whole lot of stuff in container file systems which gluster won't handle well. e.g. think of the device files in /dev. I'd also want to look closely at how gluster handles things like constant small appends to log files. In any case there's little reason to share the containers themselves, when you can just fire up the appropriate containers on ...


1

Thanks for the detailed explanation, I think I understand a lot more than earlier. Latest solution is almost working. The problems (actually one, since the first implies the second): local shares (127.0.0.1:/share) still not mounted mounted TYPE=glusterfs never satisfied, so the services which are dependent of the mounted TYPE=glusterfs state ...


0

Please don't do that. While not required, you want to give GlusterFS bricks their own partition so that you can check their usage via a simple df -h. To answer your question no, GlusterFS does not take into account other data in the same partition as its bricks.


0

As per the network.frame-timeout option, after 1800 seconds (30 minutes) the "operation has to be declared as dead, if the server does not respond for a particular operation" (old, but possibly still valid: http://www.gluster.org/community/documentation/index.php/Gluster_3.2:_Setting_Volume_Options#network.frame-timeout). The logs could also contain ...


0

I am somehow working on a similar situation. If your bottleneck is the CPU I think that decreasing cluster.background-self-heal-count should help (default is 16). In other words "when your client tries to open 17 files, it'll hang on the 17th waiting for a self-heal" (https://botbot.me/freenode/gluster/msg/45681458/).


0

The use of glusterfs would depend on the storage backend that you are using. As a cluster file system it is intended to cluster physical storage so it appears as one large continuous volume. This official quick start guide has a good explanation of the process. In the event that your setup utilizes two or more separate backend storage servers or ...


1

stat()-ing the files from the client mountpoint is how Gluster knows that the files need to be re-replicated, so basically the answer to your question is "no". The solution though is just to stat() every file - which is actually easier than it sounds, just run this from a client: find /mnt/repl1 -exec stat {} \; This is documented here.



Top 50 recent answers are included