Btrfs source repositories

From btrfs Wiki
Jump to: navigation, search

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated.

Since 2.6.29-rc1, Btrfs has been included in the mainline kernel.

Warning, Btrfs evolves very quickly do not test it unless:

  1. You have good backups and you have tested the restore capability
  2. You have a backup installation that you can switch to when something breaks
  3. You are willing to report any issues you find
  4. You can apply patches and compile the latest btrfs code against your kernel (quite easy with git and dkms, see below)
  5. You acknowledge that btrfs may eat your data
  6. Backups! Backups! Backups!

Everyone tests with the latest btrfs code from git. Even the latest Linus kernel probably doesn't have the latest, so if you're really interested in using and testing btrfs, get btrfs from git. Distributions usually offer a way to install a kernel built from git.

Contents

Kernel module

The kernel.org git repository is not used for development, only for pull requests that go to Linus and linux-next integration:

The following git repositories are used for development and are updated with patches from the mailinglist:

Branches are usually pushed to both repositories, either can be used.

There are:

  • main queue with patches for next development cycle (branch name misc-next)
  • queue with patches for current release cycle (the name has the version, eg for-4.15 or misc-4.15).
  • topic branches, eg. from a patchset picked from mailinglist
  • snapshots of for-next, that contain all of the above (eg. for-next-20200512)

Note that the branches get rebased. The base point for patches depend on the development phase. See Developer's_FAQ#Development_schedule. Independent changes can be based on the linus/master branch, changes that could depend on patches that have been added to one of the queues should use that as a base.

btrfs-progs git repository

Official repositories

The sources of the userspace utilities can be obtained from these repositories:

The master branch contains the latest released version and is never rebased.

Development git repositories:

For build dependencies and installation instructions please see [1]

Development branches

The latest development branch is called devel. Contains patches that are reviewed or tested and on the way to the next release. When a patch is added to the branch, a mail notification is sent as a reply to the patch.

The git repositories on kernel.org are not used for development or integration branches.

Note to GitHub users

The pull requests will not be accepted directly, the preferred way is to send patches to the mailinglist instead. You can link to a branch in any git repository if the mails do not make it to the mailinglist or for convenience.

The development model of btrfs-progs shares a lot with the kernel model. The github way is different in some ways. We, the upstream community, expect that the patches meet some criteria (often lacking in github contributions):

  • proper subject line: eg. prefix with btrfs-progs: subpart, ... , descriptive yet not too long
  • proper changelog: the changelogs are often missing or lacking explanation why the change was made, or how is something broken, what are user-visible effects of the bug or the fix, how does an improvement help or the intended usecase
  • the Signed-off-by line: this document who authored the change, you can read more about the The Developer's Certificate of Origin here (chapter 11)
  • one logical change per patch: eg. not mixing bugfixes, cleanups, features etc., sometimes it's not clear and will be usually pointed out during reviews

Administration and support tools

There is a separate repository of useful scripts for common administrative tasks on btrfs. This is at:

https://github.com/kdave/btrfsmaintenance/

Patches sent to mailinglist

A convenient interface to get an overview of patches and the related mail discussions can be found at https://patchwork.kernel.org/project/linux-btrfs/list/ .

It is possible to directly apply a patch by pasting the mbox link from the patch page to the command

$ wget -O - 'https://patchwork.kernel.org/patch/123456/mbox' | git am -

you may want to add --reject, or decide otherwise what to do with the patch.

Personal tools