mirror of
https://github.com/gluster/glusterdocs.git
synced 2026-02-05 15:47:01 +01:00
Merge pull request #742 from black-dragon74/devel-new-sntx
[devel-guide] Fix broken links and cleanup syntax
This commit is contained in:
Rakshitha Kamath
@@ -1,4 +1,5 @@
|
||||
# Backport Guidelines
|
||||
|
||||
In GlusterFS project, as a policy, any new change, bug fix, etc., are to be
|
||||
fixed in 'devel' branch before release branches. When a bug is fixed in
|
||||
the devel branch, it might be desirable or necessary in release branch.
|
||||
@@ -9,17 +10,17 @@ understand how to request for backport from community.
|
||||
|
||||
## Policy
|
||||
|
||||
* No feature from devel would be backported to the release branch
|
||||
* CVE ie., security vulnerability [(listed on the CVE database)](https://cve.mitre.org/cve/search_cve_list.html)
|
||||
reported in the existing releases would be backported, after getting fixed
|
||||
in devel branch.
|
||||
* Only topics which bring about data loss or, unavailability would be
|
||||
backported to the release.
|
||||
* For any other issues, the project recommends that the installation be
|
||||
upgraded to a newer release where the specific bug has been addressed.
|
||||
- No feature from devel would be backported to the release branch
|
||||
- CVE ie., security vulnerability [(listed on the CVE database)](https://cve.mitre.org/cve/search_cve_list.html)
|
||||
reported in the existing releases would be backported, after getting fixed
|
||||
in devel branch.
|
||||
- Only topics which bring about data loss or, unavailability would be
|
||||
backported to the release.
|
||||
- For any other issues, the project recommends that the installation be
|
||||
upgraded to a newer release where the specific bug has been addressed.
|
||||
- Gluster provides 'rolling' upgrade support, i.e., one can upgrade their
|
||||
server version without stopping the application I/O, so we recommend migrating
|
||||
to higher version.
|
||||
server version without stopping the application I/O, so we recommend migrating
|
||||
to higher version.
|
||||
|
||||
## Things to pay attention to while backporting a patch.
|
||||
|
||||
@@ -27,12 +28,10 @@ If your patch meets the criteria above, or you are a user, who prefer to have a
|
||||
fix backported, because your current setup is facing issues, below are the
|
||||
steps you need to take care to submit a patch on release branch.
|
||||
|
||||
* The patch should have same 'Change-Id'.
|
||||
|
||||
- The patch should have same 'Change-Id'.
|
||||
|
||||
### How to contact release owners?
|
||||
|
||||
All release owners are part of 'gluster-devel@gluster.org' mailing list.
|
||||
Please write your expectation from next release there, so we can take that
|
||||
to consideration while making the release.
|
||||
|
||||
|
||||
@@ -7,9 +7,11 @@ This page describes how to build and install GlusterFS.
|
||||
The following packages are required for building GlusterFS,
|
||||
|
||||
- GNU Autotools
|
||||
- Automake
|
||||
- Autoconf
|
||||
- Libtool
|
||||
|
||||
- Automake
|
||||
- Autoconf
|
||||
- Libtool
|
||||
|
||||
- lex (generally flex)
|
||||
- GNU Bison
|
||||
- OpenSSL
|
||||
@@ -258,9 +260,9 @@ cd extras/LinuxRPM
|
||||
make glusterrpms
|
||||
```
|
||||
|
||||
This will create rpms from the source in 'extras/LinuxRPM'. *(Note: You
|
||||
This will create rpms from the source in 'extras/LinuxRPM'. _(Note: You
|
||||
will need to install the rpmbuild requirements including rpmbuild and
|
||||
mock)*<br>
|
||||
mock)_<br>
|
||||
For CentOS / Enterprise Linux 8 the dependencies can be installed via:
|
||||
|
||||
```console
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
Developers
|
||||
==========
|
||||
# Developers
|
||||
|
||||
### Contributing to the Gluster community
|
||||
-------------------------------------
|
||||
|
||||
---
|
||||
|
||||
Are you itching to send in patches and participate as a developer in the
|
||||
Gluster community? Here are a number of starting points for getting
|
||||
@@ -10,36 +10,37 @@ involved. All you need is your 'github' account to be handy.
|
||||
|
||||
Remember that, [Gluster community](https://github.com/gluster) has multiple projects, each of which has its own way of handling PRs and patches. Decide on which project you want to contribute. Below documents are mostly about 'GlusterFS' project, which is the core of Gluster Community.
|
||||
|
||||
Workflow
|
||||
--------
|
||||
## Workflow
|
||||
|
||||
- [Simplified Developer Workflow](./Simplified-Development-Workflow.md)
|
||||
- A simpler and faster intro to developing with GlusterFS, than the document below
|
||||
- [Developer Workflow](./Development-Workflow.md)
|
||||
- Covers detail about requirements from a patch; tools and toolkits used by developers.
|
||||
This is recommended reading in order to begin contributions to the project.
|
||||
- [GD2 Developer Workflow](https://github.com/gluster/glusterd2/blob/master/doc/development-guide.md)
|
||||
- Helps in on-boarding developers to contribute in GlusterD2 project.
|
||||
- [Simplified Developer Workflow](./Simplified-Development-Workflow.md)
|
||||
|
||||
Compiling Gluster
|
||||
-----------------
|
||||
- A simpler and faster intro to developing with GlusterFS, than the document below
|
||||
|
||||
- [Building GlusterFS](./Building-GlusterFS.md) - How to compile
|
||||
Gluster from source code.
|
||||
- [Developer Workflow](./Development-Workflow.md)
|
||||
|
||||
Developing
|
||||
----------
|
||||
- Covers detail about requirements from a patch; tools and toolkits used by developers.
|
||||
This is recommended reading in order to begin contributions to the project.
|
||||
|
||||
- [Projects](./Projects.md) - Ideas for projects you could
|
||||
create
|
||||
- [Fixing issues reported by tools for static code
|
||||
analysis](./Fixing-issues-reported-by-tools-for-static-code-analysis.md)
|
||||
- This is a good starting point for developers to fix bugs in
|
||||
GlusterFS project.
|
||||
- [GD2 Developer Workflow](https://github.com/gluster/glusterd2/blob/master/doc/development-guide.md)
|
||||
|
||||
Releases and Backports
|
||||
----------------------
|
||||
- Helps in on-boarding developers to contribute in GlusterD2 project.
|
||||
|
||||
- [Backport Guidelines](./Backport-Guidelines.md) describe the steps that branches too.
|
||||
## Compiling Gluster
|
||||
|
||||
- [Building GlusterFS](./Building-GlusterFS.md) - How to compile
|
||||
Gluster from source code.
|
||||
|
||||
## Developing
|
||||
|
||||
- [Projects](./Projects.md) - Ideas for projects you could
|
||||
create
|
||||
- [Fixing issues reported by tools for static code
|
||||
analysis](./Fixing-issues-reported-by-tools-for-static-code-analysis.md)
|
||||
|
||||
- This is a good starting point for developers to fix bugs in GlusterFS project.
|
||||
|
||||
## Releases and Backports
|
||||
|
||||
- [Backport Guidelines](./Backport-Guidelines.md) describe the steps that branches too.
|
||||
|
||||
Some more GlusterFS Developer documentation can be found [in glusterfs documentation directory](https://github.com/gluster/glusterfs/tree/master/doc/developer-guide)
|
||||
|
||||
@@ -1,12 +1,10 @@
|
||||
Development workflow of Gluster
|
||||
================================
|
||||
# Development workflow of Gluster
|
||||
|
||||
This document provides a detailed overview of the development model
|
||||
followed by the GlusterFS project. For a simpler overview visit
|
||||
[Simplified development workflow](./Simplified-Development-Workflow.md).
|
||||
|
||||
##Basics
|
||||
--------
|
||||
## Basics
|
||||
|
||||
The GlusterFS development model largely revolves around the features and
|
||||
functionality provided by Git version control system, Github and Jenkins
|
||||
@@ -31,8 +29,7 @@ all builds and tests can be viewed at
|
||||
'regression' job which is designed to execute test scripts provided as
|
||||
part of the code change.
|
||||
|
||||
##Preparatory Setup
|
||||
-------------------
|
||||
## Preparatory Setup
|
||||
|
||||
Here is a list of initial one-time steps before you can start hacking on
|
||||
code.
|
||||
@@ -46,9 +43,9 @@ Fork [GlusterFS repository](https://github.com/gluster/glusterfs/fork)
|
||||
Get yourself a working tree by cloning the development repository from
|
||||
|
||||
```console
|
||||
# git clone git@github.com:${username}/glusterfs.git
|
||||
# cd glusterfs/
|
||||
# git remote add upstream git@github.com:gluster/glusterfs.git
|
||||
git clone git@github.com:${username}/glusterfs.git
|
||||
cd glusterfs/
|
||||
git remote add upstream git@github.com:gluster/glusterfs.git
|
||||
```
|
||||
|
||||
### Preferred email and set username
|
||||
@@ -69,13 +66,14 @@ get alerts.
|
||||
|
||||
Set up a filter rule in your mail client to tag or classify emails with
|
||||
the header
|
||||
|
||||
```text
|
||||
list: <glusterfs.gluster.github.com>
|
||||
```
|
||||
|
||||
as mails originating from the github system.
|
||||
|
||||
##Development & Other flows
|
||||
---------------------------
|
||||
## Development & Other flows
|
||||
|
||||
### Issue
|
||||
|
||||
@@ -90,17 +88,17 @@ as mails originating from the github system.
|
||||
- Make sure clang-format is installed and is run on the patch.
|
||||
|
||||
### Keep up-to-date
|
||||
|
||||
- GlusterFS is a large project with many developers, so there would be one or the other patch everyday.
|
||||
- It is critical for developer to be up-to-date with devel repo to be Conflict-Free when PR is opened.
|
||||
- Git provides many options to keep up-to-date, below is one of them
|
||||
|
||||
```console
|
||||
# git fetch upstream
|
||||
# git rebase upstream/devel
|
||||
git fetch upstream
|
||||
git rebase upstream/devel
|
||||
```
|
||||
|
||||
##Branching policy
|
||||
------------------
|
||||
## Branching policy
|
||||
|
||||
This section describes both, the branching policies on the public repo
|
||||
as well as the suggested best-practice for local branching
|
||||
@@ -130,13 +128,12 @@ change. The name of the branch on your personal fork can start with issueNNNN,
|
||||
followed by anything of your choice. If you are submitting changes to the devel
|
||||
branch, first create a local task branch like this -
|
||||
|
||||
```console
|
||||
```{ .console .no-copy }
|
||||
# git checkout -b issueNNNN upstream/main
|
||||
... <hack, commit>
|
||||
```
|
||||
|
||||
##Building
|
||||
----------
|
||||
## Building
|
||||
|
||||
### Environment Setup
|
||||
|
||||
@@ -147,18 +144,19 @@ refer : [Building GlusterFS](./Building-GlusterFS.md)
|
||||
|
||||
Once the required packages are installed for your appropiate system,
|
||||
generate the build configuration:
|
||||
|
||||
```console
|
||||
# ./autogen.sh
|
||||
# ./configure --enable-fusermount
|
||||
./autogen.sh
|
||||
./configure --enable-fusermount
|
||||
```
|
||||
|
||||
### Build and install
|
||||
|
||||
```console
|
||||
# make && make install
|
||||
make && make install
|
||||
```
|
||||
|
||||
##Commit policy / PR description
|
||||
--------------------------------
|
||||
## Commit policy / PR description
|
||||
|
||||
Typically you would have a local branch per task. You will need to
|
||||
sign-off your commit (git commit -s) before sending the
|
||||
@@ -169,22 +167,21 @@ CONTRIBUTING file available in the repository root.
|
||||
Provide a meaningful commit message. Your commit message should be in
|
||||
the following format
|
||||
|
||||
- A short one-line title of format 'component: title', describing what the patch accomplishes
|
||||
- An empty line following the subject
|
||||
- Situation necessitating the patch
|
||||
- Description of the code changes
|
||||
- Reason for doing it this way (compared to others)
|
||||
- Description of test cases
|
||||
- When you open a PR, having a reference Issue for the commit is mandatory in GlusterFS.
|
||||
- Commit message can have, either Fixes: #NNNN or Updates: #NNNN in a separate line in the commit message.
|
||||
Here, NNNN is the Issue ID in glusterfs repository.
|
||||
- Each commit needs the author to have the 'Signed-off-by: Name <email>' line.
|
||||
Can do this by -s option for git commit.
|
||||
- If the PR is not ready for review, apply the label work-in-progress.
|
||||
Check the availability of "Draft PR" is present for you, if yes, use that instead.
|
||||
- A short one-line title of format 'component: title', describing what the patch accomplishes
|
||||
- An empty line following the subject
|
||||
- Situation necessitating the patch
|
||||
- Description of the code changes
|
||||
- Reason for doing it this way (compared to others)
|
||||
- Description of test cases
|
||||
- When you open a PR, having a reference Issue for the commit is mandatory in GlusterFS.
|
||||
- Commit message can have, either Fixes: #NNNN or Updates: #NNNN in a separate line in the commit message.
|
||||
Here, NNNN is the Issue ID in glusterfs repository.
|
||||
- Each commit needs the author to have the 'Signed-off-by: Name <email>' line.
|
||||
Can do this by -s option for git commit.
|
||||
- If the PR is not ready for review, apply the label work-in-progress.
|
||||
Check the availability of "Draft PR" is present for you, if yes, use that instead.
|
||||
|
||||
##Push the change
|
||||
-----------------
|
||||
## Push the change
|
||||
|
||||
After doing the local commit, it is time to submit the code for review.
|
||||
There is a script available inside glusterfs.git called rfc.sh. It is
|
||||
@@ -192,31 +189,34 @@ recommended you keep pushing to your repo every day, so you don't loose
|
||||
any work. You can submit your changes for review by simply executing
|
||||
|
||||
```console
|
||||
# ./rfc.sh
|
||||
./rfc.sh
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```console
|
||||
# git push origin HEAD:issueNNN
|
||||
git push origin HEAD:issueNNN
|
||||
```
|
||||
|
||||
This script rfc.sh does the following:
|
||||
|
||||
- The first time it is executed, it downloads a git hook from
|
||||
<http://review.gluster.org/tools/hooks/commit-msg> and sets it up
|
||||
locally to generate a Change-Id: tag in your commit message (if it
|
||||
was not already generated.)
|
||||
- Rebase your commit against the latest upstream HEAD. This rebase
|
||||
also causes your commits to undergo massaging from the just
|
||||
downloaded commit-msg hook.
|
||||
- Prompt for a Reference Id for each commit (if it was not already provided)
|
||||
and include it as a "fixes: #n" tag in the commit log. You can just hit
|
||||
<enter> at this prompt if your submission is purely for review
|
||||
purposes.
|
||||
- Push the changes for review. On a successful push, you will see a URL pointing to
|
||||
the change in [Pull requests](https://github.com/gluster/glusterfs/pulls) section.
|
||||
- The first time it is executed, it downloads a git hook from
|
||||
<http://review.gluster.org/tools/hooks/commit-msg> and sets it up
|
||||
locally to generate a Change-Id: tag in your commit message (if it
|
||||
was not already generated.)
|
||||
- Rebase your commit against the latest upstream HEAD. This rebase
|
||||
also causes your commits to undergo massaging from the just
|
||||
downloaded commit-msg hook.
|
||||
- Prompt for a Reference Id for each commit (if it was not already provided)
|
||||
and include it as a "fixes: #n" tag in the commit log. You can just hit
|
||||
<enter> at this prompt if your submission is purely for review
|
||||
purposes.
|
||||
- Push the changes for review. On a successful push, you will see a URL pointing to
|
||||
the change in [Pull requests](https://github.com/gluster/glusterfs/pulls) section.
|
||||
|
||||
## Test cases and Verification
|
||||
------------------------------
|
||||
|
||||
---
|
||||
|
||||
### Auto-triggered tests
|
||||
|
||||
@@ -258,13 +258,13 @@ To check and run all regression tests locally, run the below script
|
||||
from glusterfs root directory.
|
||||
|
||||
```console
|
||||
# ./run-tests.sh
|
||||
./run-tests.sh
|
||||
```
|
||||
|
||||
To run a single regression test locally, run the below command.
|
||||
|
||||
```console
|
||||
# prove -vf <path_to_the_file>
|
||||
prove -vf <path_to_the_file>
|
||||
```
|
||||
|
||||
**NOTE:** The testing framework needs perl-Test-Harness package to be installed.
|
||||
@@ -284,18 +284,17 @@ of the feature. Please go through glusto-tests project to understand
|
||||
more information on how to write and execute the tests in glusto.
|
||||
|
||||
1. Extend/Modify old test cases in existing scripts - This is typically
|
||||
when present behavior (default values etc.) of code is changed.
|
||||
when present behavior (default values etc.) of code is changed.
|
||||
|
||||
2. No test cases - This is typically when a code change is trivial
|
||||
(e.g. fixing typos in output strings, code comments).
|
||||
(e.g. fixing typos in output strings, code comments).
|
||||
|
||||
3. Only test case and no code change - This is typically when we are
|
||||
adding test cases to old code (already existing before this regression
|
||||
test policy was enforced). More details on how to work with test case
|
||||
scripts can be found in tests/README.
|
||||
adding test cases to old code (already existing before this regression
|
||||
test policy was enforced). More details on how to work with test case
|
||||
scripts can be found in tests/README.
|
||||
|
||||
##Reviewing / Commenting
|
||||
------------------------
|
||||
## Reviewing / Commenting
|
||||
|
||||
Code review with Github is relatively easy compared to other available
|
||||
tools. Each change is presented as multiple files and each file can be
|
||||
@@ -304,8 +303,7 @@ on each line by clicking on '+' icon and writing in your comments in
|
||||
the text box. Such in-line comments are saved as drafts, till you
|
||||
finally publish them by Starting a Review.
|
||||
|
||||
##Incorporate, rfc.sh, Reverify
|
||||
--------------------------------------
|
||||
## Incorporate, rfc.sh, Reverify
|
||||
|
||||
Code review comments are notified via email. After incorporating the
|
||||
changes in code, you can mark each of the inline comments as 'done'
|
||||
@@ -313,8 +311,9 @@ changes in code, you can mark each of the inline comments as 'done'
|
||||
commits in the same branch with -
|
||||
|
||||
```console
|
||||
# git commit -a -s
|
||||
git commit -a -s
|
||||
```
|
||||
|
||||
Push the commit by executing rfc.sh. If your previous push was an "rfc"
|
||||
push (i.e, without a Issue Id) you will be prompted for a Issue Id
|
||||
again. You can re-push an rfc change without any other code change too
|
||||
@@ -332,8 +331,7 @@ comments can be made on the new patch as well, and the same cycle repeats.
|
||||
|
||||
If no further changes are necessary, the reviewer can approve the patch.
|
||||
|
||||
##Submission Qualifiers
|
||||
-----------------------
|
||||
## Submission Qualifiers
|
||||
|
||||
GlusterFS project follows 'Squash and Merge' method.
|
||||
|
||||
@@ -350,8 +348,7 @@ The project maintainer will merge the changes once a patch
|
||||
meets these qualifiers. If you feel there is delay, feel free
|
||||
to add a comment, discuss the same in Slack channel, or send email.
|
||||
|
||||
##Submission Disqualifiers
|
||||
--------------------------
|
||||
## Submission Disqualifiers
|
||||
|
||||
- +2 : is equivalent to "Approve" from the people in the maintainer's group.
|
||||
- +1 : can be given by a maintainer/reviewer by explicitly stating that in the comment.
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
Fixing easy issues is an excellent method to start contributing patches to Gluster.
|
||||
|
||||
Sometimes an *Easy Fix* issue has a patch attached. In those cases,
|
||||
the *Patch* keyword has been added to the bug. These bugs can be
|
||||
Sometimes an _Easy Fix_ issue has a patch attached. In those cases,
|
||||
the _Patch_ keyword has been added to the bug. These bugs can be
|
||||
used by new contributors that would like to verify their workflow. [Bug
|
||||
1099645](https://bugzilla.redhat.com/1099645) is one example of those.
|
||||
|
||||
@@ -11,12 +11,12 @@ All such issues can be found [here](https://github.com/gluster/glusterfs/labels/
|
||||
|
||||
### Guidelines for new comers
|
||||
|
||||
- While trying to write a patch, do not hesitate to ask questions.
|
||||
- If something in the documentation is unclear, we do need to know so
|
||||
that we can improve it.
|
||||
- There are no stupid questions, and it's more stupid to not ask
|
||||
questions that others can easily answer. Always assume that if you
|
||||
have a question, someone else would like to hear the answer too.
|
||||
- While trying to write a patch, do not hesitate to ask questions.
|
||||
- If something in the documentation is unclear, we do need to know so
|
||||
that we can improve it.
|
||||
- There are no stupid questions, and it's more stupid to not ask
|
||||
questions that others can easily answer. Always assume that if you
|
||||
have a question, someone else would like to hear the answer too.
|
||||
|
||||
[Reach out](https://www.gluster.org/community/) to the developers
|
||||
in #gluster on [Gluster Slack](https://gluster.slack.com) channel, or on
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
Static Code Analysis Tools
|
||||
--------------------------
|
||||
## Static Code Analysis Tools
|
||||
|
||||
Bug fixes for issues reported by *Static Code Analysis Tools* should
|
||||
Bug fixes for issues reported by _Static Code Analysis Tools_ should
|
||||
follow [Development Work Flow](./Development-Workflow.md)
|
||||
|
||||
### Coverity
|
||||
@@ -9,49 +8,48 @@ follow [Development Work Flow](./Development-Workflow.md)
|
||||
GlusterFS is part of [Coverity's](https://scan.coverity.com/) scan
|
||||
program.
|
||||
|
||||
- To see Coverity issues you have to be a member of the GlusterFS
|
||||
project in Coverity scan website.
|
||||
- Here is the link to [Coverity scan website](https://scan.coverity.com/projects/987)
|
||||
- Go to above link and subscribe to GlusterFS project (as
|
||||
contributor). It will send a request to Admin for including you in
|
||||
the Project.
|
||||
- Once admins for the GlusterFS Coverity scan approve your request,
|
||||
you will be able to see the defects raised by Coverity.
|
||||
- [Issue #1060](https://github.com/gluster/glusterfs/issues/1060)
|
||||
can be used as a umbrella bug for Coverity issues in master
|
||||
branch unless you are trying to fix a specific issue.
|
||||
- When you decide to work on some issue, please assign it to your name
|
||||
in the same Coverity website. So that we don't step on each others
|
||||
work.
|
||||
- When marking a bug intentional in Coverity scan website, please put
|
||||
an explanation for the same. So that it will help others to
|
||||
understand the reasoning behind it.
|
||||
- To see Coverity issues you have to be a member of the GlusterFS
|
||||
project in Coverity scan website.
|
||||
- Here is the link to [Coverity scan website](https://scan.coverity.com/projects/987)
|
||||
- Go to above link and subscribe to GlusterFS project (as
|
||||
contributor). It will send a request to Admin for including you in
|
||||
the Project.
|
||||
- Once admins for the GlusterFS Coverity scan approve your request,
|
||||
you will be able to see the defects raised by Coverity.
|
||||
- [Issue #1060](https://github.com/gluster/glusterfs/issues/1060)
|
||||
can be used as a umbrella bug for Coverity issues in master
|
||||
branch unless you are trying to fix a specific issue.
|
||||
- When you decide to work on some issue, please assign it to your name
|
||||
in the same Coverity website. So that we don't step on each others
|
||||
work.
|
||||
- When marking a bug intentional in Coverity scan website, please put
|
||||
an explanation for the same. So that it will help others to
|
||||
understand the reasoning behind it.
|
||||
|
||||
*If you have more questions please send it to
|
||||
_If you have more questions please send it to
|
||||
[gluster-devel](https://lists.gluster.org/mailman/listinfo/gluster-devel) mailing
|
||||
list*
|
||||
list_
|
||||
|
||||
### CPP Check
|
||||
|
||||
Cppcheck is available in Fedora and EL's EPEL repo
|
||||
|
||||
- Install Cppcheck
|
||||
- Install Cppcheck
|
||||
|
||||
# dnf install cppcheck
|
||||
dnf install cppcheck
|
||||
|
||||
- Clone GlusterFS code
|
||||
- Clone GlusterFS code
|
||||
|
||||
# git clone https://github.com/gluster/glusterfs
|
||||
git clone https://github.com/gluster/glusterfs
|
||||
|
||||
- Run Cpp check
|
||||
|
||||
# cppcheck glusterfs/ 2>cppcheck.log
|
||||
- Run Cpp check
|
||||
|
||||
cppcheck glusterfs/ 2>cppcheck.log
|
||||
|
||||
### Clang-Scan Daily Runs
|
||||
|
||||
We have daily runs of static source code analysis tool clang-scan on
|
||||
the glusterfs sources. There are daily analyses of the master and
|
||||
the glusterfs sources. There are daily analyses of the master and
|
||||
on currently supported branches.
|
||||
|
||||
Results are posted at
|
||||
|
||||
@@ -3,9 +3,7 @@
|
||||
This page contains a list of project ideas which will be suitable for
|
||||
students (for GSOC, internship etc.)
|
||||
|
||||
Projects/Features which needs contributors
|
||||
------------------------------------------
|
||||
|
||||
## Projects/Features which needs contributors
|
||||
|
||||
### RIO
|
||||
|
||||
@@ -13,27 +11,23 @@ Issue: https://github.com/gluster/glusterfs/issues/243
|
||||
|
||||
This is a new distribution logic, which can scale Gluster to 1000s of nodes.
|
||||
|
||||
|
||||
### Composition xlator for small files
|
||||
|
||||
Merge small files into a designated large file using our own custom
|
||||
semantics. This can improve our small file performance.
|
||||
|
||||
|
||||
### Path based geo-replication
|
||||
|
||||
Issue: https://github.com/gluster/glusterfs/issues/460
|
||||
|
||||
This would allow remote volume to be of different type (NFS/S3 etc etc) too.
|
||||
|
||||
|
||||
### Project Quota support
|
||||
|
||||
Issue: https://github.com/gluster/glusterfs/issues/184
|
||||
|
||||
This will make Gluster's Quota faster, and also provide desired behavior.
|
||||
|
||||
|
||||
### Cluster testing framework based on gluster-tester
|
||||
|
||||
Repo: https://github.com/aravindavk/gluster-tester
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
Simplified development workflow for GlusterFS
|
||||
=============================================
|
||||
# Simplified development workflow for GlusterFS
|
||||
|
||||
This page gives a simplified model of the development workflow used by
|
||||
the GlusterFS project. This will give the steps required to get a patch
|
||||
@@ -8,8 +7,7 @@ accepted into the GlusterFS source.
|
||||
Visit [Development Work Flow](./Development-Workflow.md) a more
|
||||
detailed description of the workflow.
|
||||
|
||||
##Initial preparation
|
||||
---------------------
|
||||
## Initial preparation
|
||||
|
||||
The GlusterFS development workflow revolves around
|
||||
[GitHub](http://github.com/gluster/glusterfs/) and
|
||||
@@ -17,13 +15,15 @@ The GlusterFS development workflow revolves around
|
||||
Using these both tools requires some initial preparation.
|
||||
|
||||
### Get the source
|
||||
|
||||
Git clone the GlusterFS source using
|
||||
|
||||
```console
|
||||
git clone git@github.com:${username}/glusterfs.git
|
||||
cd glusterfs/
|
||||
git remote add upstream git@github.com:gluster/glusterfs.git
|
||||
```{ .console .no-copy }
|
||||
git clone git@github.com:${username}/glusterfs.git
|
||||
cd glusterfs/
|
||||
git remote add upstream git@github.com:gluster/glusterfs.git
|
||||
```
|
||||
|
||||
This will clone the GlusterFS source into a subdirectory named glusterfs
|
||||
with the devel branch checked out.
|
||||
|
||||
@@ -34,7 +34,7 @@ distribution specific package manger to install git. After installation
|
||||
configure git. At the minimum, set a git user email. To set the email
|
||||
do,
|
||||
|
||||
```console
|
||||
```{ .console .no-copy }
|
||||
git config --global user.name <name>
|
||||
git config --global user.email <email address>
|
||||
```
|
||||
@@ -43,8 +43,7 @@ Next, install the build requirements for GlusterFS. Refer
|
||||
[Building GlusterFS - Build Requirements](./Building-GlusterFS.md#Build Requirements)
|
||||
for the actual requirements.
|
||||
|
||||
##Actual development
|
||||
--------------------
|
||||
## Actual development
|
||||
|
||||
The commands in this section are to be run inside the glusterfs source
|
||||
directory.
|
||||
@@ -55,23 +54,25 @@ It is recommended to use separate local development branches for each
|
||||
change you want to contribute to GlusterFS. To create a development
|
||||
branch, first checkout the upstream branch you want to work on and
|
||||
update it. More details on the upstream branching model for GlusterFS
|
||||
can be found at [Development Work Flow - Branching\_policy](./Development-Workflow.md#branching-policy).
|
||||
can be found at [Development Work Flow - Branching_policy](./Development-Workflow.md#branching-policy).
|
||||
For example if you want to develop on the devel branch,
|
||||
|
||||
```console
|
||||
# git checkout devel
|
||||
# git pull
|
||||
git checkout devel
|
||||
git pull
|
||||
```
|
||||
|
||||
Now, create a new branch from devel and switch to the new branch. It is
|
||||
recommended to have descriptive branch names. Do,
|
||||
|
||||
```console
|
||||
```{ .console .no-copy }
|
||||
git branch issueNNNN
|
||||
git checkout issueNNNN
|
||||
```
|
||||
|
||||
or,
|
||||
```console
|
||||
|
||||
```{ .console .no-copy }
|
||||
git checkout -b issueNNNN upstream/main
|
||||
```
|
||||
|
||||
@@ -100,8 +101,8 @@ working GlusterFS installation and needs to be run as root. To run the
|
||||
regression test suite, do
|
||||
|
||||
```console
|
||||
# make install
|
||||
# ./run-tests.sh
|
||||
make install
|
||||
./run-tests.sh
|
||||
```
|
||||
|
||||
or, After uploading the patch The regression tests would be triggered
|
||||
@@ -113,7 +114,7 @@ If you haven't broken anything, you can now commit your changes. First
|
||||
identify the files that you modified/added/deleted using git-status and
|
||||
stage these files.
|
||||
|
||||
```console
|
||||
```{ .console .no-copy }
|
||||
git status
|
||||
git add <list of modified files>
|
||||
```
|
||||
@@ -121,7 +122,7 @@ git add <list of modified files>
|
||||
Now, commit these changes using
|
||||
|
||||
```console
|
||||
# git commit -s
|
||||
git commit -s
|
||||
```
|
||||
|
||||
Provide a meaningful commit message. The commit message policy is
|
||||
@@ -134,18 +135,19 @@ sign-off the commit with your configured email.
|
||||
To submit your change for review, run the rfc.sh script,
|
||||
|
||||
```console
|
||||
# ./rfc.sh
|
||||
./rfc.sh
|
||||
```
|
||||
|
||||
or
|
||||
```console
|
||||
|
||||
```{ .console .no-copy }
|
||||
git push origin HEAD:issueNNN
|
||||
```
|
||||
|
||||
More details on the rfc.sh script are available at
|
||||
[Development Work Flow - rfc.sh](./Development-Workflow.md#rfc.sh).
|
||||
|
||||
##Review process
|
||||
----------------
|
||||
## Review process
|
||||
|
||||
Your change will now be reviewed by the GlusterFS maintainers and
|
||||
component owners. You can follow and take part in the review process
|
||||
@@ -186,8 +188,9 @@ review comments. Build and test to see if the new changes are working.
|
||||
Stage your changes and commit your new changes in new commits using,
|
||||
|
||||
```console
|
||||
# git commit -a -s
|
||||
git commit -a -s
|
||||
```
|
||||
|
||||
Now you can resubmit the commit for review using the rfc.sh script or git push.
|
||||
|
||||
The formal review process could take a long time. To increase chances
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
How to compile GlusterFS RPMs from git source, for RHEL/CentOS, and Fedora
|
||||
--------------------------------------------------------------------------
|
||||
## How to compile GlusterFS RPMs from git source, for RHEL/CentOS, and Fedora
|
||||
|
||||
Creating rpm's of GlusterFS from git source is fairly easy, once you know the steps.
|
||||
|
||||
@@ -21,13 +20,13 @@ Specific instructions for compiling are below. If you're using:
|
||||
|
||||
### Preparation steps for Fedora 16-20 (only)
|
||||
|
||||
1. Install gcc, the python development headers, and python setuptools:
|
||||
1. Install gcc, the python development headers, and python setuptools:
|
||||
|
||||
# sudo yum -y install gcc python-devel python-setuptools
|
||||
sudo yum -y install gcc python-devel python-setuptools
|
||||
|
||||
2. If you're compiling GlusterFS version 3.4, then install python-swiftclient. Other GlusterFS versions don't need it:
|
||||
2. If you're compiling GlusterFS version 3.4, then install python-swiftclient. Other GlusterFS versions don't need it:
|
||||
|
||||
# sudo easy_install simplejson python-swiftclient
|
||||
sudo easy_install simplejson python-swiftclient
|
||||
|
||||
Now follow through with the **Common Steps** part below.
|
||||
|
||||
@@ -35,15 +34,15 @@ Now follow through with the **Common Steps** part below.
|
||||
|
||||
You'll need EPEL installed first and some CentOS-specific packages. The commands below will get that done for you. After that, follow through the "Common steps" section.
|
||||
|
||||
1. Install EPEL first:
|
||||
1. Install EPEL first:
|
||||
|
||||
# curl -OL `[`http://download.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm`](http://download.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm)
|
||||
# sudo yum -y install epel-release-5-4.noarch.rpm --nogpgcheck
|
||||
curl -OL http://download.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
|
||||
sudo yum -y install epel-release-5-4.noarch.rpm --nogpgcheck
|
||||
|
||||
2. Install the packages required only on CentOS 5.x:
|
||||
2. Install the packages required only on CentOS 5.x:
|
||||
|
||||
# sudo yum -y install buildsys-macros gcc ncurses-devel \
|
||||
python-ctypes python-sphinx10 redhat-rpm-config
|
||||
sudo yum -y install buildsys-macros gcc ncurses-devel \
|
||||
python-ctypes python-sphinx10 redhat-rpm-config
|
||||
|
||||
Now follow through with the **Common Steps** part below.
|
||||
|
||||
@@ -51,32 +50,31 @@ Now follow through with the **Common Steps** part below.
|
||||
|
||||
You'll need EPEL installed first and some CentOS-specific packages. The commands below will get that done for you. After that, follow through the "Common steps" section.
|
||||
|
||||
1. Install EPEL first:
|
||||
1. Install EPEL first:
|
||||
|
||||
# sudo yum -y install `[`http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm`](http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm)
|
||||
sudo yum -y install http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
|
||||
|
||||
2. Install the packages required only on CentOS:
|
||||
2. Install the packages required only on CentOS:
|
||||
|
||||
# sudo yum -y install python-webob1.0 python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
|
||||
sudo yum -y install python-webob1.0 python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
|
||||
|
||||
Now follow through with the **Common Steps** part below.
|
||||
|
||||
|
||||
### Preparation steps for CentOS 8.x (only)
|
||||
|
||||
You'll need EPEL installed and then the powertools package enabled.
|
||||
You'll need EPEL installed and then the powertools package enabled.
|
||||
|
||||
1. Install EPEL first:
|
||||
|
||||
# sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
|
||||
1. Install EPEL first:
|
||||
|
||||
2. Enable the PowerTools repo and install CentOS 8.x specific packages for building the rpms.
|
||||
sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
|
||||
|
||||
# sudo yum --enablerepo=PowerTools install automake autoconf libtool flex bison openssl-devel \
|
||||
libxml2-devel libaio-devel libibverbs-devel librdmacm-devel readline-devel lvm2-devel \
|
||||
glib2-devel userspace-rcu-devel libcmocka-devel libacl-devel sqlite-devel fuse-devel \
|
||||
redhat-rpm-config rpcgen libtirpc-devel make python3-devel rsync libuuid-devel \
|
||||
rpm-build dbench perl-Test-Harness attr libcurl-devel selinux-policy-devel -y
|
||||
2. Enable the PowerTools repo and install CentOS 8.x specific packages for building the rpms.
|
||||
|
||||
sudo yum --enablerepo=PowerTools install automake autoconf libtool flex bison openssl-devel \
|
||||
libxml2-devel libaio-devel libibverbs-devel librdmacm-devel readline-devel lvm2-devel \
|
||||
glib2-devel userspace-rcu-devel libcmocka-devel libacl-devel sqlite-devel fuse-devel \
|
||||
redhat-rpm-config rpcgen libtirpc-devel make python3-devel rsync libuuid-devel \
|
||||
rpm-build dbench perl-Test-Harness attr libcurl-devel selinux-policy-devel -y
|
||||
|
||||
Now follow through from Point 2 in the **Common Steps** part below.
|
||||
|
||||
@@ -84,14 +82,14 @@ Now follow through from Point 2 in the **Common Steps** part below.
|
||||
|
||||
You'll need EPEL installed first and some RHEL specific packages. The 2 commands below will get that done for you. After that, follow through the "Common steps" section.
|
||||
|
||||
1. Install EPEL first:
|
||||
1. Install EPEL first:
|
||||
|
||||
# sudo yum -y install `[`http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm`](http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm)
|
||||
sudo yum -y install http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
|
||||
|
||||
2. Install the packages required only on RHEL:
|
||||
2. Install the packages required only on RHEL:
|
||||
|
||||
# sudo yum -y --enablerepo=rhel-6-server-optional-rpms install python-webob1.0 \
|
||||
python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
|
||||
sudo yum -y --enablerepo=rhel-6-server-optional-rpms install python-webob1.0 \
|
||||
python-paste-deploy1.5 python-sphinx10 redhat-rpm-config
|
||||
|
||||
Now follow through with the **Common Steps** part below.
|
||||
|
||||
@@ -104,64 +102,65 @@ These steps are for both Fedora and RHEL/CentOS. At the end you'll have the comp
|
||||
- If you're on RHEL/CentOS 5.x and get a message about lvm2-devel not being available, it's ok. You can ignore it. :)
|
||||
- If you're on RHEL/CentOS 6.x and get any messages about python-eventlet, python-netifaces, python-sphinx and/or pyxattr not being available, it's ok. You can ignore them. :)
|
||||
- If you're on CentOS 8.x, you can skip step 1 and start from step 2. Also, for CentOS 8.x, the steps have been
|
||||
tested for the master branch. It is unknown if it would work for older branches.
|
||||
tested for the master branch. It is unknown if it would work for older branches.
|
||||
|
||||
<br/>
|
||||
|
||||
1. Install the needed packages
|
||||
1. Install the needed packages
|
||||
|
||||
# sudo yum -y --disablerepo=rhs* --enablerepo=*optional-rpms install git autoconf \
|
||||
automake bison dos2unix flex fuse-devel glib2-devel libaio-devel \
|
||||
libattr-devel libibverbs-devel librdmacm-devel libtool libxml2-devel lvm2-devel make \
|
||||
openssl-devel pkgconfig pyliblzma python-devel python-eventlet python-netifaces \
|
||||
python-paste-deploy python-simplejson python-sphinx python-webob pyxattr readline-devel \
|
||||
rpm-build systemtap-sdt-devel tar libcmocka-devel
|
||||
sudo yum -y --disablerepo=rhs* --enablerepo=*optional-rpms install git autoconf \
|
||||
automake bison dos2unix flex fuse-devel glib2-devel libaio-devel \
|
||||
libattr-devel libibverbs-devel librdmacm-devel libtool libxml2-devel lvm2-devel make \
|
||||
openssl-devel pkgconfig pyliblzma python-devel python-eventlet python-netifaces \
|
||||
python-paste-deploy python-simplejson python-sphinx python-webob pyxattr readline-devel \
|
||||
rpm-build systemtap-sdt-devel tar libcmocka-devel
|
||||
|
||||
2. Clone the GlusterFS git repository
|
||||
2. Clone the GlusterFS git repository
|
||||
|
||||
# git clone `[`git://git.gluster.org/glusterfs`](git://git.gluster.org/glusterfs)
|
||||
# cd glusterfs
|
||||
git clone git://git.gluster.org/glusterfs
|
||||
cd glusterfs
|
||||
|
||||
3. Choose which branch to compile
|
||||
3. Choose which branch to compile
|
||||
|
||||
If you want to compile the latest development code, you can skip this step and go on to the next one. :)
|
||||
|
||||
If instead, you want to compile the code for a specific release of GlusterFS (such as v3.4), get the list of release names here:
|
||||
|
||||
# git branch -a | grep release
|
||||
remotes/origin/release-2.0
|
||||
remotes/origin/release-3.0
|
||||
remotes/origin/release-3.1
|
||||
remotes/origin/release-3.2
|
||||
remotes/origin/release-3.3
|
||||
remotes/origin/release-3.4
|
||||
remotes/origin/release-3.5
|
||||
# git branch -a | grep release
|
||||
remotes/origin/release-2.0
|
||||
remotes/origin/release-3.0
|
||||
remotes/origin/release-3.1
|
||||
remotes/origin/release-3.2
|
||||
remotes/origin/release-3.3
|
||||
remotes/origin/release-3.4
|
||||
remotes/origin/release-3.5
|
||||
|
||||
Then switch to the correct release using the git "checkout" command, and the name of the release after the "remotes/origin/" bit from the list above:
|
||||
|
||||
# git checkout release-3.4
|
||||
git checkout release-3.4
|
||||
|
||||
**NOTE -** The CentOS 5.x instructions have only been tested for the master branch in GlusterFS git. It is unknown (yet) if they work for branches older than release-3.5.
|
||||
|
||||
---
|
||||
If you are compiling the latest development code you can skip steps **4** and **5**. Instead, you can run the below command and you will get the RPMs.
|
||||
***
|
||||
|
||||
|
||||
# extras/LinuxRPM/make_glusterrpms
|
||||
---
|
||||
If you are compiling the latest development code you can skip steps **4** and **5**. Instead, you can run the below command and you will get the RPMs.
|
||||
|
||||
4. Configure and compile GlusterFS
|
||||
extras/LinuxRPM/make_glusterrpms
|
||||
|
||||
***
|
||||
|
||||
4. Configure and compile GlusterFS
|
||||
|
||||
Now you're ready to compile Gluster:
|
||||
|
||||
# ./autogen.sh
|
||||
# ./configure --enable-fusermount
|
||||
# make dist
|
||||
./autogen.sh
|
||||
./configure --enable-fusermount
|
||||
make dist
|
||||
|
||||
5. Create the GlusterFS RPMs
|
||||
5. Create the GlusterFS RPMs
|
||||
|
||||
# cd extras/LinuxRPM
|
||||
# make glusterrpms
|
||||
cd extras/LinuxRPM
|
||||
make glusterrpms
|
||||
|
||||
That should complete with no errors, leaving you with a directory containing the RPMs.
|
||||
|
||||
|
||||
@@ -1,47 +1,52 @@
|
||||
# Get core dump on a customer set up without killing the process
|
||||
|
||||
### Why do we need this?
|
||||
|
||||
Finding the root cause of an issue that occurred in the customer/production setup is a challenging task.
|
||||
Most of the time we cannot replicate/setup the environment and scenario which is leading to the issue on
|
||||
our test setup. In such cases, we got to grab most of the information from the system where the problem
|
||||
has occurred.
|
||||
<br>
|
||||
|
||||
### What information we look for and also useful?
|
||||
|
||||
The information like a core dump is very helpful to catch the root cause of an issue by adding ASSERT() in
|
||||
the code at the places where we feel something is wrong and install the custom build on the affected setup.
|
||||
But the issue is ASSERT() would kill the process and produce the core dump.
|
||||
<br>
|
||||
|
||||
### Is it a good idea to do ASSERT() on customer setup?
|
||||
Remember we are seeking help from customer setup, they unlikely agree to kill the process and produce the
|
||||
|
||||
Remember we are seeking help from customer setup, they unlikely agree to kill the process and produce the
|
||||
core dump for us to root cause it. It affects the customer’s business and nobody agrees with this proposal.
|
||||
<br>
|
||||
|
||||
### What if we have a way to produce a core dump without a kill?
|
||||
Yes, Glusterfs provides a way to do this. Gluster has customized ASSERT() i.e GF_ASSERT() in place which helps
|
||||
in producing the core dump without killing the associated process and also provides a script which can be run on
|
||||
the customer set up that produces the core dump without harming the running process (This presumes we already have
|
||||
GF_ASSERT() at the expected place in the current build running on customer setup. If not, we need to install custom
|
||||
|
||||
Yes, Glusterfs provides a way to do this. Gluster has customized ASSERT() i.e GF_ASSERT() in place which helps
|
||||
in producing the core dump without killing the associated process and also provides a script which can be run on
|
||||
the customer set up that produces the core dump without harming the running process (This presumes we already have
|
||||
GF_ASSERT() at the expected place in the current build running on customer setup. If not, we need to install custom
|
||||
build on that setup by adding GF_ASSERT()).
|
||||
<br>
|
||||
|
||||
### Is GF_ASSERT() newly introduced in Gluster code?
|
||||
No. GF_ASSERT() is already there in the codebase before this improvement. In the debug build, GF_ASSERT() kills the
|
||||
process and produces the core dump but in the production build, it just logs the error and moves on. What we have done
|
||||
is we just changed the implementation of the code and now in production build also we get the core dump but the process
|
||||
|
||||
No. GF_ASSERT() is already there in the codebase before this improvement. In the debug build, GF_ASSERT() kills the
|
||||
process and produces the core dump but in the production build, it just logs the error and moves on. What we have done
|
||||
is we just changed the implementation of the code and now in production build also we get the core dump but the process
|
||||
won’t be killed. The code places where GF_ASSERT() is not covered, please add it as per the requirement.
|
||||
<br>
|
||||
|
||||
## Here are the steps to achieve the goal:
|
||||
- Add GF_ASSERT() in the Gluster code path where you expect something wrong is happening.
|
||||
- Build the Gluster code, install and mount the Gluster volume (For detailed steps refer: Gluster quick start guide).
|
||||
- Now, in the other terminal, run the gfcore.py script
|
||||
`# ./extras/debug/gfcore.py $PID 1 /tmp/` (PID of the gluster process you are interested in, got it by `ps -ef | grep gluster`
|
||||
in the previous step. For more details, check `# ./extras/debug/gfcore.py --help`)
|
||||
- Hit the code path where you have introduced GF_ASSERT(). If GF_ASSERT() is in fuse_write() path, you can hit the code
|
||||
path by writing on to a file present under Gluster moun. Ex: `# dd if=/dev/zero of=/mnt/glustrefs/abcd bs=1M count=1`
|
||||
where `/mnt/glusterfs` is the gluster mount
|
||||
- Go to the terminal where the gdb is running (step 3) and observe that the gdb process is terminated
|
||||
- Go to the directory where the core-dump is produced. Default would be present working directory.
|
||||
- Access the core dump using gdb Ex: `# gdb -ex "core-file $GFCORE_FILE" $GLUSTER_BINARY`
|
||||
(1st arg would be core file name and 2nd arg is o/p of file command in the previous step)
|
||||
- Observe that the Gluster process is unaffected by checking its process state. Check pid status using `ps -ef | grep gluster`
|
||||
<br>
|
||||
Thanks, Xavi Hernandez(jahernan@redhat.com) for the idea. This will ease many Gluster developer's/maintainer’s life.
|
||||
|
||||
- Add GF_ASSERT() in the Gluster code path where you expect something wrong is happening.
|
||||
- Build the Gluster code, install and mount the Gluster volume (For detailed steps refer: Gluster quick start guide).
|
||||
- Now, in the other terminal, run the gfcore.py script
|
||||
`# ./extras/debug/gfcore.py $PID 1 /tmp/` (PID of the gluster process you are interested in, got it by `ps -ef | grep gluster`
|
||||
in the previous step. For more details, check `# ./extras/debug/gfcore.py --help`)
|
||||
- Hit the code path where you have introduced GF_ASSERT(). If GF_ASSERT() is in fuse_write() path, you can hit the code
|
||||
path by writing on to a file present under Gluster moun. Ex: `# dd if=/dev/zero of=/mnt/glustrefs/abcd bs=1M count=1`
|
||||
where `/mnt/glusterfs` is the gluster mount
|
||||
- Go to the terminal where the gdb is running (step 3) and observe that the gdb process is terminated
|
||||
- Go to the directory where the core-dump is produced. Default would be present working directory.
|
||||
- Access the core dump using gdb Ex: `# gdb -ex "core-file $GFCORE_FILE" $GLUSTER_BINARY`
|
||||
(1st arg would be core file name and 2nd arg is o/p of file command in the previous step)
|
||||
- Observe that the Gluster process is unaffected by checking its process state. Check pid status using `ps -ef | grep gluster`
|
||||
|
||||
Thanks, Xavi Hernandez(jahernan@redhat.com) for the idea. This will ease many Gluster developer's/maintainer’s life.
|
||||
|
||||
Reference in New Issue
Block a user