1
- OpenZFS Patches
1
+ illumos Patches
2
2
===============
3
3
4
- The ZFS on Linux project is an adaptation of the upstream `OpenZFS
5
- repository <https://github.com/openzfs/openzfs/> `__ designed to work in
6
- a Linux environment. This upstream repository acts as a location where
7
- new features, bug fixes, and performance improvements from all the
8
- OpenZFS platforms can be integrated. Each platform is responsible for
9
- tracking the OpenZFS repository and merging the relevant improvements
10
- back in to their release.
11
-
12
- For the ZFS on Linux project this tracking is managed through an
13
- `OpenZFS tracking <http://build.zfsonlinux.org/openzfs-tracking.html >`__
14
- page. The page is updated regularly and shows a list of OpenZFS commits
15
- and their status in regard to the ZFS on Linux master branch.
16
-
17
- This page describes the process of applying outstanding OpenZFS commits
18
- to ZFS on Linux and submitting those changes for inclusion. As a
19
- developer this is a great way to familiarize yourself with ZFS on Linux
4
+ The OpenZFS tracks illumos ZFS patches at the
5
+ `illumos Tracking <http://build.zfsonlinux.org/openzfs-tracking.html >`__
6
+ page. The page is updated regularly and shows a list of illumos commits
7
+ and their status in regard to the OpenZFS master branch.
8
+
9
+ This page describes the process of applying outstanding illumos commits
10
+ to OpenZFS and submitting those changes for inclusion. As a
11
+ developer this is a great way to familiarize yourself with OpenZFS
20
12
and to begin quickly making a valuable contribution to the project. The
21
13
following guide assumes you have a `github
22
14
account <https://help.github.com/articles/signing-up-for-a-new-github-account/> `__,
23
15
are familiar with git, and are used to developing in a Linux
24
16
environment.
25
17
26
- Porting OpenZFS changes to ZFS on Linux
27
- ---------------------------------------
18
+ Porting illumos changes to OpenZFS
19
+ ----------------------------------
28
20
29
21
Setup the Environment
30
22
~~~~~~~~~~~~~~~~~~~~~
31
23
32
24
**Clone the source. ** Start by making a local clone of the
33
- `spl <https://github.com/zfsonlinux/spl >`__ and
34
- `zfs <https://github.com/zfsonlinux/zfs >`__ repositories.
25
+ `zfs <https://github.com/zfsonlinux/zfs >`__ repository.
35
26
36
27
::
37
28
38
- $ git clone -o zfsonlinux https://github.com/zfsonlinux/spl.git
39
29
$ git clone -o zfsonlinux https://github.com/zfsonlinux/zfs.git
40
30
41
31
**Add remote repositories. ** Using the GitHub web interface
42
32
`fork <https://help.github.com/articles/fork-a-repo/ >`__ the
43
33
`zfs <https://github.com/zfsonlinux/zfs >`__ repository in to your
44
34
personal GitHub account. Add your new zfs fork and the
45
- `openzfs <https://github.com/openzfs/openzfs / >`__ repository as remotes
46
- and then fetch both repositories. The OpenZFS repository is large and
47
- the initial fetch may take some time over a slow connection.
35
+ `illumos-gate <https://github.com/illumos/illumos-gat / >`__ repository as
36
+ remotes and then fetch both repositories. The illumos-gate repository is large
37
+ and the initial fetch may take some time over a slow connection.
48
38
49
39
::
50
40
51
41
$ cd zfs
52
42
$ git remote add <your-github-account> [email protected] :<your-github-account>/zfs.git
53
- $ git remote add openzfs https://github.com/openzfs/openzfs .git
43
+ $ git remote add illumos-gate https://github.com/illumos/illumos-gate .git
54
44
$ git fetch --all
55
45
56
- **Build the source. ** Compile the spl and zfs master branches. These
57
- branches are always kept stable and this is a useful verification that
46
+ **Build the source. ** Compile the zfs master branch. This branch
47
+ is always kept stable and this is a useful verification that
58
48
you have a full build environment installed and all the required
59
49
dependencies are available. This may also speed up the compile time
60
50
latter for small patches where incremental builds are an option.
61
51
62
52
::
63
53
64
- $ cd ../spl
65
- $ sh autogen.sh && ./configure --enable-debug && make -s -j$(nproc)
66
- $
67
54
$ cd ../zfs
68
55
$ sh autogen.sh && ./configure --enable-debug && make -s -j$(nproc)
69
56
70
57
Pick a patch
71
58
~~~~~~~~~~~~
72
59
73
- Consult the `OpenZFS
74
- tracking <http://build.zfsonlinux.org/openzfs -tracking.html> `__ page and
60
+ Consult the `illumos
61
+ tracking <http://build.zfsonlinux.org/illumos -tracking.html> `__ page and
75
62
select a patch which has not yet been applied. For your first patch you
76
63
will want to select a small patch to familiarize yourself with the
77
64
process.
@@ -123,7 +110,7 @@ Download the script:
123
110
./openzfs-merge.sh -d path_to_zfs_folder -c openzfs_commit_hash
124
111
125
112
This command will fetch all repositories, create a new branch
126
- ``autoport-ozXXXX `` (XXXX - OpenZFS issue number), try to cherry-pick,
113
+ ``autoport-ozXXXX `` (XXXX - illumos issue number), try to cherry-pick,
127
114
compile and check cstyle on success.
128
115
129
116
If it succeeds without any merge conflicts - go to ``autoport-ozXXXX ``
@@ -161,21 +148,21 @@ Manual merge
161
148
^^^^^^^^^^^^
162
149
163
150
**Create a new branch. ** It is important to create a new branch for
164
- every commit you port to ZFS on Linux . This will allow you to easily
151
+ every commit you port to OpenZFS . This will allow you to easily
165
152
submit your work as a GitHub pull request and it makes it possible to
166
153
work on multiple OpenZFS changes concurrently. All development branches
167
- need to be based off of the ZFS master branch and it's helpful to name
154
+ need to be based off of the OpenZFS master branch and it's helpful to name
168
155
the branches after the issue number you're working on.
169
156
170
157
::
171
158
172
- $ git checkout -b openzfs -<issue-nr> master
159
+ $ git checkout -b illumos -<issue-nr> master
173
160
174
161
**Generate a patch. ** One of the first things you'll notice about the
175
- ZFS on Linux repository is that it is laid out differently than the
176
- OpenZFS repository. Organizationally it is much flatter, this is
162
+ OpenZFS repository is that it is laid out differently than the
163
+ illumos-gate repository. Organizationally it is much flatter, this is
177
164
possible because it only contains the code for OpenZFS not an entire OS.
178
- That means that in order to apply a patch from OpenZFS the path names in
165
+ That means that in order to apply a patch from illumos the path names in
179
166
the patch must be changed. A script called zfs2zol-patch.sed has been
180
167
provided to perform this translation. Use the ``git format-patch ``
181
168
command and this script to generate a patch.
@@ -197,51 +184,54 @@ cleanly while preserving the its original intent.
197
184
198
185
::
199
186
200
- $ git am ./openzfs -<commit-nr>.diff
187
+ $ git am ./illumos -<commit-nr>.diff
201
188
202
189
**Update the commit message. ** By using ``git format-patch `` to generate
203
190
the patch and then ``git am `` to apply it the original comment and
204
191
authorship will be preserved. However, due to the formatting of the
205
- OpenZFS commit you will likely find that the entire commit comment has
192
+ illumos commit you will likely find that the entire commit comment has
206
193
been squashed in to the subject line. Use ``git commit --amend `` to
207
194
cleanup the comment and be careful to follow `these standard
208
195
guidelines <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html> `__.
209
196
210
- The summary line of an OpenZFS commit is often very long and you should
197
+ The summary line of an illumos commit is often very long and you should
211
198
truncate it to 50 characters. This is useful because it preserves the
212
199
correct formatting of ``git log --pretty=oneline `` command. Make sure to
213
200
leave a blank line between the summary and body of the commit. Then
214
- include the full OpenZFS commit message wrapping any lines which exceed
201
+ include the full illumos commit message wrapping any lines which exceed
215
202
72 characters. Finally, add a ``Ported-by `` tag with your contact
216
- information and both a ``OpenZFS -issue `` and ``OpenZFS -commit `` tag with
203
+ information and both a ``illumos -issue `` and ``illumos -commit `` tag with
217
204
appropriate links. You'll want to verify your commit contains all of the
218
205
following information:
219
206
220
- - The subject line from the original OpenZFS patch in the form:
221
- "OpenZFS <issue-nr> - short description".
207
+ - The subject line from the original illumos patch in the form:
208
+ "illumos <issue-nr> - short description".
222
209
- The original patch authorship should be preserved.
223
- - The OpenZFS commit message.
210
+ - The illumos commit message.
224
211
- The following tags:
225
212
226
213
- **Authored by: ** Original patch author
227
- - **Reviewed by: ** All OpenZFS reviewers from the original patch.
228
- - **Approved by: ** All OpenZFS reviewers from the original patch.
214
+ - **Reviewed by: ** All illumos reviewers from the original patch.
215
+ - **Approved by: ** All illumos reviewers from the original patch.
229
216
- **Ported-by: ** Your name and email address.
230
- - **OpenZFS -issue: ** https ://www.illumos.org/issues/issue
231
- - **OpenZFS -commit: ** https
232
- ://github.com/openzfs/openzfs /commit/hash
217
+ - **illumos -issue: ** https ://www.illumos.org/issues/issue
218
+ - **illumos -commit: ** https
219
+ ://github.com/illumos/illumos-gate /commit/hash
233
220
234
221
- **Porting Notes: ** An optional section describing any changes
235
222
required when porting.
236
223
237
- For example, OpenZFS issue 6873 was `applied to
238
- Linux <https://github.com/zfsonlinux/zfs/commit/b3744ae> `__ from this
239
- upstream `OpenZFS
240
- commit <https://github.com/openzfs/openzfs/commit/ee06391> `__.
224
+ For example, illumos issue 6873 was `applied to
225
+ OpenZFS <https://github.com/openzfs/openzfs/commit/b3744ae> `__ from this
226
+ upstream `illumos
227
+ commit <https://github.com/illumos/illumos-gate/commit/ee06391> `__. Note
228
+ that this example predates the OpenZFS renaming, so the real commit uses
229
+ "OpenZFS" instead of "illumos"; the example below show how it should look
230
+ if done today.
241
231
242
232
::
243
233
244
- OpenZFS 6873 - zfs_destroy_snaps_nvl leaks errlist
234
+ illumos 6873 - zfs_destroy_snaps_nvl leaks errlist
245
235
246
236
Authored by: Chris Williamson <[email protected] >
247
237
Reviewed by: Matthew Ahrens <[email protected] >
@@ -251,8 +241,8 @@ commit <https://github.com/openzfs/openzfs/commit/ee06391>`__.
251
241
lzc_destroy_snaps() returns an nvlist in errlist.
252
242
zfs_destroy_snaps_nvl() should nvlist_free() it before returning.
253
243
254
- OpenZFS -issue: https://www.illumos.org/issues/6873
255
- OpenZFS -commit: https://github.com/openzfs/openzfs/commit/ee06391
244
+ illumos -issue: https://www.illumos.org/issues/6873
245
+ illumos -commit: https://github.com/openzfs/openzfs/commit/ee06391
256
246
257
247
Testing a Patch
258
248
~~~~~~~~~~~~~~~
@@ -275,7 +265,7 @@ checker, the command should return without printing any output.
275
265
style checks `open a new pull
276
266
request <https://help.github.com/articles/creating-a-pull-request/> `__.
277
267
The pull request will be queued for `automated
278
- testing <https://github.com/zfsonlinux /zfs-buildbot/> `__. As part of the
268
+ testing <https://github.com/openzfs /zfs-buildbot/> `__. As part of the
279
269
testing the change is built for a wide range of Linux distributions and
280
270
a battery of functional and stress tests are run to detect regressions.
281
271
@@ -285,10 +275,10 @@ a battery of functional and stress tests are run to detect regressions.
285
275
286
276
**Fix any issues. ** Testing takes approximately 2 hours to fully
287
277
complete and the results are posted in the GitHub `pull
288
- request <https://github.com/zfsonlinux /zfs/pull/4594> `__. All the tests
278
+ request <https://github.com/openzfs /zfs/pull/4594> `__. All the tests
289
279
are expected to pass and you should investigate and resolve any test
290
280
failures. The `test
291
- scripts <https://github.com/zfsonlinux /zfs-buildbot/tree/master/scripts> `__
281
+ scripts <https://github.com/openzfs /zfs-buildbot/tree/master/scripts> `__
292
282
are all available and designed to run locally in order reproduce an
293
283
issue. Once you've resolved the issue force update the pull request to
294
284
trigger a new round of testing. Iterate until all the tests are passing.
@@ -302,17 +292,8 @@ trigger a new round of testing. Iterate until all the tests are passing.
302
292
Merging the Patch
303
293
~~~~~~~~~~~~~~~~~
304
294
305
- **Review. ** Lastly one of the ZFS on Linux maintainers will make a final
295
+ **Review. ** Lastly one of the OpenZFS maintainers will make a final
306
296
review of the patch and may request additional changes. Once the
307
297
maintainer is happy with the final version of the patch they will add
308
298
their signed-off-by, merge it to the master branch, mark it complete on
309
299
the tracking page, and thank you for your contribution to the project!
310
-
311
- Porting ZFS on Linux changes to OpenZFS
312
- ---------------------------------------
313
-
314
- Often an issue will be first fixed in ZFS on Linux or a new feature
315
- developed. Changes which are not Linux specific should be submitted
316
- upstream to the OpenZFS GitHub repository for review. The process for
317
- this is described in the `OpenZFS
318
- README <https://github.com/openzfs/openzfs/> `__.
0 commit comments