[gentoo-user] Re: How to set up drive with many Linux distros?

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2024-03-10, Michael <confabulate@kintzios.com> wrote:

> Perhaps I'm picking up on semantics, but shouldn't this sentence:
>
> "... The gap between the DOS disklabel and the first partition"
>
> read:
>
> "The gap between the MBR and the first partition"?

Yes, thanks -- MBR is more accurate, I've changed that sentence.

> Your next paragraph pointed out something which I hadn't considered at any 
> length.  Namely, the installation of GRUB's boot.img in a MBR or VBR also 
> hardcodes in a block list format the location of the first sector where the 
> core.img is stored and more importantly, the physical position of this sector 
> can be altered both by COW fs (and by the wear levelling firmware of flash 
> storage devices).
>
> I had assumed both the COW fs and/or the flash controller will in
> both cases translate any physical data position to the logical layer
> and presented this to inquiring software.  Have you actually tried
> using btrfs as a distro's root fs to see if the VBR installed GRUB
> boot.img will ever lose access to the core.img?

No, I haven't. I agree that the flash controller can't change the
logical address of a filesystem data block without the knowledge of the
filesystem, so I don't think controller layer wear-leveling would be
a problem. But, the filesystem layer is allowed to move data blocks
around, so flash-aware filesystems that attempt to do wear-leveling
or defragmentation could move data blocks.

Some of the descriptions I've read of "fancier" filesystem internals
have also implied implied that does happen under certain conditions,
but I may have misunderstood or the descriptions may have been wrong.

My use of these multi-boot installs have no need for anything beyond
exnN, so I've never tried using block lists with anything other than
extN filesystems. Since I am confident extN filesystems won't cause
problems, I've always stuck with that.

--
Grant