On 21.01.2014 09:41, Andrey Borzenkov wrote: > On Tue, Jan 21, 2014 at 12:32 PM, Vladimir 'φ-coder/phcoder' > Serbinenko <phco...@gmail.com> wrote: >> On 21.01.2014 09:28, Andrey Borzenkov wrote: >>> On Tue, Jan 21, 2014 at 12:14 PM, Vladimir 'φ-coder/phcoder' >>> Serbinenko <phco...@gmail.com> wrote: >>>> On 10.01.2014 08:49, Dr. Tilmann Bubeck wrote: >>>>> >>>>> The blocklist is fixed and stable and will never change. >>>> What guarantees that it won't change on grub-setup invocation? I'm under >>>> impression that it will change on every grub-setup invocation as file >>>> gets recreated. >>>> >>> >>> If I read code correctly, it checks current size and if new core.img >>> fits, space is reused. So we could effectively make it preallocate >>> reasonable size (or even unreasonable - I guess 10MB will be enough >>> for foreseeable future) the very first time it is done. >>> >> It still doesn't solve the problem that during operations file becomes a >> normal file and OS is allowed to rearrange the blocks as it sees fit. > > Would this be acceptable - use external utility to allocate > EXT2_BOOT_LOADER_INO space of sufficient size once (outside of grub at > all) and allow embedding into extX if this space exists? Do not mess > with with it in grub-setup itself? > This presents a problem with sync'ing. After this space was reserved it won't appear when using block functions until next sync'ing. This would result in install failure on a new filesystem. > We could then speak with ext2 folks to add option to mke2fs/une2fs in > the long run it it does not exist yet. > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
