On 21.01.2014 09:41, Andrey Borzenkov wrote:
On Tue, Jan 21, 2014 at 12:32 PM, Vladimir 'φ-coder/phcoder'
Serbinenko <address@hidden> wrote:
On 21.01.2014 09:28, Andrey Borzenkov wrote:
On Tue, Jan 21, 2014 at 12:14 PM, Vladimir 'φ-coder/phcoder'
Serbinenko <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel