From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1W5hdH-0004Mv-BR for mharc-grub-devel@gnu.org; Tue, 21 Jan 2014 15:09:11 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5hdA-0004M1-IN for grub-devel@gnu.org; Tue, 21 Jan 2014 15:09:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5hd5-0006KZ-RA for grub-devel@gnu.org; Tue, 21 Jan 2014 15:09:04 -0500 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::7]:51957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5hd5-0006KQ-GX for grub-devel@gnu.org; Tue, 21 Jan 2014 15:08:59 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1390334937; l=2858; s=domk; d=bubecks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=M4GJWUaVf2/k65ovag4ndNWvmQI=; b=a9lZI3muO5/FnRytWc6Lo8EiBAVjvgGIF6FgIwZZpSSAcOxm6Dn62KjCiNpAeR5EA5J aJfhETNYlqqnjApSVA9yKWPYe2cMgU5rCEKPK4Ykg14o31p/L+nDcFJKwHvs1zlehcfz1 blnK2q+He62xGBsdQ15bpfTxz+6LQBPCORI= X-RZG-AUTH: :OGUIeEGmdd9LocaRWNUrTCqIQctGnGgg+eszxi8Zzh68aZhci43fYAKnuM5wedgMpA== X-RZG-CLASS-ID: mo00 Received: from brain.bubecks.de (p5B2CEB7F.dip0.t-ipconnect.de [91.44.235.127]) by smtp.strato.de (RZmta 32.17 DYNA|AUTH) with (TLSv1:DHE-RSA-AES256-SHA encrypted) ESMTPSA id I01fd8q0LJtfeoH ; Tue, 21 Jan 2014 20:55:41 +0100 (CET) Received: from [10.2.1.33] (fw.wid.reinform.de [10.2.1.254]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by brain.bubecks.de (Postfix) with ESMTPSA id 75887884D7 for ; Tue, 21 Jan 2014 20:55:41 +0100 (CET) Message-ID: <52DED0BC.8060902@bubecks.de> Date: Tue, 21 Jan 2014 20:55:40 +0100 From: "Dr. Tilmann Bubeck" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [PATCH] Improve ext2 driver to allow embedding of the boot loader code. References: <1389301657-8236-1-git-send-email-tilmann@bubecks.de> <52CF282C.4070408@gmail.com> <52CFA5FF.7070200@bubecks.de> <52DE2C79.2000507@gmail.com> <52DE30AD.9030301@gmail.com> <52DE541E.2090600@gmail.com> In-Reply-To: <52DE541E.2090600@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a01:238:20a:202:5300::7 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:09:09 -0000 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 wrote: >>> On 21.01.2014 09:28, Andrey Borzenkov wrote: >>>> On Tue, Jan 21, 2014 at 12:14 PM, Vladimir 'φ-coder/phcoder' >>>> Serbinenko 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 >