RFE: add function 'bd_btrfs_replace_device' to btrfs plugin
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c, linux
- Domain
- operating-systems
Research direction
The request is to add a bd_btrfs_replace_device function to the btrfs plugin, wrapping btrfs replace start as an alternative to the add-then-remove sequence. Read the existing btrfs plugin device-management functions first, using the linked UDisks BTRFS documentation as the reference for the expected behaviour. Done means a new function, its test coverage, and a note on the size caveat that the replacement device must be at least as large as the source.
Written by the indexing model from the issue text.
Description
http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Filesystem.BTRFS.html
Instead of AddDevice followed by RemoveDevice, it's preferred to use btrfs replace. Both btrfs device add/remove imply file system resize, and also a relatively expensive balance. Whereas replace is a variation on scrub, and is a sort of virtual and temporary raid1 between the device being replaced and the new device. Both devices are used for reads and writes, so there's better safety as well as performance.
There are two current caveats: the replacement block device must be equal to or larger than the device being replaced; and once replacement is complete, there is no automatic resize (grow) to take advantage of space for a larger device.
It's actually more expedient to do a minimal resize (shrink) of a device being replaced, in order to make it possible to use replace instead of add followed by remove.
man btrfs replace
start [-Bfr] <srcdev>|<devid> <targetdev> <path>
_Originally posted by @cmurf in https://github.com/storaged-project/udisks/issues/803
- Dominant language
- C
- Stars
- 137
- Forks
- 64
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from storaged-project/libblockdev
-
fails to build with libnvme3 (nvme-cli 3.0)Possibly taken @tbzatek claimed this 43 days ago. Open
storaged-project/libblockdev#1211 · 4 comments · 1 assignee ·
-
RFE
Difficulty 3/5 1-2 days Newbie friendliness 35/100
storaged-project/libblockdev#1093 · 3 comments ·
-
Difficulty 4/5 Over a week Newbie friendliness 18/100
storaged-project/libblockdev#1067 ·
-
Difficulty 3/5 Half a day Newbie friendliness 40/100
storaged-project/libblockdev#1060 · 1 comment ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 12/100
storaged-project/libblockdev#977 · 1 comment ·
All issues in storaged-project/libblockdev
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
JustAResearcher/gpu-unlock-ada#98 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug intrinsic medium priority rt_lib
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[CLI] Clarify distinction between 'capture camera' and 'capture screen' in help text and outputOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
espressif/esp-vision#18 ·