Page History
...
For code that requires modifications or additions to the existing suite of automated Lustre tests, the new or modified test scripts must be submitted with the patch. If there is a defect in the existing code, it means that there is no regression test that covers this code path. A new test should be written that confirms the problem be hit by the test before the fix is landed, and verifies the patch resolves the problem afterward. Any additional testing that cannot be covered by the existing automated Lustre tests must also be documented with a clear, step-by-step test plan, and arrangements must be made with the Lustre test team to execute these plans.
Commit comment format
The first line of the commit comment is the commit summary of the change. Changes submitted to the fs/lustre-release branch also require a Lustre Jira issue tag at the beginning of the first line of the commit summary. A Lustre Jira ticket is one that begins with LU and is therefore part of the Lustre project within Jira. If the patch is submitted for the fs/lustre-release repository without a Lustre Jira ID in the first line, then it will automatically receive a -2 review which will prevent the patch from being submitted to a release branch. You will get an e-mail about this rejection at which time you can add the line and resubmit the patch. The commit summary should also have a component: field immediately following the Jira issue tag that indicates which Lustre subsystem that the commit is related to. Example Lustre subsystems relate to modules like llite, lov, osc, mdc, lmv, ldlm, ptlrpc, mds, oss, mdd, osd, ldiskfs, lnet, libcfs, socklnd, o2iblnd; functional components like recovery, quota, grant; or auxiliary components like build, tests, docs. This subsystem list is not exhaustive, but provides a good guideline for consistency.
The rest of the comments should be wrapped to 70 columns or less. This allows for the first line to be used a subject in emails, and also for the entire body to be displayed using tools like git log or git shortlog in an 80 column window.
Please make sure the Change-Id: line and Signed-off-by: lines are at the bottom of the comment. This is required by the fs/lustre-release project (at least) in order for the patch to be approved. If your comments are missing either of these lines the patch will be automatically be rejected at submission time. See Using Gerrit for a description of the Change-Id: line .
Commit comment template
| No Format |
|---|
LU-000 component: short description of change under 64 columns
A more detailed explanation of the change being made. This can be
as detailed as you'd like, possibly several paragraphs in length.
Please provide a detailed explanation of what problem was solved,
a good high-level description of how it was solved, and which
parts of the code were affected (including function names as
needed, for easier searching). Wrap lines at 72 columns or less.
Signed-off-by: Random J Developer <random@developer.example.org>
Change-Id: Ica9ed1612eab0c4673dee088f8b441d806c64932
|
Examples of good commit comments are:
| No Format |
|---|
LU-477 ldiskfs: allocate s_group_desc/s_group_info by vmalloc()
Add the patch to the RHEL6 ldiskfs patch series.
Large kmalloc() for sbi->s_group_desc and sbi->s_group_info can fail
for large filesystems (typically over 16TB), which will cause the
"not enough memory" error while mounting. This patch makes allocation
fall back to vmalloc() if the kmalloc() failed, as what was done for
sbi->s_flex_groups.
To avoid colliding with an valid on-disk inode number, EXT4_BAD_INO
is used as the number of the buddy cache inode.
The patch also incorporates the following upstream kernel fix:
commit 32a9bb57d7c1fd04ae0f72b8f671501f000a0e9f
ext4: fix missing iput() of root inode for some mount error paths
https://bugzilla.kernel.org/show_bug.cgi?id=26752
Signed-off-by: Yu Jian <yujian whamcloud.com>
Change-Id: I3950425835ea7f2968ceb2edbc622e3ff3ed8545
|
| No Format |
|---|
LU-723 build: Enhance lustre/ldiskfs build system
Enhance the lustre/ldiskfs build system so it is more robust, flexible,
and consistent with lustre/zfs build system. This change is being made
in the interest of standardizing the infra-structure around backend
filesystems.
This change does not effect the current behavior of the --with-ldiskfs,
--enable-ext4, or --with-ldiskfsprogs configure options. However, it
does remove the obsolete --with-ldiskfs-inkernel configure option which
was only used by LLNL. It also adds the --with-ldiskfs-obj configure
option which improves flexibility. And the --enable-ldiskfs-build
configure option to support building against the lustre-ldiskfs-devel
package. The behavior of these options is consistent with their ZFS
counterparts, see commit 8c7266c for further details.
--enable-ext4 enable ldiskfs build using ext4
--enable-ldiskfs-build enable ldiskfs configure/make
--with-ldiskfs=path set path to ldiskfs source
--with-ldiskfs-obj=path set path to ldiskfs objects
--with-ldiskfsprogs use alternate names for ldiskfs-enabled e2fsprogs
Sample ./configure results when building lustre and ldiskfs using
the kernel-devel and kernel-debuginfo-common packages.
checking whether to enable ldiskfs... yes
checking ldiskfs source directory... /home/behlendo/src/git/lustre/ldiskfs
checking ldiskfs object directory... /home/behlendo/src/git/lustre/ldiskfs
checking ldiskfs module symbols... Module.symvers
checking ldiskfs source release... 3.3.0
checking whether to use ext3 or ext4 source... ext4
checking ext4 source directory... /usr/src/debug/.../fs/ext4
checking whether to build ldiskfs... yes
checking for /home/behlendo/src/git/lustre/ldiskfs/configure... yes
checking for /usr/src/debug/.../fs/ext4/dir.c... yes
checking for /usr/src/debug/.../fs/ext4/file.c... yes
checking for /usr/src/debug/.../fs/ext4/inode.c... yes
checking for /usr/src/debug/.../fs/ext4/super.c... yes
checking if ext4_ext_walk_space() takes i_data_sem... yes
checking if LDISKFS_SINGLEDATA_TRANS_BLOCKS takes sb as argument... yes
checking if ldiskfs_discard_preallocations defined... yes
checking if ldiskfs_ext_insert_extent needs 5 arguments... yes
In the context of this change additional cleanup has been done and
all of the ldiskfs specific code relocated to lustre-build-ldiskfs.m4.
Note that this change moves us closer to supporting patchless Lustre
servers with ldiskfs. Once the remaining kernel patches for Lustre
are dropped you will be able to build Lustre using the distribution
provided kernel-devel and kernel-debuginfo-common packages.
This change also incorperates ORI-340, commit f604951, which ensures
that the Module.symvers file will cleanly include the symbols for all
enabled Lustre backends. While the only backend supported by master
right now is ldiskfs this brings the master and orion branchs in to
sync in this regard.
Change-Id: I6f13f266944ec6967f4d7705a30b83ab8e577b15
Signed-off-by: Brian Behlendorf <behlendorf1 llnl.gov>
Signed-off-by: Prakash Surya <surya1 llnl.gov>
|
Submitting a change to a Lustre Release
...
Overview
Content Tools