From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MaURc-000637-EN for mharc-grub-devel@gnu.org; Mon, 10 Aug 2009 08:57:44 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaURb-000632-QG for grub-devel@gnu.org; Mon, 10 Aug 2009 08:57:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaURX-00062h-PC for grub-devel@gnu.org; Mon, 10 Aug 2009 08:57:43 -0400 Received: from [199.232.76.173] (port=55882 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaURX-00062e-KJ for grub-devel@gnu.org; Mon, 10 Aug 2009 08:57:39 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:64701) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MaURX-000458-0H for grub-devel@gnu.org; Mon, 10 Aug 2009 08:57:39 -0400 Received: from [85.180.2.205] (e180002205.adsl.alicedsl.de [85.180.2.205]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MKuxg-1MaURV3cV6-0008Jb; Mon, 10 Aug 2009 14:57:38 +0200 From: Felix Zielcke To: The development of GRUB 2 In-Reply-To: <1249908373.3579.10.camel@fz.local> References: <20090728181234.GI32726@thorin> <1248857003.3729.0.camel@fz.local> <20090731160546.GF14675@thorin> <1249057611.3635.11.camel@fz.local> <20090804211955.GA16346@thorin> <1249453109.3549.6.camel@fz.local> <20090807112732.GH6695@thorin> <1249655340.3592.12.camel@fz.local> <20090807192212.GB14498@thorin> <1249708400.3537.0.camel@fz.local> <20090810113158.GC9344@thorin> <1249908373.3579.10.camel@fz.local> Content-Type: text/plain Date: Mon, 10 Aug 2009 14:58:39 +0200 Message-Id: <1249909119.3579.11.camel@fz.local> Mime-Version: 1.0 X-Mailer: Evolution 2.27.5 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18ulY+/CYzxHLx0IaKGg77Wpbmjj10rxozcXvE R9fiwWWhWb16avEmj5+ewgVw7HNJs0316rromL2cCL8IyI4C+M hcD9iGPzHGZ6gssXx+Y6Q== X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] use UUID to map system devices to grub devices 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: Mon, 10 Aug 2009 12:57:43 -0000 Am Montag, den 10.08.2009, 14:46 +0200 schrieb Felix Zielcke: > Am Montag, den 10.08.2009, 13:31 +0200 schrieb Robert Millan: > > On Sat, Aug 08, 2009 at 07:13:20AM +0200, Felix Zielcke wrote: > > > Am Freitag, den 07.08.2009, 21:22 +0200 schrieb Robert Millan: > > > > On Fri, Aug 07, 2009 at 04:29:00PM +0200, Felix Zielcke wrote: > > > > > Am Freitag, den 07.08.2009, 13:27 +0200 schrieb Robert Millan: > > > > > > On Wed, Aug 05, 2009 at 08:18:29AM +0200, Felix Zielcke wrote: > > > > > > > Am Dienstag, den 04.08.2009, 23:19 +0200 schrieb Robert Millan: > > > > > > > > On Fri, Jul 31, 2009 at 06:26:51PM +0200, Felix Zielcke wrote: > > > > > > > > > > > > > > > > > > If we'd do an arbitrary mapping then `grub-probe -t drive' would show > > > > > > > > > the wrong grub device. > > > > > > > > > But except from this I think that would be okay. > > > > > > > > > > > > > > > > We can never garantee that `grub-probe -t drive' will show the "right" drive, > > > > > > > > at least on i386-pc, because we don't know how is BIOS going to order them. > > > > > > > > > > > > > > Yes drive not, but the partition. > > > > > > > > > > > > It's true, but we don't really make the distinction. UUID search will find > > > > > > a filesystem, which is in a partition (usually), and doesn't rely on partitions > > > > > > being reliable. > > > > > > > > > > > > That's fortunate! It means we don't have to commit to partition numbers being > > > > > > reliable, even if they are right now. > > > > > > > > > > > > Because of this (unless I missed something), at the end of the day the > > > > > > unreliability issue you described doesn't translate into any real problem > > > > > > for us. It just adds more to a problem we already solved. > > > > > > > > > > > > > Unfortunately we don't have UUID support on every filesystem we support > > > > > > > like JFS. But I think it's not that commonly used. > > > > > > > > > > > > Adding UUID support to new filesystems is very easy. I did the first ones > > > > > > with just 5-10 minutes of research and a few lines of coding. > > > > > > > > > > > > Would you like to do JFS ? > > > > > > > > > > I did it now for JFS. > > > > > > > > > > I tried it now out with dos_part set to p + 2 with my find_by_uuid patch > > > > > and now I get a `no such partition' error on my dmraid device. > > > > > So we can't use an arbitary mapping in grub_util_biosdisk_get_grub_dev > > > > > > > > Why not? > > > > > > well then we would need to change the partition table parsing code to > > > use the same arbitary mapping for GRUB_UTIL && LINUX then > > > grub_util_biosdisk_get_grub_dev and I think that's not really a proper > > > solution. > > > > Why? In that specific situation, it seems: > > > > - We're unable to obtain partition numbers reliably > > > > - It doesn't matter, because the upper layer will sort that out > > Well with the current design of util/hostdisk.c it doestn't work. > I don't know how we can make an arbitary mapping work. > > > Though, it'd be much better if we could obtain this information from Linux. > > Did you figure out if the behaviour of that ioctl is a bug or is intentional? > > Probable intentional, because device-mapper is also used for LVM for > which HDIO_GETGEO really doestn't make sense. > Someone sent a patch to implement it for device-mapper in 2006 to LKML > [0] but it wasn't accepted. > Now I noticed Andrew Morton said `block_device_operations now has a > standalone `getgeo' method.', which doestn't say me anything if this is > something we can use or if this is purely internal for the kernel. > > [0] http://lkml.indiana.edu/hypermail/linux/kernel/0602.1/index.html#0729 > Oh and it's limited to 2 TiB on 32bit systems, so I think it would be good if we find an alternative to it. Western Digital and Seagate sell now 2 TB disks. -- Felix Zielcke Proud Debian Maintainer