Maybe this function could give you a little explanation.
static inline u64 btrfs_sb_offset(int mirror)
{
u64 start = 16 * 1024;
if (mirror)
return start << (BTRFS_SUPER_MIRROR_SHIFT * mirror);
return BTRFS_SUPER_INFO_OFFSET;
}
and BTRFS_SUPER_INFO_OFFSET is (64 * 1024)
2012/12/3 Chris Murphy <li...@colorremedies.com>:
> When creating a btrfs volume with mkfs.btrfs, I'm noticing that the first
> 64KB are completely blank. Is this gap expressly intended for installing a
> boot manager/loader? e.g. GRUB 2 allows installation of boot.img + core.img
> into a btrfs formatted partition, without using block lists (the --force
> flag). It appears to produce a bootable system.
>
> However, the man page says -A, --alloc-start specifies the offset to the
> start of the file system, and that the default is zero. If the default is
> zero, the file system starts immediately, which implies those 64KB of zero
> aren't actually intended for a boot loader.
>
> In all three of these examples:
> mkfs.btrfs /dev/sda1
> mkfs.btrfs -A 5000 /dev/sda1
> mkfs.btrfs -A 50000 /dev/sda1
>
> I get the same results for:
> hexdump -C /dev/sda1
>
> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00010000 66 0d 21 28 00 00 00 00 00 00 00 00 00 00 00 00 |f.!(….........|
>
> The file system appears to start at the same point in all cases. I zero'd the
> first 500MB of the partition in between each mkfs attempt.
>
> What am I misunderstanding, or is this a bug?
>
>
> Chris Murphy--
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
