Re: [PATCH] Improve ext2 driver to allow embedding of the boot loader code.

["Dr. Tilmann Bubeck" <tilmann@bubecks.de>]

The allocated space is reused every time on grub-setup execution. It 
does not change, as long as it is big enough. As Andrew said, by 
allocating 10 MB in the first run, it will be big enough for the 
foreseeable future (currently core.img on my system is 30k).

After issuing the ioctl(EXT4_IOC_SWAP_BOOT) it is not a file anymore. It 
is only a (reserved) inode with data blocks. There is no filename 
associated in any directory. So user tools have no way to manipulate the 
data.

fsck is aware of this and will not change anything or report any error.

I do not see, why we need another user space tool for the initial 
allocation. The initial reservation and subsequent use of the data 
blocks can be done by grub-setup very easy and is already part of the patch.


Tilmann


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