Best Practices

From GlusterDocumentation

Jump to: navigation, search

Although we plan/design/code GlusterFS to behave ideally for any weird idea you can think of, its still much better if the users follow the best practises below to get the best out of GlusterFS.

  • Once the process starts, be sure that you dont have any errors in the logs (/var/log/glusterfs.log or /var/log/glusterfsd.log). The default log level is 'Warning'. Mostly GlusterFS translators will be logging errors in the system to the logfile. Monitoring the log files is a nice practice.
  • One process for one export works best with the current codebase. (Sharing a namespace export in the same server is not a problem).
  • Whenever possible, use 'cluster/*' translators on the client side (they can be usable on server side without problem).
  • Start with empty export directories when using the 'stripe' translator for the first time. Whenever the number of subvolumes changes for stripe, start from an empty export.
  • If '/mnt/sda1' is your export disk, it is nice if you export '/mnt/sda1/export/' through glusterfs, instead of exporting /mnt/sda1 itself. That way, you can have multiple directories from the same disk exported and it can save you from a possible headache in the future of having to create new export directories.
  • Run 'setfattr -n user.key -v value /<exportdirectory>' as a user (not as 'root') and if it runs successfully, fine. Otherwise, check 'user_xattr' flag in mounting that partition.

NOTE: Above mentioned points are just advises and not the limitations of GlusterFS. You can choose, not to follow them and still it should work fine.

TODO: Remove this page soon, let GlusterFS init() check for all these requirements. Hence User will not be bothered about remembering all these points.

Personal tools