On Sun, May 29, 2016 at 12:23 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > 20.05.2016 20:59, Austin S. Hemmelgarn пишет: >> On 2016-05-20 13:02, Ferry Toth wrote: >>> We have 4 1TB drives in MBR, 1MB free at the beginning, grub on all 4, >>> then 8GB swap, then all the rest btrfs (no LVM used). The 4 btrfs >>> partitions are in the same pool, which is in btrfs RAID10 format. /boot >>> is in subvolume @boot. >> If you have GRUB installed on all 4, then you don't actually have the >> full 2047 sectors between the MBR and the partition free, as GRUB is >> embedded in that space. I forget exactly how much space it takes up, >> but I know it's not the whole 1023.5K I would not suggest risking usage >> of the final 8k there though. > > If you mean grub2, required space is variable and depends on where > /boot/grub is located (i.e. which drivers it needs to access it). > Assuming plain btrfs on legacy BIOS MBR, required space is around 40-50KB. > > Note that grub2 detects some post-MBR gap software signatures and skips > over them (space need not be contiguous). It is entirely possible to add > bcache detection if enough demand exists.
Might not be a bad idea, just to avoid it getting stepped on and causing later confusion. If it is stepped on I don't think there's data loss except possibly in the case where there's an unclean shutdown where the SSD has bcache data that hasn't been committed to the HDD? But I'm skeptical of bcache using a hidden area historically for the bootloader, to put its device metadata. I didn't realize that was the case. Imagine if LVM were to stuff metadata into the MBR gap, or mdadm. Egads. -- 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
