From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8E45A158041 for ; Sun, 10 Mar 2024 18:35:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9697E2A4F; Sun, 10 Mar 2024 18:35:39 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5FAD0E2A25 for ; Sun, 10 Mar 2024 18:35:39 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rjO1J-0004fH-O3 for gentoo-user@lists.gentoo.org; Sun, 10 Mar 2024 19:35:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: How to set up drive with many Linux distros? Date: Sun, 10 Mar 2024 18:35:29 -0000 (UTC) Message-ID: References: <1882593.tdWV9SEqCh@rogueboard> User-Agent: slrn/1.0.3 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 0f4c6a7f-97ee-4724-a71e-fe83624c8044 X-Archives-Hash: 2ae6ea366173060ab3fa422e8bdc1d46 On 2024-03-10, Michael 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