From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V2SUY-0005p1-HE for mharc-grub-devel@gnu.org; Thu, 25 Jul 2013 16:50:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2ROf-0006em-LZ for grub-devel@gnu.org; Thu, 25 Jul 2013 15:40:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2ROc-0003bD-MX for grub-devel@gnu.org; Thu, 25 Jul 2013 15:40:21 -0400 Received: from mo6-p00-ob.rzone.de ([2a01:238:20a:202:5300::1]:19942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2ROc-0003a4-Am for grub-devel@gnu.org; Thu, 25 Jul 2013 15:40:18 -0400 X-RZG-AUTH: :OGUIeEGmdd9LocaRWNUrTCqIQctGnGgg+eszxi8Zzh68aZhTiI3aYTRTQoeQ2ZsVPw== X-RZG-CLASS-ID: mo00 Received: from brain.bubecks.de (p3E9E841B.dip0.t-ipconnect.de [62.158.132.27]) by smtp.strato.de (joses mo25) (RZmta 31.30 DYNA|AUTH) with (DHE-RSA-CAMELLIA256-SHA encrypted) ESMTPA id 2015dbp6PJ12Ea ; Thu, 25 Jul 2013 21:40:15 +0200 (CEST) Received: from t420.wid.reinform.de (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 1A13187C39 for ; Thu, 25 Jul 2013 21:40:15 +0200 (CEST) Message-ID: <51F17F1E.4050400@bubecks.de> Date: Thu, 25 Jul 2013 21:40:14 +0200 From: "Dr. Tilmann Bubeck" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Why special linux code in grub2/util/grub-setup.c References: <8513f87fd2e877871174acaf00583071.squirrel@bubecks.de> <51DFAAB0.2040908@gmail.com> <51DFF9EC.7010801@bubecks.de> <51F14448.2050103@gmail.com> In-Reply-To: <51F14448.2050103@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::1 X-Mailman-Approved-At: Thu, 25 Jul 2013 16:50:29 -0400 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: Thu, 25 Jul 2013 19:40:25 -0000 Am 25.07.2013 17:29, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 12.07.2013 14:43, Dr. Tilmann Bubeck wrote: >> Hi Vladimir, >> >> Am 12.07.2013 09:05, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: >>> On 12.07.2013 08:52, Dr. Tilmann Bubeck wrote: >>>> Hi Vladimir, >>>> >>>> I am curently preparing an improvement for GRUB2 to let it embed into >>>> ext4 >>>> based upon the new ioctl EXT4_IOC_SWAP_BOOT which I wrote for linux >>>> 3.10. >>>> This would allow to install GRUB SAFELY into a file system and omit the >>>> warning about block list being unreliable (for ext4). >>>> >>> What does this ioctl do? >> >> It was discussed with Ted T'so and modelled after his suggestion and >> included in 3.10. It takes the file associated with the file descriptor >> passed to the ioctl and stores the data blocks of that file in a special >> (reserved) inode called "BOOT_IMAGE_INO". This inode is reserved >> specifically for storing boot loaders inside the filesystem. Technically >> it copies the inodes data block pointers and some more data like >> timestamps from the given file's inode to the BOOT_IMAGE_INO. >> >> This means, that we have a reserved area for storing the boot file and >> that area is never touched again and therefore "sealed". No user tool is >> able to get access to that data (except debug2fs and similar). It is not >> visible in any directory and not destroyed or reported by e2fsck. It is >> similar to the reserved area for booting in btrfs. >> >> It is called "SWAP", because the previous content of the BOOT_IMAGE_INO >> is linked back to the given fd. Therefore one is able to get the >> previous boot code in exchange. GRUB would delete that right away. >> >> Using this ioctl we could make ext4 able to embed reliably which would >> allow installing GRUB into a partition without requiring "--force". >> >>>> To do so I need code to get the blocks of a file. I found that this is >>>> already present in grub2/util/grub-setup.c. I have a few questons based >>>> upon your changes in revision 4033. >>>> >>>> 1. Why did you add additional (linux only) methods to get block list >>>> based >>>> upon FS_IOC_FIEMAP and FIBMAP instead of sticking with the existing >>>> (generic) code based upon file->read_hook = save_blocklists? >>>> >>> Because Linux buffering and caching is piece of shit and even issuing >>> flush, sync and flushing ioctl doesn't make metadata go to disk. >> > >>>> 2. I would like to refactor the above code, so that there is a new >>>> method >>>> called "grub_getblocklist(dir, core_file, &blocklist);". This method >>>> move >>>> contain your code together with the generic code to find the blocklist. >>>> This method would then be called from the existing place (and my new >>>> place >>>> in fs/ext2.c if GRUB_UTIL). >>>> >>>> What do you think? >>>> >>> Relying on blocklist retrieving is likely wrong and doesn't solve any >>> of blocklist problems. But I lack details to know for sure and right now >>> I'm under a lot of stress with my thesis on neural learning. >> >> I would use the blocklist of the above BOOT_IMAGE_INO which will never >> change and therefore will never break. However, I need a way to know >> where the blocks are stored, even if they are "save". >> >> Would you accept a patch from me, using the above IOCTL to make >> embedding to ext4 work reliable? Sure, we have to discuss the details >> but before I start I would like to get a feeling, if this would have a >> chance for inclusion. >> > What's with the allocation issues? The blocks have to be as near to the > beginning as possible. Is it possible to modify the embedding zone > without doing the "swapping"? There is a parallel issues in LVM which > would prompt for the ability of overwrite only part of embedded zone. The embedding zone is not accessible and could not be changed. This ensure, that block lists keep stable. If you want to change the content, then you have to install a new file using IOCTL (and you will get back the previous embedded file in exchange). -- Mit freundlichen Gruessen, Tilmann Bubeck //// dr. tilmann bubeck, it professional & geek //// //// till@bubecks.de / http://www.bubecks.de //// mobile: 0172-8842972 / fon: 0711-7227719 / fax: 0711-7227734 //// widmaierstr. 58 / 70567 stuttgart / germany