This commit introduces a new command called 'btrfs' for managing
a btrfs filesystem. 'btrfs' handles:
- snapshot/subvolume creation
- adding/removal of volume (ie: disk)
- defragment of a tree
- scan of a device searching a btrfs filesystem
- re-balancing of the chunk on the disks
- listing subvolumes and snapshots
This has also been updated to include the new defrag range ioctl.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This allows us to figure out which physical byte offset on which device
is the real location for a given logical block number. It can
optionally read the block in and save it to a file for debugging
analysis.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
This commit introduces a new kind of back reference for btrfs metadata.
Once a filesystem has been mounted with this commit, IT WILL NO LONGER
BE MOUNTABLE BY OLDER KERNELS.
The new back ref provides information about pointer's key, level and in which
tree the pointer lives. This information allow us to find the pointer by
searching the tree. The shortcoming of the new back ref is that it only works
for pointers in tree blocks referenced by their owner trees.
This is mostly a problem for snapshots, where resolving one of these fuzzy back
references would be O(number_of_snapshots) and quite slow. The solution used
here is to use the fuzzy back references in the common case where a given tree
block is only referenced by one root, and use the full back references when
multiple roots have a reference
This patch adds btrfs image tool. The image tool is
a debugging tool that creates/restores btrfs metadump
image.
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
This patch does the following:
1) Update device management code to match the kernel code.
2) Allocator fixes.
3) Add a program called btrfstune to set/clear the SEEDING
super block flags.
Gcc only sends warnings for uninitialized variables when you compile with -O,
and there were a couple of bugs sprinkled in the code. The biggest was the
alloc_start variable for mkfs, which can cause strange things to happen.
(thanks to Gabor Micsko for helping to find this)
Add -D_FORTIFY_SOURCE=2 to the makeflags. It has been very helpful
in finding problems.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Split CFLAGS into CFLAGS (user part) and AM_CFLAGS (not-so-user part;
variable name taken from automake, but otherwise no relation).
Also add LDFLAGS.
This allows me to use `make CFLAGS="-O2 -fPIE" LDFLAGS="-pie"` without
dropping the other important (AM_CFLAGS) flags.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
---
btrfs-progs/Makefile | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
The dependency archive ".depend" is only created once.
Changing a C file's dependencies does not remake .depend,
so make will recompile either too few or too many things.
Use of per-.c file dependencies that are created and update
during compile solve this.
