From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LlNen-00023h-1r for mharc-grub-devel@gnu.org; Sun, 22 Mar 2009 09:24:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlNej-00023O-V0 for grub-devel@gnu.org; Sun, 22 Mar 2009 09:24:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlNee-00023C-EN for grub-devel@gnu.org; Sun, 22 Mar 2009 09:24:00 -0400 Received: from [199.232.76.173] (port=40753 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlNee-000239-8M for grub-devel@gnu.org; Sun, 22 Mar 2009 09:23:56 -0400 Received: from fg-out-1718.google.com ([72.14.220.159]:17012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlNed-0003BK-Po for grub-devel@gnu.org; Sun, 22 Mar 2009 09:23:56 -0400 Received: by fg-out-1718.google.com with SMTP id 19so462343fgg.7 for ; Sun, 22 Mar 2009 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=S1tPaq+a/q2wF8eMcsGaoBeYXcsg5JbIPdMmd/yXvXE=; b=GZdLx+60YR8sTte5QrHhM2+zx55R6Ex8n//QNsCIqGM3spTTk9qjZz9CNXZZBsDa1g kc+llz4jY9JSOrJcmveotJppzcSgcUU+LtRnF3TFKwcguR3wUKcf/TS83dTBr2AHswRe oLd/1tq+5QS7MkMtySH7Q/X1A0/xaoJg//NCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Gtg5HhivWpY0DcELK407FUVCVOE8d50xMs+Wj8X3xm5u8eKdH9NeCddEiTzpJZzd3s hJtGhEROGMV7QEb8j4YSbgk8JPpZBzDXxwH6Qc5npKk58Hoqt7JwaJsE33VXNLipnLgV KC+L3x+o0pC0/FOadMrjt8TRzulwcPx9ejhwo= Received: by 10.86.49.13 with SMTP id w13mr2826426fgw.1.1237728234125; Sun, 22 Mar 2009 06:23:54 -0700 (PDT) Received: from ?192.168.1.25? (252.80.3.213.cust.bluewin.ch [213.3.80.252]) by mx.google.com with ESMTPS id l19sm1742617fgb.1.2009.03.22.06.23.53 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Mar 2009 06:23:53 -0700 (PDT) Message-ID: <49C63BE9.2070405@gmail.com> Date: Sun, 22 Mar 2009 14:23:53 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49A50DA2.20604@netsyncro.com> <200903221601.36503.okuji@enbug.org> <49C61784.6020602@gmail.com> <200903222211.03080.okuji@enbug.org> In-Reply-To: <200903222211.03080.okuji@enbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 13:24:02 -0000 Yoshinori K. Okuji wrote: > On Sunday 22 March 2009 19:48:36 phcoder wrote: >> Hello, I agree that non-sector aligned writes should be handled >> correctly. However I disagree with removing of the magic number. I >> personally would prefer if this file would have magic number and >> checksum. AFAIK currently grub2 doesn't write to FS except in >> load_env/save_env so a bug in code calling the hook could easily be >> present. And I don't want grub2 to corrupt the filesystem because of any >> such mistakes > > For magic, alright. But I am not certain about the necessity of checksum. > > Bean's code re-reads blocks so as to ensure that blocklists are identical to > what a given filesystem driver reads. So the probability of accidental writes > has been reduced very much already. It is hard for me to imagine the benefit > of adding more overhead. With this condition, if a checksum is invalid, the > cause must be either of these: > > - that GRUB has a bug in a filesystem driver, so this has read wrong sectors > - that the content of grubenv has already been corrupted (e.g. because the > user modified it mistakenly) > > In the latter case, there is no problem in GRUB overwriting the data, so we > don't have to care. In the former, this means that GRUB cannot read the > filesystem correctly anyway, so the user cannot boot any OS reliably. It is > rather surprising that the user has successfully installed GRUB. This assumption doesn't hold true if developping new FS using grub-emu. Perhaps a configure parameter to disable all writes would be a good idea? > > Regards, > Okuji > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko