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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <lists@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 majordomo@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
No idea what that means. On Dec 3, 2012, at 12:52 AM, Rock Lee <zimilo@code-trick.com> wrote:> 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 <lists@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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 03, 2012 at 12:34:06AM -0700, Chris Murphy wrote:> 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. >Right, I wanted to leave room for bootloaders. I actually would have used a larger offset, but the other filesystem mkfs commands don''t zero very far into the drive. I had to make sure that mkfs.foo would overwrite the btrfs super, otherwise you might have a stale btrfs filesystem recognized inside the new filesystem.> 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.The alloc start doesn''t change the location of the super, just the preferred location for any blocks we allocate. The idea was to test huge drives without having to fill them with data. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 03, 2012 at 12:34:06AM -0700, Chris Murphy wrote:> 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?If you want some historical reading check out the ''BTRFS partition usage...'' messages in: https://oss.oracle.com/pipermail/btrfs-devel/2008-February/ - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html