From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PbD9g-00050n-At for mharc-grub-devel@gnu.org; Fri, 07 Jan 2011 09:19:00 -0500 Received: from [140.186.70.92] (port=38320 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbD9d-0004zB-Cm for grub-devel@gnu.org; Fri, 07 Jan 2011 09:18:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbD9c-0001eq-DJ for grub-devel@gnu.org; Fri, 07 Jan 2011 09:18:57 -0500 Received: from mail-ww0-f41.google.com ([74.125.82.41]:40856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbD9c-0001ei-9C for grub-devel@gnu.org; Fri, 07 Jan 2011 09:18:56 -0500 Received: by wwi18 with SMTP id 18so502675wwi.0 for ; Fri, 07 Jan 2011 06:18:55 -0800 (PST) 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=rFU5hp2NZBq6Rxu4VL0QiEfVMfpshWU/0ppHUzIFfHI=; b=unB535f5ZLZ6W+nJGxSBTfdL7Ij3gsiQLcl41nY4LtrrdfZjCxnG/46+DBSMSQwrJT bhDWolipJjVgTCCdHzBBNsjdwb2nio1EiXBP+BbV3CPDXpnCEFN9C3rK9phVEF0t40s8 vAgLtBGdQBI6kSsqSvQ2loP+231lYJdzbtnCU= 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=SJvIBfOzX9e1btBSBNMNs8KljnnYcXcJVqsV2IBiEAkBmN0jKJfGLKZqCnPfjWBYt4 NkbwtqNY0f8gbzn5+6zSVAqB5A01+mMHmH1kiDHK/LhGZ7mkYZkFNY8FjykOkdru5UyX JhkIIMGFjfU9xggnZbYEJ+AKVacvEY+0Sw+5g= Received: by 10.227.132.213 with SMTP id c21mr15546281wbt.28.1294409935445; Fri, 07 Jan 2011 06:18:55 -0800 (PST) Received: from [147.210.129.183] (laptop-147-210-129-183.labri.fr [147.210.129.183]) by mx.google.com with ESMTPS id 11sm17697377wbj.7.2011.01.07.06.18.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 06:18:54 -0800 (PST) Message-ID: <4D2720CC.8030207@gmail.com> Date: Fri, 07 Jan 2011 15:18:52 +0100 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.9.2.11) Gecko/20101130 Lightning/1.0b3pre Lanikai/3.1.5 MIME-Version: 1.0 To: The development of GNU GRUB References: <4D26DE69.5080106@gmail.com> <4D26EB2E.5030106@gmail.com> <4D26F7C6.9080904@gmail.com> <4D270506.9060003@gmail.com> In-Reply-To: <4D270506.9060003@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Reserved first sector for UFS X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Fri, 07 Jan 2011 14:18:58 -0000 On 01/07/2011 13:20, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> Do you know of any OS that would put the superblock in sector 0? >> I googled a bit, but I couldn't find examples where UFS would >> not start with a boot sector (afaics, it usually starts with a >> bootblock area of at least 8KiB -- with OS-specific data in it, >> e.g. a disklabel). >> > According to *BSD http://fxr.watson.org/fxr/source/ufs/ffs/fs.h: > > */"* Depending on the architecture and the media, the superblock may/* > */* reside in any one of four places. For tiny media where every block /* > */* counts, it is placed at the very front of the partition. Historically,/* > */* UFS1 placed it 8K from the front to leave room for the disk label and/* > */* a small bootstrap. For UFS2 it got moved to 64K from the front to leave/* > */* room for the disk label and a bigger bootstrap, and for really piggy/* > */* systems we check at 256K from the front if the first three fail/*" Interesting. So, when searching for a UFS superblock, sector 0 is a candidate (after sectors 128 and 16). It seems to me that this use of sector 0 for tiny media does not apply to (recent) NetBSD newfs(8), though. If we want to improve the situation, we could let the filesystem driver dynamically decide whether the first sector is reserved or not. But I'm not sure that it's worth it (the first sector of a partition containing a filesystem is only used for blocklist embedding, right?). Grégoire