You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This commit adds zone-aware magics and probing functions for zoned btrfs. The superblock (and its copies) are the only data structure in btrfs with a fixed location on a device. Since we cannot do overwrites in a sequential write required zone, we cannot place the superblock in the zone. Thus, zoned btrfs uses superblock log writing to update superblocks on sequential write required zones. It uses two zones as a circular buffer to write updated superblocks. Once the first zone is filled up, start writing into the second buffer. When both zones are filled up, and before starting to write to the first zone again, it reset the first zone. We can determine the position of the latest superblock by reading the write pointer information from a device. One corner case is when both zones are full. For this situation, we read out the last superblock of each zone and compare them to determine which zone is older. The magics can detect a superblock magic ("_BHRfs_M") at the beginning of zone #0 or zone #1 to see if it is zoned btrfs. When both zones are filled up, zoned btrfs resets the first zone to write a new superblock. If btrfs crashes at the moment, we do not see a superblock at zone #0. Thus, we need to check not only zone #0 but also zone #1. It also supports the temporary magic ("!BHRfS_M") in zone #0. Mkfs.btrfs first writes the temporary superblock to the zone during the mkfs process. It will survive there until the zones are filled up and reset. So, we also need to detect this temporary magic. Finally, this commit extends probe_btrfs() to load the latest superblock determined by the write pointers. Signed-off-by: Naohiro Aota <email@example.com>
|1 year ago|
|.github/workflows||2 years ago|
|Documentation||1 year ago|
|bash-completion||1 year ago|
|config||5 years ago|
|disk-utils||1 year ago|
|include||1 year ago|
|lib||1 year ago|
|libblkid||1 year ago|
|libfdisk||1 year ago|
|libmount||2 years ago|
|libsmartcols||1 year ago|
|libuuid||1 year ago|
|login-utils||1 year ago|
|m4||2 years ago|
|man-common||1 year ago|
|misc-utils||1 year ago|
|po||1 year ago|
|po-man||1 year ago|
|schedutils||1 year ago|
|sys-utils||1 year ago|
|term-utils||1 year ago|
|tests||1 year ago|
|text-utils||1 year ago|
|tools||2 years ago|
|.editorconfig||7 years ago|
|.gitignore||1 year ago|
|.travis-functions.sh||2 years ago|
|.travis.yml||2 years ago|
|AUTHORS||1 year ago|
|COPYING||11 years ago|
|ChangeLog||2 years ago|
|Makefile.am||1 year ago|
|NEWS||1 year ago|
|README||2 years ago|
|README.licensing||3 years ago|
|autogen.sh||5 years ago|
|configure.ac||1 year ago|
|meson.build||1 year ago|
|meson_options.txt||2 years ago|
|util-linux.doap||6 years ago|
util-linux is a random collection of Linux utilities
Note: for the years 2006-2010 this project was named "util-linux-ng".
COMPILE & INSTALL:
The mailing list will reject email messages that contain:
- more than 100K characters
- spam phrases/keywords
#util-linux at freenode.net:
The IRC channel and Mailing list are for developers and project
maintainers. For end users it is recommended to utilize the
distribution's support system.
This project has no resources to provide support for distribution specific
issues. For end users it is recommended to utilize the distribution's
NLS (PO TRANSLATIONS):
PO files are maintained by:
major = fatal and deep changes
minor = typical release with new features
maint = maintenance releases; bug fixes only
SCM (Source Code Management) Repository:
git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
git clone git://github.com/karelzak/util-linux.git
Note: the GitHub repository may contain temporary development branches too.
The kernel.org repository contains master (current development) and stable/*
(maintenance) branches only. All master or stable/* changes are always pushed
to both repositories at the same time.
Repository Branches: 'git branch -a'
- current development
- the source for stable releases when deemed ready.
- day-to-day status is: 'it works for me'. This means that its
normal state is useful but not well tested.
- long-term development or invasive changes in active development are
forked into separate 'topic' branches from the tip of 'master'.
- public releases
- branch name: stable/v<major>.<minor>.
- created from the 'master' branch after two or more release
candidates and the final public release. This means that the stable
releases are committed, tagged, and reachable in 'master'.
- these branches then become forked development branches. This means
that any changes made to them diverge from the 'master' branch.
- maintenance releases are part of, and belong to, their respective
stable branch. As such, they are tags(<major>.<minor>.<maint>) and
not branches of their own. They are not part of, visible in, or
have anything to do with the 'master' development branch. In git
terminology: maintenance releases are not reachable from 'master'.
- when initially cloned (as with the 'git clone' command given above)
these branches are created as 'remote tracking branches' and are
only visible by using the -a or -r options to 'git branch'. To
create a local branch use the desired tag with this command:
'git checkout -b v2.29.2 v2.29.2'
Tags: 'git tag'
- a new tag object is created for every release.
- tag name: v<version>.
- all tags are signed by the maintainer's PGP key.
- don't use tag v2.13.1 (created and published by mistake),
use v2.13.1-REAL instead.
1) development (branch: <master>)
2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
3) development (work on v2.30, branch: <master>)
4) fork -- create a new branch <stable/v2.29> based on tag v2.29
4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
4c) more patches; another release (tag: v2.29.2, branch: <stable/v2.29>)
5) master release v2.30 (branch: <master>)
where 3) and 4) happen simultaneously.