Block headers now store the chunk tree uuid
Chunk items records the device uuid for each stripes
Device extent items record better back refs to the chunk tree
Block groups record better back refs to the chunk tree
The chunk tree format has also changed. The objectid of BTRFS_CHUNK_ITEM_KEY
used to be the logical offset of the chunk. Now it is a chunk tree id,
with the logical offset being stored in the offset field of the key.
This allows a single chunk tree to record multiple logical address spaces,
upping the number of bytes indexed by a chunk tree from 2^64 to
2^128.
When a block is freed, it can be immediately reused if it is from
the current transaction. But, an extra check is required to make sure
the block had not been written yet. If it were reused after being written,
the transid in the block header might match the transid of the
next time the block was allocated.
The parent node records the transaction ID of the block it is pointing to,
and this is used as part of validating the block on reads. So, there
can only be one version of a block per transaction.
The mkfs code bootstraps the filesystem on a single device. Once
the raid block groups are setup, it needs to recow all of the blocks so
that each tree is properly allocated.
mkfs.btrfs --data {raid0,raid1,single}
mkfs.btrfs --metadata {raid0,raid1,single}
In single mode, no extra duplication or striping is done.
In raid0 mode, blocks are spread across all of the available devices
In raid1 mode, blocks are mirrored across two devices.
For metadata, if raid1 is used and there is only one device, the
metadata is duplicated on that single spindle.
The defaults are raid0 for data and raid1 for metadata
We get lots of warnings of the flavor:
utils.c:441: warning: format '%Lu' expects type 'long long unsigned int' but argument 2 has type 'u64'
And thanks to -Werror, the build fails. Clean up these printfs
by properly casting the arg to the format specified.
Signed-off-by: Alex Chiang <achiang@hp.com>
In btrfs_name_hash, Local variable 'buf' is declared as
__u32 buf[2];
but we then try to do this:
buf[0] = 0x67452301;
buf[1] = 0xefcdab89;
buf[2] = 0x98badcfe;
buf[3] = 0x10325476;
Oops. Fix buf to be the proper size.
Signed-off-by: Alex Chiang <achiang@hp.com>
This saves from the blunder of formatting a live mounted filesystem.
This can be extended to get the mount flags of the filesystem
mounted.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@gmail.com>
When freeing root block of a tree, btrfs_free_extent' parameter
'ref_generation' is from root block itseft. When freeing non-root
block, 'ref_generation' is from its parent. so when converting a
non-root block to root block, we must guarantee its generation is
equal to its parent's generation.
The first problem is that these SETGET macros lose typing information,
and therefore can't see the 'packed' attribute and therefore take
unaligned access SIGBUS signals on sparc64 when trying to derefernce
the member.
The next problem is a similar issue in btrfs_name_hash(). This gets
passed things like &key.offset which is a member of a packed
structure, losing this packed'ness information btrfs_name_hash()
performs a potentially unaligned memory access, again resulting in a
SIGBUS.
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(-)
Using strncpy avoids a 1 byte overflow into the next field
of the struct. The overflow is harmless, but does
trip automated tools.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
---
utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
btrfs_find_free_objectid may return a used objectid due to arithmetic
underflow. This bug may happen when parameter 'root' is tree root, so
it may cause serious problems when creating snapshot or sub-volume.
