On 2024-03-10, Michael <confabul...@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
